RE: saml assertion schema notes

["Hallam-Baker, Phillip" <pbaker@verisign.com>]

Title: saml assertion schema notes

From: Simon Godik [mailto:sgodik@crosslogix.com]

notes on draft-sstc-core-discussion-00.doc

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?  

 The attributes were elements at one time, people thought they should be attributes. converting them into elements would make the messages larger, not smaller and the data items that bind tightly to the parent element would not lumped together with those that are true sub-containers.

The xsi:type attribute is a separate issue, see the thread on substitution groups.

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

True but by definition implementations are not required to take any notice of information in the advice element. I have a feeling that what you are perjoritatively calling 'misuse' I would call a 'legitimate extension'.

There are many abstract types but only AbstractConditionType has 'Abstract'
in it's name.  It is confusing: we either should use 'Abstract' in the name
of every abstract type or not at all.  

There are a bunch of naming consistency issues, the 'abstract' issue is one, the <SAMLRequest> etc. is another. 

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.  

The bug is not present in the core-11, at which point it was fixed/broken I won't investigate.

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)

Should I add text in the draft to address the issue? If so what?

Changing the schema to prohibit recursion would be possible but unwieldy.

Also I don't see how confusion would arise by accident, for the nested construct to appear one would have to be indulging in some multi-step, multi-factor authentication process (e.g. PIN, SecureID, plus biometric DNA sample). If people want to do such things maybe it is a legitimate use case?

        Phill

Phillip Hallam-Baker (E-mail).vcf