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: Moving subjects up to assertions

We agreed on our last call that we don't need "subjectless" assertions, 
but we're now wondering if XACML needs them because it wants to add its 
own subject information that doesn't look anything like SAML's.  I've 
copied Anne Anderson to see if she can confirm this.

(Detail: Recall that we agreed to move <Subject> up to <Assertion>, and 
agreed not to offer a subjectless version of assertions.  Statements 
will now have no <Subject> element explicitly on them, but it's only 
because they inherit the subject information on the assertion parent.)

If it turns out that XACML does want to avoid SAML's <Subject> element 
and supplant it with their own, then we do need to add an abstract 
datatype branch in the schema for subjectless assertions.  *If* we do 
need to do this, I'll need some guidance on the style to use, as 
explained below.

In SAML V1.x, we had StatementAbstractType and <Statement>, 
SubjectStatementAbstractType and <SubjectStatement>, and then the three 
concrete statement types/elements.  If we want to apply this same 
solution pattern to the assertion level in order to solve the putative 
XACML need, I have a question:

We've always had a generic <Assertion> element.  If I add a hierarchy 
such as AssertionAbstractType->SubjectAssertionType, would the names of 
the associated element pair have to be <Assertion> and 
<SubjectAssertion> (which swaps a new meaning onto an old element name), 
or should we have <SubjectlessAssertion> and <Assertion> instead (which 
approximately preserves the name of the thing with the 1.x meaning, but 
may be considered inconsistent given the types they're bound to)?

I've written this quickly 'cause I have to leave the office soon, so I 
hope it's understandable.  If the response is silence or a big "huh?", 
I'll try again tomorrow.

Eve Maler                                        +1 781 442 3190
Sun Microsystems                            cell +1 781 354 9441
Web Products, Technologies, and Standards    eve.maler @ sun.com

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