[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] Does anyone create assertions with more than onesubject? (was RE: [security-services] Retracting earlier SubjectRef suggestion)
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:email@example.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.