Proposal for assertion-level subjects

["Eve L. Maler" <Eve.Maler@Sun.COM>]

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