RE: saml assertion schema notes

[Chris McLaren <cmclaren@netegrity.com>]

> Assertion type has 4 required attributes. Also we have to specify
> xsi:type for each assertion instance. It will make 5 required
> attributes
> for each assertion. I think it will be difficult to read. Why
> not make
> 4 required attributes in base assertion into elements and
> have one xsi:type
> attribute?

I believe the rationale here was to make a distinction between meta-data
about the assertion and the contents of the assertion. Meta-data is
expressed as attributes and contents of the assertion as elements.

I am not sure that "readability" is really an argument for XML--it's meant
to be machine-readable, not human-readable--but I haven't put a lot of
thought into it.

> Advice element could be misused for anything that does not fit into
> assertion.

This one is directly out of the F2F notes. If you feel having it, or having
it as an any, are wrong decisions, that is an issue to be taken up with the
full TC. The consensus draft has to reflect the minutes of the F2F, where
the will of the entire TC was expressed.

> There is a typo on line 249 for the SubjectType:
> Authenticator is referenced
> but everywhere in the text HolderOfKey is mentioned. I belive
> there is still
> an open issue on this element name.

That would be a typo. Thanks for catching that.

> It is not clear what can be a subject of AuthenticationAssertion.
> Definetely AssertionSpecifier should not be used in this case
> but schema
> does not preclude it. (AssertionSpecifier will give us
> self-reference and
> subject will be left undefined)

The subject of any assertion (including Authentication) is what is
identified by the Subject element. One of the possible contents of this
element is an AssertionSpecifier (read as "The subject of this assertion is
the same as the subject of _THAT_ assertion" where the AssertionSpecifier
specifies the other assertion). Naturally this opens the door for the
creation of a pathological assertion who's subject references itself, but I
don't think that's a real concern.

If you know of a way to model the restriction in schema that the referenced
assertion has to have a different ID than the containing assertion, then we
can add it. I don't know of any way to do that. The use of
AssertionSpecifier as a possible content of the Subject element is again
directly from the F2F notes.

Chris