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] Retracting earlier SubjectRef suggestion

Note that, with Scott's original solution proposal, we could have used 
XSD's keyref capabilities to scope IDREF values to IDs assigned only in 
the current assertion element.  But I don't know how interoperable this 
really is.

If we agree to "factor out" common subjects, we still have a choice 
about whether to accept the use case of multi-subject assertions, as 
Scott notes below.  However, whether or not we accept it, there's still 
some looming schema awkwardness:

Any statements without a <Subject> present (which could be *all* of them 
or *some* of them, depending on the decision above) are still subject 
statements in the sense that they "inherit" the common subject from 
above, but if SubjectStatementAbstractType now has an optional <Subject> 
element in it, where have we gone with that semantic?  Should we just 
have StatementAbstractType with an optional <Subject> element in it and 
do away with the "...Subject..." type level?

Other, more Draconian, solutions (such as splitting into 
SubjectStatement types and ImpliedSubjectStatement types) seem not worth 
the trouble.


Scott Cantor wrote:

> I did some back-of-napkin implementation of my SubjectRef proposal, and even
> though it's more elegant to specify and is more consistent with the current
> spec, it's a little harder to implement than defaulting the Subject would
> be.
> Polar's comment also got me a little paranoid, only in the sense that one of
> the advantages of SubjectRef is that I was hoping to keep the relationship
> between schema validity and SAML validity. Since multiple assertions can
> appear in an XML document, this wouldn't hold with my suggestion any more
> than it does in Conor's, so it's a lose either way for me.
> So I retract that idea and suggest we go ahead and at least add an optional
> <Subject> ahead of the statement sequence and then make <Subject> optional
> in the SubjectStatementType. I can't think of any actual use cases for a
> statement that would optionally have a "primary" subject, so there's not
> much point in worrying about weird hypotheticals.
> That said, I'd like to ask what the use cases are for multiple
> SubjectStatements with different Subjects? I can't see any current or
> proposed protocols that would be likely to result in such a thing. If there
> aren't any, then why do we need to support it? It certainly creates enough
> headaches.
> -- Scott

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]