RE: [security-services] Does anyone create assertions with more than onesubject? (was RE: [security-services] Retracting earlier SubjectRef suggestion)

["Beach, Michael C" <michael.c.beach@boeing.com>]

The only multi-subject discussions we have had in Boeing relate to
services (subject 1) acting on behalf of a user (subject 2).  I picture
that working just fine with 2 assertions.  Also seems 2 assertions would
be easier to handle on the receiving end anyway.  I understand the
theory of chains of intermediaries and proxies (and thus many subjects),
but we have many folks that are just beginning to grasp the implications
of single external user identity assertions.

So, unless I am missing something, I also think the single subject per
assertion is a good idea.

Mike Beach 

-----Original Message-----
From: Linn, John [mailto:jlinn@rsasecurity.com] 
Sent: Thursday, February 12, 2004 6:18 AM
To: 'Scott Cantor'; 'Reid, Irving'; 'SAML'
Subject: RE: [security-services] Does anyone create assertions with more
than onesubject? (was RE: [security-services] Retracting earlier
SubjectRef suggestion)

Scott writes, excerpting: 

>> I'd be happy to move a proposal to *completely remove* the subject 
>> from the Statement element, and have a single subject in each 
>> assertion. I believe that we fell victim to optimizing the 1-percent 
>> case when we moved the subject into the statement in the first place.
>
>That's certainly my view, but I wasn't sure how people felt about it. I

>would second such a motion.

I'd "third" the hypothetical motion to avoid multi-subject assertions,
unless a compelling functional requirement emerges therefor, though am
neutral about the precise representation involved.  This seems somewhat
(though not exactly) reminscent of X.509 certificates, where each of the
elements of issuers' and subjects' relative distinguished names can
themselves be multi-valued.  I think it's fair to state that this has
generally proven to be a facility that's provided more confusion than
usage or utility.  As recent discussions have demonstrated, complex SAML
usage scenarios can lead to complex trust implications.  These are
important to specify and understand clearly, in order to grasp the
security properties of the overall system.  I expect that it will be
easier to analyze the mainstream case, with a single subject per
assertion, than to generalize in order to allow a more complicated
situation that may not be functionally necessary.  If we can take this
sort of simplification here, I think we should. 

--jl



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/l
eave_workgroup.php.