OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [security-services] Moving subjects up to assertions

Maybe I'm off track, but my thinking was that we could simplify this by
embedding the distinction within the single AssertionType/<Assertion>

I would propose something like this (forgive the pseudocode notation):

<Statement> of StatementAbstractType (empty)
<SubjectStatement> SubjectStatementAbstractType (<SubjectConfirmation>*)

SubjectStatementAbstractType does not derive from StatementAbstractType.

Then inside AssertionType, you do something like the following (I've tweaked
a few elements to jump the gun on some abbreviations):

	...usual assertion header, conditions, etc.
			<element ref="saml:BaseIdentifier"/>
			<element ref="saml:NameIdentifier"/>
			<element ref="saml:EncryptedIdentifier"/>
		<choice maxOccurs="unbounded">
			<element ref="saml:SubjectStatement">
			<element ref="saml:AttributeStatement">
			<element ref="saml:AuthnStatement">
			<element ref="saml:AuthzDecisionStatement">
		<element ref="saml:Statement" maxOccurs="unbounded"/>

So either an assertion is one or more subject-less statements, or it's a
name identifier (of any sort) plus one or more subject statements.

I think this is cleaner, personally, though it hides more of the
distinctions. I guess the point is, where do you want to fork off the
processing model? I don't think, as long as we continue to bottom-type the
statements that are the real content, we need to top-type on this one issue.
An assertion should still be commonly processable in either case.

-- Scott

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]