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 (disregardfirst reply)

Perhaps I'm misunderstanding this, but if you take Subject out of 
SubjectStatement, what is the difference between 
SubjectStatementAbstractType and StatementAbstractType? So what makes 
SubjectStatement (or AuthenticationStatement) a subject statement if the 
Subject is at the same level as the statement in the assertion? That 
makes me think Eve had this right - we have an Assertion and a 
"SubjectlessAssertion" - at least conceptually. But I don't think I like 
that concept so much - especially with multiple statements in the 
assertion. In addition, the pseudo-schema you have below seems to 
restrict your assertion to non-Subject related statements OR 
Subject-related statements in one assertion but not both. That is not as 
flexible as what we have now.

So, I guess I would suggest:

1) We define an container for Subject+SubjectStatements (where 
SubjectStatement and its ilk are now descended from 
StatementAbstractType, with additional other Subject related info 
(SubjectLocality for example).
2) SubjectStatements can only appear in the container element (ie. along 
with a Subject)
3) The SubjectStatementContainer and other statements can all exist in 
the same assertion.

- JohnK

ext Scott Cantor wrote:

> Sorry, belay that last post, I pulled out an earlier sketch I had done
> before we settled on not having per-statement subject confirmation, so I was
> down a different track there.
> I suggest this instead:
> <Statement> of StatementAbstractType (empty)
> <SubjectStatement> SubjectStatementAbstractType (also empty)
> SubjectStatementAbstractType does not derive from StatementAbstractType.
> Then inside AssertionType:
> 	...usual assertion header, conditions, etc.
> <choice>
> 	<sequence>
> 		<element ref="saml:Subject"/>
> 		<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>
> <Subject> still has the current overall design, I assume, where you either
> have an identifier plus zero or more confirmations OR you have just one or
> more confirmations.
> -- Scott
> To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/security-services/members/leave_workgroup.php.

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