[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. Eve 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]