[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [security-services] Proposal for assertion-level subjects
One of the benefits that I was looking forward to with assertion-level subjects was only having to confirm the subject *once* in the common case, and I'm not sure how that is impacted by this proposal. In the presumably common case that there is one SubjectConfirmation method that a number of statements share, does this proposal allow an assertion-level expression of that method? Thanks, -Greg On Feb 24, 2004, at 11:28 AM, Eve L. Maler wrote: > 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 > > > 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.