[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] Comments on core-2.0-cd-01 - Assertion Issuee
>>>>> " " == Scott Cantor <cantor.2@osu.edu> writes: This is precisely the semantic I was looking for when I proposed IssuedTo. Thanks actually to Ron who reminded me of the thread in the first place. I also agree that IssuedTo may have a better use as a way to audit the injection of an assertion into the system. >> There should be an indentifier which reflects the party (or parties) >> the assertion was issued to. With X.509 end entity certificates the >> issuee is described by either the SubjectName or the >> SubjectAltName. However, SAML is much more flexible with respect to >> the role of the entity being described by the <Subject> element. > Although knowing the issuee may have some usefulness in terms of auditing, I > think the real goal of this suggestion is about providing more information > in the assertion about the entity (or entities) that are expected to *use* > the assertion, which generally means those that can satisfy the subject > confirmation. > To that end, I'd like to propose something a little different that I > actually proposed back in February after various discussions with Ron > Monzillo back when I was working up ideas for the AuthnRequest message > (thanks to Gary for digging this up, I had forgotten it): > http://lists.oasis-open.org/archives/security-services/200402/msg00157.html > Specifically, item (4) in that list of suggestions. > Much of that note's proposals has been adopted into the specification > already, like renaming the set of identifier elements and restructuring > SubjectConfirmation into a method plus single Data element. > Item (4) suggested adding an optional sequence of BaseID/NameID/EncryptedID > choices to <SubjectConfirmation>, allowing the issuer to name/identify the > confirming entities in a SAML-consistent way. One might achieve a similar > outcome by, for example, embedding SAML identifiers in a ds:KeyInfo, at > least in the holder-of-key case, but putting this in our schema would allow > it with other kinds of confirmation methods, perhaps with other semantics. > -- 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. -- mailto:gfe@sun.com http://tinyurl.com/yrbj6 "Even if you're on the right track, you'll get run over if you just sit there." -- Will Rogers --
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]