OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[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]