RE: [security-services] Last call issues with schema

[Scott Cantor <cantor.2@osu.edu>]

> I see your point. I was wondering how to refer to assertions 
> when stored or used outside the protocol context. 

Right, something that's largely undefined at this point. Using a URI makes sense except for the currently common cases in which the
"where" part is implied (but not the current message), and I'm not sure what to do there.

In 1.0, we permitted and explicitly mentioned that identifiers could be URIs themselves. So I guess the thinking was that the where
question could in fact be answered by the identifier. That's no longer true, but it wasn't my impression that too many
implementations actually were doing that anyway, so the problem isn't new.

> To give an example, what if an assertion includes Evidence 
> that has an AssertionIDReference. Is it true that this 
> reference is a name defined by the authority that produced 
> the evidence and used to query that authority for the 
> evidence assertion? If so, then obtaining evidence from more 
> than one authority could be a problem? This is why I was 
> thinking about a URI. (An alternative is for Evidence to 
> indicate where in addition to what, with what being the name).

In some respects, this is what an artifact is, a special one-time reference that also includes an identifier that can be mapped to
metadata about where to find the assertion. Absent that approach, as in the case of Evidence, it's left unaddressed by SAML.

Probably what needs to happen (in 2.0 perhaps) is a divergence of the various referencing elements and attributes into separate
types with URIs used in cases like Evidence, and simple NCNames used in places like InResponseTo or in a Query.

-- Scott