[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Proposal for assertion-level subjects
In today's focus call, we discussed the matter of assertion-level subjects, which bled a little into the matter of subject confirmations in the grander scheme of things. The thinking went along these lines: - The use case of an assertion with multiple statements having multiple subjects is unrealistic at this time. It would be simpler to do away with it. - However, if we achieve this in the obvious way (move Subject up to the Assertion level), then SubjectConfirmation comes along for the ride. - This is bad because the use case of an assertion with the *same* subject for all statements but *multiple* ways to confirm that subject is *realistic* (and, more to the point, desired). - Irving's idea of subject confirmations being a kind of condition ("use this statement only if you can confirm the subject") is valid, though we didn't have a problem seeing it as such a special-purpose condition that it deserves a special- purpose construct. I mentioned a strawman proposal on the call for how to meet the entire set of needs here with some schema changes that are relatively modest, and agreed to write it up for closer study on the list. Here it is. - English: Allow a series of zero or more "naked" SubjectConfirmation elements in Statements. (XSD-speak: Remove the SubjectConfirmation element from the content model of SubjectType, base the three major statement types on StatementAbstractType instead of SubjectStatementType (which would itself be removed as dead code), and reference SubjectConfirmation as an optional repeatable element inside StatementAbstractType. Put some prose around what it means to have multiple subject confirmations on a statement.) - English: Push the Subject element up into Assertion as a required field, but make sure that people can still create subjectless assertions if they wish. (XSD-speak: Change AssertionType to AssertionAbstractType and derive a new SubjectAssertionType from it that contains a required Subject element after the Issuer element. Base the Assertion element on SubjectAssertionType. (This is on the theory that all of SAML's three main statement types currently require subjects anyway, and that we have a StatementAbstractType-to- SubjectStatementType hierarchy now.)) - English: If anyone wants to treat a confirming key as a condition for a subjectless assertion of some kind, they can make the appropriate extensions in the usual manner. (XSD- speak: They would have to extend AssertionAbstractType into their own assertion type, and extend the Condition element to make a new condition.) Thoughts? Scott mentioned that he thought he could make some progress on refining the authN request protocol proposal (currently appearing in core-06) if we got this settled. Eve -- 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]