[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:[email protected]] > 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: [email protected] [mailto:[email protected]] 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: [email protected] [mailto:[email protected]] 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 <[email protected]> > wrote: > > > > On Mon, Jul 26, 2010 at 4:11 PM, Eran Hammer-Lahav > > > <[email protected]> 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 > > > > [email protected] > > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > _______________________________________________ > > > OAuth mailing list > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > > OAuth mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
