Re: [security-services] Proposal for assertion-level subjects

[Greg Whitehead <grw@trustgenix.com>]

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.