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
