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
