[Seems like the only way is for me to say this] I am going to include this text in -11 unless someone objects (and explains why).
EHL > -----Original Message----- > From: Yaron Goland [mailto:yar...@microsoft.com] > Sent: Monday, August 09, 2010 2:16 PM > To: Eran Hammer-Lahav; Brian Campbell; oauth > Subject: RE: [OAUTH-WG] Proposed language for section 2.2 on Client > Assertions > > So how do we resolve if the language goes into the spec? > Thanks, > Yaron > > > -----Original Message----- > > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > > Of Eran Hammer-Lahav > > Sent: Tuesday, July 27, 2010 8:36 AM > > To: Brian Campbell; oauth > > Subject: Re: [OAUTH-WG] Proposed language for section 2.2 on Client > > Assertions > > > > Makes sense. Personally, I don't have any preference on including it or not. > > > > EHL > > > > > -----Original Message----- > > > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On > > > Behalf Of Brian Campbell > > > Sent: Tuesday, July 27, 2010 5:49 AM > > > To: oauth > > > Subject: Re: [OAUTH-WG] Proposed language for section 2.2 on Client > > > Assertions > > > > > > A client_id parameter would still be presented in the end user > > > authorization request. The text Brian E. quoted is what mandates any > > > specifications/documents/agreements that define how to use client > > > assertions must also define the association between the client_id > > > and some > > > field(s) in the assertion. > > > > > > If someone sees a cleaner way to deal with client identity on the > > > user authorization request when using assertions to authenticate the > client > > > to the token endpoint, please speak up and lets discuss it. However, > > > in general I do feel it's important to have better defined support > > > in the core OAuth spec to allow for client authentication methods > > > beyond just password. > > > > > > -Brian > > > > > > On Mon, Jul 26, 2010 at 5:18 PM, Brian Eaton <bea...@google.com> > wrote: > > > > On Mon, Jul 26, 2010 at 4:11 PM, Eran Hammer-Lahav > > > <e...@hueniverse.com> wrote: > > > >> How do you link the client_id using in the authorization endpoint > > > >> with the > > > client assertion using in the token endpoint? > > > > > > > > In theory: > > > > > > > > "any document that defines how to use an assertion of a particular > > > > type with OAuth 2.0 MUST define how to map the value from the > > > > client_id parameter in the authorization request to a value or > > > > values in the assertion subsequently submitted with the code to > > > > obtain an access token." > > > > > > > > In practice: you do it the same way you handle any kind of > > > > identity assertion. There is some combination of issuer and > > > > subject and signature that ends up producing an identity that you trust. > > > > _______________________________________________ > > > > OAuth mailing list > > > > OAuth@ietf.org > > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
