Re: [security-services] Retracting earlier SubjectRef suggestion

[Ron Monzillo <Ronald.Monzillo@Sun.COM>]

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.
>
Scott,

Are you also reconsidering the the other change you suggested (i.e.
including muliple SubjectConfirmation elements in a statment)?

I liked that suggestion as it seemed to allow alternative combinations of
confirming entity and statement to be expressed without needing to
rely on a multi-statment assertion to carry the alternatives. It also seemed
to suggest how multiple subjects could be "combined", based on
confirmation method,  within a single statement, and without (necessarily)
relying on other  assertions/security tokens.

Ron

>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
>
>
>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.
>
>  
>