Subject: Re: [OAUTH-WG] Proposed language for section 2.2 on Client Assertions

From: Yaron Goland <[email-masked]>
Date: Mon, 9 Aug 2010 21:15:41 +0000

So how do we resolve if the language goes into the spec?
	Thanks,
		Yaron

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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 9 Aug 2010 21:46:25 -0700

[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

> From: Yaron Goland [mailto:[email-masked]]
> 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
> 
> > > From: [email-masked] [mailto:[email-masked]] On
> > > Behalf Of Brian Campbell
> > > assertions must also define the association between the client_id
> > > and some
> > > If someone sees a cleaner way to deal with client identity on the
> > > user authorization request when using assertions to authenticate the
> client
> > > 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
> > >
> > > > 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.