[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> structure. 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. <choice> <sequence> <choice> <element ref="saml:BaseIdentifier"/> <element ref="saml:NameIdentifier"/> <element ref="saml:EncryptedIdentifier"/> </choice> <choice maxOccurs="unbounded"> <element ref="saml:SubjectStatement"> <element ref="saml:AttributeStatement"> <element ref="saml:AuthnStatement"> <element ref="saml:AuthzDecisionStatement"> </choice> </sequence> <sequence> <element ref="saml:Statement" maxOccurs="unbounded"/> </sequence> </choice> 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]