[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wss] Groups - WSS-SAML-09.pdf uploaded
Ron, I agree that the formulation I proposed for scenario 2b is a sender-vouches use case. If the subject of the assertion is not holder of the key used to sign the message then I don't see any way this can be avoided using the current saml defintions. In addition, at this point I have not seen a compelling need to change the saml definitions, because it appears to me that all the use cases we have discussed seem to me to be implementable with the existing definitions. The way I view the 4 use cases is that we have one hk use case (2a) and 3 sender-vouches use cases: 1a, 1b, 2b. 1a is a degenerate case of the attester and the saa being the same entity with the attester both generating the assertion and signing the message for the user. 1b is a case where there is a separate saml assertion authority (saa) that the attester uses to get attributes about the subject. The attester then signs both the message content and the assertion that came from the saa. The recipient in this case would (as in 1a) have a relationship with the attester and the attester would have a separate relationship with the saa that the recipient in general was not too concerned about, since presumably the attester would take responsibility for all third parties the attester utilized in providing a service to the recipient. 1b is the use case demonstrated in section 5 (Sender-vouches: Signed) in the interop spec. 2b is a case the same players exist as in case 1b, except the recipient in this case relies on the saa for the business relationship. In this context, in order for the recipient to receive messages from the attester, there must be an established relationship between the attester and the saa that the recipient is prepared to utilize in the context of the relationship the recipient has with the saa. One way, as you have suggested in the profile spec, to implement this is to have the saa grant the attester an hk assertion. The recipient can then use the key in this assertion to trace back the relationship to the saa. However, I do not believe that this changes the overall characteristic of this scenario from sender vouches to "hk-based impersonation", although that phrase might be used to characterize the saa-attester relationship. My point is that the saa-attester relationship could be done in other ways as well, without altering the basic nature of this scenario as sender-vouches. One side comment regarding your proposed setup for 1a and 1b is that I am concerned that using the SubjectConfirmation is that according to the saml core the SubjectConfirmation/KeyInfo is defined as: "<ds:KeyInfo> [Optional] 642 An XML Signature [XMLSig] element that specifies a cryptographic key held by the subject." which does not appear to be consistent with the sender-vouches case where the key is held by the attester not the subject. Do you think we are getting any closer on this overall subject, or are there still some missing pieces that need to be addressed? Thanks, Rich > -----Original Message----- > From: Ron Monzillo [mailto:Ronald.Monzillo@sun.com] > Sent: Monday, February 09, 2004 4:48 PM > To: Levinson, Richard > Cc: 'wss@lists.oasis-open.org ' > Subject: Re: [wss] Groups - WSS-SAML-09.pdf uploaded > > > Rich, > > I will try to keep this high level. > > We have been discussing impersonation formulations both wrt > to sv and hok. > > I think we agree on how to use hok when NOT doing > impersonation (i.e. 2a). > > For 2b (hok based impersonation), you view the current SAML > core text which defines the keyInfo used with hok as as > precluding the use of keyInfo within a hok confirmed > SubjectConfirmation Element to carry a key that is NOT held > by the subject of the assertion. > > You have proposed another formulation for this case, which I think > degenerates > to sv, as it depends on authorities NOT giving hok confirmed > assertions to unauthorized (by the authority) impersonators. > > I prefer that the authorization of hok confirmed > impersonators be explicitly defined within the assertion, and > that we correct the language in SAML Core as appropriate to > sustain this use model. I raised this issuse at last week's > SS TC FTF. I think there is the SS TC will accept a less > restrictive interpretation; especially since the hok > confirmation mechanism is not used by any of the existing SS > TC defined profiles. > > We seem to be in agreement on the (1a) sv use case, in which > the attesting entity would include a reference to its key in > SubjectConfirmation, > and then sign the assertion and the msg content. This would > be a departure from what the profile currently requires, in > that the the reference to the subject assertion would move > from SignedInfo/Reference to Signature/KeyInfo. The > attesting entity could either sign the assertion (enveloped) > within the assertion, or via a data reference. The following > diagram employs the data reference approach, as it requires > one less signature creation and > validation, > and seems to more easily generalize to support 1b. > > +-----------------------------+ > +------>| msg content | > | | +-----------------------------+ > | | +-->| subj sv assn |<--+ > | | | | subjconf attester keyInfo | | > | | | +-----------------------------+ | > | | +---| ds ref (subject+attributes) | | > | +-----------------------------+ | > +-------| ds ref (msg content) | | > +-----------------------------+ | > | sig key info |---+ > +-----------------------------+ > > (1b) where the attesting entity is authoritative for the > confirmation key, but not for the other attributes of the > subject seems to be the remaining problematic case. I think > your proposal for this case is to separate the confirmation > key binding (authorized by the attesting > entity) and the other subject attributes (authorized by the assertion > authority) into separate assertions. At least one other > person at the SS TC FTF also advocated this approach, and the > more I think about this, the more I also think it is the > correct approach. > > +--------------------------+ > +------>| msg content | > | +--------------------------+ > | +---->| subj sv assn | > | | | attr env sig | > | | +--------------------------+ > | | +-->| subj sv assn |<--+ > | | | | subjconf attester keyInfo| | > | | | +--------------------------+ | > | | +---| ds ref (subject) | | > | | +--------------------------+ | > | +-----| ds ref (attributes) | | > | +--------------------------+ | > +-------| ds ref (msg content) | | > +--------------------------+ | > | sig key info |---+ > +--------------------------+ > > Does the preceding diagram accurately represent the 2 > assertion approach you are advocating (for 1b)? > > How do you feel about the approach diagrammed for 1a? > > Ron > > Levinson, Richard wrote: > > >Ron, > > > >My replies are interspersed below in response > >to your replies. > > > >Note: I have also truncated some of the earlier > >messages since this is now pretty much self-contained > >starting with your 4 use case scenarios which are now > >at the end. > > > > > > > > > > > >>-----Original Message----- > >>From: Ron Monzillo [mailto:Ronald.Monzillo@Sun.COM] > >>Sent: Wednesday, February 04, 2004 3:02 PM > >>To: Levinson, Richard > >>Cc: 'wss@lists.oasis-open.org ' > >>Subject: Re: [wss] Groups - WSS-SAML-09.pdf uploaded > >> > >> > >> > >> > >>Levinson, Richard wrote: > >> > >> > >> > >>>Ron, > >>> > >>>Based on your previous email and the phone conversation we had > >>>yesterday that clarified the use cases in the email I have > done some > >>>thinking about the ws message structures we can use to > support the 4 > >>>use cases. I have included a first cut at something I think might > >>>work, where the WS Sig KeyInfo always points to an assertion whose > >>>subject is the invocation identity. The structures below > incorporate > >>>the suggestions both of us have had in the course of these > >>> > >>> > >>discussions and > >> > >> > >>>are meant to be a structure within which we can define the > >>> > >>> > >>context of > >> > >> > >>>the use cases and the assertions and signatures necessary > to support > >>>those use cases. Also, the main focus here is probably 2b with the > >>>other use cases leading up to it to provide a common context. > >>> > >>>Below are some defns and some use case scenarios that show the > >>>ws/saml message structures that can support those scenarios. > >>> > >>> Definitions: > >>> > >>> confirmation key: used to verify the signature on the > >>> message content. > >>> > >>> SAML Assertion Authority (saa) > >>> > >>> attr assertion: an assertion issued by the saa that contains > >>> some attributes that refer to the assertion subject. > >>> Basically the attester gets attr assertions from > >>> the saa. > >>> > >>> subject, attester, saa, recipient are set up as follows: > >>> > >>> > >>> +-------> saa > >>> | ^ > >>> | | > >>> V V > >>> subject -> attester -> recipient > >>> > >>> In general, the subject gets authenticated by the saa and > >>> uses that authentication to interact with the attester in > >>> order to deliver messages to the recipient. > >>> > >>>The key is where the Security/Signature/KeyInfo STR (SSK > STR) points. > >>> > >>>In all cases, we presume that subject has established identity > >>>relationship with saa and passes an indicator, such as a > >>> > >>> > >>saml artifact > >> > >> > >>>to the attester to give the attester ability to contact the > >>> > >>> > >>saa to get > >> > >> > >>>assertion related to subject. Also, in all cases the > >>> > >>> > >>attester creates > >> > >> > >>>the ws signature. > >>> > >>>The key difference between 1* and 2* is that for 1* the > >>> > >>> > >>recipient would > >> > >> > >>>rely on a business agreement with the attester for the purpose of > >>>dispute resolution, and in the 2* case the recipient would > rely on a > >>>business agreement with the saa for the purpose of dispute > >>> > >>> > >>resolution. > >> > >> > >>>In 2* the attester basically acts as an authorized agent of > >>> > >>> > >>the saa to > >> > >> > >>>receive messages from users, get an assertion describing > >>> > >>> > >>that user and > >> > >> > >>>packaging up a ws message that is sent to the recipient. > >>> > >>> > >>>1. attesting entity is authoritative for defining the confirmation > >>> key and confirms its knowledge of the key. > >>> > >>> a. the attesting entity is also authoritative for the > >>> contents of the assertion > >>> > >>>1a. attester and saa are the same entity. SSK STR points to > >>> > >>> > >>sv assertion > >> > >> > >>> in message. Assertion contains attester signature with > >>> > >>> > >>verification > >> > >> > >>> key for both the assertion and the content. Recipient relies > >>> on attester. > >>> > >>> > >>> +-------------------+ > >>> | content |<-+ > >>> +-------------------+ | > >>> | subj sv/attr assn | | > >>> +->| attester env sig | | > >>> | +-------------------+ | > >>> | | ws sig ref |--+ > >>> | +-------------------+ > >>> +--| ws sig key info | > >>> +-------------------+ > >>> > >>> > >>> > >>Rich, > >> > >>In the preceding example, I presume the attester is putting a > >>reference > >>to its key > >>somewhere. I guess that key could be in the "attester env > sig", or it > >>could be > >>in the assertion subject conf. I am guessing it would be easier to > >>find/recognize if it > >>is in subject conf, but I am not sure. Moving the attester's > >>key to the > >>signature, would > >>likely open up furthur simplification, as I'll try to depict below: > >> > >>1a. > >> > >> +-------------------+ > >> | content |<---+ > >> +-------------------+ | > >> +--->| subj sv assn | | > >> | | attester env sig | | > >> | | env sig keyValue | | > >> | +-------------------+ | > >> | | ws sig ref |----+ > >> | +-------------------+ > >> +----| ws sig key info | > >> +-------------------+ > >> > >> > > > >My intent was that the attester signature on the assertion would > >implicitly contain the attester key. I do not see any > necessity to put > >it in the SubjectConfirmationData since standard signatures already > >have the KeyInfo in place. We can decide later exactly how > the KeyInfo > >references the key, but I think that is almost application-specific > >since XML signatures provide a wide variety of acceptable techniques. > >Also, since this is a signature enveloped in a saml assertion > >it does not really need to branch back out into the > >WS-Security layer to use SecurityTokenReferences, but that, > >of course, is an option if the application chooses to do it. > > > > > > > >>1b. done with 2 signatures in assertion is depicted below and > >>would require a change to the SAML schema to allow multiple > >>signatures in assertions. This approach would suggest that > >>the signers of the assertion that is also signing the msg > >>content is attesting for the subject in the context of the > >>msg. This approach would depend on the receiver being able to > >>tell which signature contains the key that it should use to > >>validate the signature on the > >>msg content. One simple hueristic might be to expect the > >>attestor signature to be that last one added to the assertion > >> > >> +-------------------+ > >> | content |<---+ > >> +-------------------+ | > >> +--->| subj sv assn | | > >> | | saa env sig | | > >> | | saa sig keyValue | | > >> | | attester env sig | | > >> | | env sig keyValue | | > >> | +-------------------+ | > >> | | ws sig ref |----+ > >> | +-------------------+ > >> +----| ws sig key info | > >> +-------------------+ > >> > >>As I understand your suggestion for 1b (below), you help the > >>receiver understand which signature is which, by separating > >>them in different assertions; > >>.one attester signed assertion naming the subject and > >>demonstrating the attestor key .one saa and attesting entity > >>signed (in different ways) assertion containing the > >>attributes of the subject (and bound by the attesting entity > >>to the msg content). > >> > >> > >> > > > >I had a couple of intents here. One was to avoid doing anything that > >would require changes to the saml specs, such as using a 2nd > signature > >in the saml assertion. > > > >I don't think that multiple assertions is a problem since > the recipient > >can just look thru the message and find what they want among > the signed > >parts, basing their trust on the attester's signature. > > > >The other intent was to make it clear for the recipient to > know who was > >responsible for this message. In particular, by having the attester > >sign the contents of the saa assertion means the attester is > >responsible for the assertion at least as far as the recipient is > >concerned. In this sense it is optional whether the saa > signs the attr > >assertion as far as the recipient is concerned, because the > recipient > >has a primary agreement with the attester. There could be secondary > >agreements, of course, in which case the recipient could complain to > >the saa that it relied on its assertion in the attester context. But > >this would probably also require an agreement between the > attester and > >saa to cover such situations. > > > >In general, I am trying to avoid any presumption about business > >agreements that need to exist, but am trying to set things up so any > >scenario conceivably could be set up between the recipient > and 1 other > >party: the attester in the 1* cases, and the saa in the 2* cases. > > > >It appears to me that the 1b I suggested provides a > framework that does > >not require any spec changes, supports a model that can be put into > >practice with a single business agreement, and is flexible enough to > >support multiple business agreements if that is what the > parties want. > > > > > > > > > >>>1. attesting entity is authoritative for defining the confirmation > >>> key and confirms its knowledge of the key. > >>> > >>> b. The assertion issuer is authoritative for the contents of > >>> the assertion other than the confirmation key. > >>> > >>>1b. attester gets attr assertion from saa. Attester sig > >>> > >>> > >>covers both the > >> > >> > >>> assertion and the content. SSK STR points to sv assertion > >>> in message with same subject as attr assertion. Attester signs > >>> the sv assertion. Recipient relies on attester. > >>> > >>> +-------------------+ > >>> | content |<---+ > >>> +-------------------+ | > >>> | subj attr assn |<-+ | > >>> +-------------------+ | | > >>> | subj sv assn | | | > >>> +->| attester env sig | | | > >>> | +-------------------+ | | > >>> | | ws sig ref |--+ | > >>> | +-------------------+ | > >>> | | ws sig ref |----+ > >>> | +-------------------+ > >>> +--| ws sig key info | > >>> +-------------------+ > >>> > >>> > >>>2. assertion issuer is authoritative for defining the confirmation > >>> key and attesting entity confirms knowledge of key. > >>> > >>> a. issuer establishes confirmation key such that only the > >>> subject of the assertion can satisfy the confirmation > >>> method. > >>> > >>>2a. attester and subject are the same entity. This is pure > >>> > >>> > >>holder-of-key > >> > >> > >>> case. Subject gets hk assertion from saa. Subject uses > >>> > >>> > >>private key > >> > >> > >>> to create sig w SSK STR pointing to hk assertion. > >>> > >>> > >>Recipient relies > >> > >> > >>> on saa. > >>> (this should represent section 3.4.1.3 in WS-SAML Profile V9) > >>> > >>> +-------------------+ > >>> | content |<-+ > >>> +-------------------+ | > >>> | attester hk assn | | > >>> +->| saa env sig | | > >>> | +-------------------+ | > >>> | | ws sig ref |--+ > >>> | +-------------------+ > >>> +--| ws sig key info | > >>> +-------------------+ > >>> > >>> > >>> > >>>2. assertion issuer is authoritative for defining the confirmation > >>> key and attesting entity confirms knowledge of key. > >>> > >>> b. issuer establishes confirmation key such that entities other > >>> than the the subject of the assertion can satisfy the > >>> confirmation method (i.e are authorized to impersonate the > >>> subject). > >>> > >>>2b. attester is authorized by saa to impersonate subjects > >>> > >>> > >>for whom it > >> > >> > >>> supplies assertions. Attester gets attr assertion signed by saa > >>> with saa attributes referring to subject. Attester signs > >>> sv assertion with same subject as attr assertion. > >>> > >>> How does SSK STR point to subject in 2b? Attester could sign > >>> sv assertion with sig that has KeyInfo that points to > >>> attester hk assertion, signed by saa. > >>> > >>> Recipient relies on saa. > >>> > >>> (this should represent section 3.4.2.3 in WS-SAML Profile V9, > >>> except that instead of the WS-KeyInfo pointing to an hk > >>> > >>> > >>assertion > >> > >> > >>> it points to an sv assertion signed by the attester, which has > >>> a pointer to an hk assertion signed by the saa. Also rather than > >>> have ref 1 point to an str to an off message sv assertion, ref 1 > >>> points to an onboard sv attr assn signed by the saa ) > >>> > >>> +-------------------+ > >>> | content |<---+ > >>> +-------------------+ | > >>> | subj attr assn |<-+ | > >>> | saa env sig | | | > >>> +-------------------+ | | > >>> | subj sv assn | | | > >>> +--->| attester env sig | | | > >>> | +--| attester key info | | | > >>> | | +-------------------+ | | > >>> | | | attester hk assn | | | > >>> | +->| saa env sig | | | > >>> | +-------------------+ | | > >>> | | ws sig ref 1 |--+ | > >>> | +-------------------+ | > >>> | | ws sig ref 2 |----+ > >>> | +-------------------+ > >>> +----| ws sig key info | > >>> +-------------------+ > >>> > >>> > >>> > >>> > >>Focusing on your proposed 2b formulation, I can see that the > >>saa is authorizing the contents of the first assertion (i.e. > >>the attributes that pertain to the subject), and the key > >>binding of the attester (in the third assertion). > >> > >>I don't see how the saa is authorizing the impersonation > >>of the subject of the first and second assertions, by the > >>subject of the third assertion. > >> > >>It would seem that the second assertion would need to be > signed by the > >>saa for this to be the case. > >> > >>Maybe you can clarify this. > >> > >> > >> > > > >My thinking on this is that by the saa granting an hk > assertion to the > >attester, the saa is implicitly allowing the attester to use the > >attester key to sign messages. In particular, the saa is authorizing > >the attester to sign sv assertions containing subjects for whom the > >attester has acquired an attr assertion from the saa by means of the > >artifact the subject sent to the attester. > > > >The action of the attester would be after acquiring the attr > assertion > >for the subject from the saa, the attester would create a simple sv > >subject assertion identifying the same subject, and the signature on > >the sv assertion would point to the attester hk assertion > which it got > >from the saa to authorize such actions. > > > >When the recipient gets the message, the recipient looks to > the ws sig > >key info to find the confirmation key and the invocation > identity which > >is the subject. The ws key info points the recipient to the subj sv > >assn to get the subject. The assertion is signed by the > attester, and > >the KeyInfo of that sig points to the hk assertion which > contains the > >attester key authorized by the saa. > > > >The net of this, I think, is that the attester effectively becomes > >an authorized agent of the saa. And for the purposes of business > >agreements the recipient would deal with the saa and the attester > >could recede to be simply a pretty much transparent intermediary > >subject to controls by the saa. > > > > > > > > > >>Drawing a similar diagram for what the STP currently > >>profiles, the formulation would look as follows: > >> > >> +-------------------+ > >> | content |<---+ > >> +-------------------+ | > >> +--->| subj hk assn | | > >> | | subConf keyInfo |--+ | > >> | | saa env sig | | | > >> | +-------------------+ | | > >> | | attester hk assn |<-+ | > >> | | subConf keyValue | | > >> | | saa env sig | | > >> | +-------------------+ | > >> | | ws sig ref |----+ > >> | +-------------------+ > >> +----| ws sig key info | > >> +-------------------+ > >> > >>which is a variation of the non-impersonation hok case (as > >>currently profiled). The variation is that an assertion of > >>the attesting enity would be referenced from the subject assertion. > >> > >> +-------------------+ > >> | content |<---+ > >> +-------------------+ | > >> +--->| subj hk assn | | > >> | | subConf keyValue | | > >> | | saa env sig | | > >> | +-------------------+ | > >> | | ws sig ref |----+ > >> | +-------------------+ > >> +----| ws sig key info | > >> +-------------------+ > >> > >>Ron > >> > >> > >> > > > >The problem I see with these formulations is that subject > assertion is > >an hk assertion, but the content is signed by the attester > who is not > >the subject. As I understand the 2b reqt: > > > > b. issuer (< saa, I assume >) establishes confirmation key such > > that entities other than the subject (< the attester, I > > assume is the "entity other than the subject" >) of the > > assertion can satisfy the confirmation method (i.e are > > authorized to impersonate the subject). > > > >I interpret this to mean that attester has the confirmation key and > >that the subject does not need to enter a key into this > scenario, i.e. > >this is what sender-vouches is intended for. And the subject could > >initiate this scenario with an artifact from a browser. > > > >Also the Saml binding spec section 5.1 says this about holder of > >key: > > > > "The subject of the assertion is the party that can > > demonstrate that it is the holder of the key." > > > >I interpret this to mean that subject should be the one showing they > >have possession of a particular key, but it is the attester, > I believe, > >that is doing the signing in 2b. > > > >Maybe there is still some context here that I am missing, > which would > >not surprise me since I suspect there are several possible ways that > >these reqts might be interpreted and met. > > > > Rich > > > > > > > > > > > >>>Let me know if you think this moves us closer to a > >>>framework that captures the requirements. > >>> > >>> Thanks, > >>> > >>> Rich > >>> > >>> > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: Ron Monzillo [mailto:Ronald.Monzillo@Sun.COM] > >>>>Sent: Monday, February 02, 2004 1:24 PM > >>>>To: Levinson, Richard > >>>>Cc: 'wss@lists.oasis-open.org ' > >>>>Subject: Re: [wss] Groups - WSS-SAML-09.pdf uploaded > >>>> > >>>> > >>>> > >>>>Levinson, Richard wrote: > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>Ron, > >>>>> > >>>>>I have reviewed the rest of your comments and I believe > >>>>>we are in basic agreement on the principles involved, > >>>>>and what it really boils down to is how to implement > >>>>> > >>>>> > >>>>> > >>>>> > >>>>sender-vouches in > >>>> > >>>> > >>>> > >>>> > >>>>>a recognizable and efficient manner. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>Rich, > >>>> > >>>>Sounds good. > >>>> > >>>>As I mentioned a few msgs ago, it is difficult with sv, to set > >>>>things up such that the attesting entity is authoritative for the > >>>>key binding, but not for the other contents of the > assertion. Maybe > >>>>your proposed use of the assertion signature, opens up a > new way to > >>>>accomplish this. > >>>> > >>>>IMO, the important (msg authentication) use cases are as follows: > >>>> > >>>>1. attesting entity is authoritative for defining the > confirmation > >>>>key and > >>>> confirms its knowledge of the key. > >>>> a. the attesting entity is also authoritative for the > >>>> > >>>> > >>contents of > >> > >> > >>>>the assertion > >>>> b. The assertion issuer is authoritative for the > >>>> > >>>> > >>contents of the > >> > >> > >>>>assertion > >>>> other than the confirmation key. > >>>> > >>>>2. assertion issuer is authoritative for defining the > confirmation > >>>>key and attesting > >>>> entity confirms knowledge of key. > >>>> a. issuer establishes confirmation key such that only the > >>>>subject of > >>>>the assertion > >>>> can satisfy the confirmation method. > >>>> b. issuer establishes confirmation key such that entities > >>>>other than > >>>>the > >>>> the subject of the assertion can satisfy the > >>>> > >>>> > >>confirmation method > >> > >> > >>>>(i.e are authorized > >>>> to impersonate the subject). > >>>> > >>>>Maybe there should also be variants of both 2a, and 2b, > that allow > >>>>the subject > >>>>of the assertion to be authoritative for some or all of the > >>>> > >>>> > >>assertion > >> > >> > >>>>content > >>>>except the definition of the confirmation key. > >>>> > >>>>Any comments on the use cases? > >>>> > >>>>I suspect if we settle on use cases, it will be easier for us to > >>>>improve the related profile specific details. > >>>> > >>>>BTW, the SAML schema doesn't seem to allow multiple > signatures to be > >>>>included in the assertion. If it did, maybe the > "difficult" sv case > >>>>I noted above, which is case 1b in the list of use cases, > could be > >>>>handled (in the signature approach you proposed) by the attesting > >>>>entity adding a second signature to the assertion (using > its key as > >>>>keyInfo). > >>>> > >>>>Independent of how many signatures there are in the > assertion, the > >>>>receiver of a sv confirmed assertion would have to > understand that > >>>>the msg signature key must be a key used to create a signature > >>>>(within the assertion). > >>>> > >>>>I think the signature approach is interesting, but if we > accept the > >>>>use cases enumerated above, I think we should think a bit harder > >>>>about how we might allow an attesting entity, other than the > >>>>assertion issuer, to authorize one or more confirmation keys in > >>>>subject confirmation. > >>>> > >>>>I realize that doing this would call into question SAML's > definition > >>>>of KeyInfo in SubjectConfirmation, where the identified key is > >>>>supposed to be "held by the subject". > >>>> > >>>> > >>>>Ron > >>>> > >>>> > >>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>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/wss/members/leav > >>>>> > >>>>> > >>>>> > >>>>> > >>>>e_workgrou > >>>> > >>>> > >>>> > >>>> > >>>>>p.php. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>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/wss/members/leav > >>> > >>> > >>e_workgrou > >> > >> > >>>p.php. > >>> > >>> > >>> > >>> > >>> > > > >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/wss/members/leav > e_workgrou > >p.php. > > > > > > > > > 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/wss/members/leave _workgroup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]