> -----Original Message----- > From: Brian Campbell [mailto:bcampb...@pingidentity.com] > Sent: Monday, July 25, 2011 10:39 AM > To: Eran Hammer-Lahav > Cc: oauth > Subject: Re: [OAUTH-WG] treatment of client_id for authentication and > identification > > I'm asking from both an implementation perspective as well as the spec > perspective. > > On the spec side, draft-ietf-oauth-assertions will deal with client_id and > while it's currently required I'd guess it will become optional or even > forbidden.
Can't help with this one. > On the implementation side, let me make sure I understand. Clients without > a secret must present client_id on token endpoint requests and > must use only that method of identifying themselves? HTTP Basic and > other means of client authentication are reserved for clients that actually > have some secret to authenticate with? The client_id is currently only defined for password authentication on the token endpoint. If you are using Basic or any other form of authentication (or no authentication at all), you are not going to use the client_id parameter. EHL > > > On Mon, Jul 25, 2011 at 10:50 AM, Eran Hammer-Lahav > <e...@hueniverse.com> wrote: > > It shouldn't. You are still allowed to reuse client_id outside the specific > password credentials use case. Just make sure the way the parameter is > defined in v2 is consistent. > > > > EHL > > > >> -----Original Message----- > >> From: Brian Campbell [mailto:bcampb...@pingidentity.com] > >> Sent: Monday, July 25, 2011 9:28 AM > >> To: Eran Hammer-Lahav > >> Cc: oauth > >> Subject: Re: [OAUTH-WG] treatment of client_id for authentication and > >> identification > >> > >> How should HTTP Basic be used for a client not in possession of a > >> client secret? > >> > >> > >> > >> On Mon, Jul 25, 2011 at 10:25 AM, Eran Hammer-Lahav > >> <e...@hueniverse.com> wrote: > >> > client_id is only required on the authorization endpoint, not the > >> > token > >> endpoint. -18 cleaned up how the document talked about client > >> authentication in general. So you should remove client_id from your > >> draft and instead mention client authentication (if appropriate). > >> > > >> > EHL > >> > > >> >> -----Original Message----- > >> >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On > >> >> Behalf Of Brian Campbell > >> >> Sent: Monday, July 25, 2011 7:02 AM > >> >> To: oauth > >> >> Subject: [OAUTH-WG] treatment of client_id for authentication and > >> >> identification > >> >> > >> >> I need to revisit a question that came up about two months ago. I > >> >> thought I had a clear understanding of when client_id was and > >> >> wasn't included in access token requests but drafts 18/19 seemed > >> >> to have changed things (or my understanding of 16 was wrong). > >> >> > >> >> > >> >> The question is, when is client_id a required parameter on > >> >> requests to the token endpoint and when can/should it be omitted? > >> >> > >> >> In -16 I was under the impression that client_id was always to be > >> >> included even when using HTTP Basic or other means of > authentication. > >> >> See http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-3.1 > >> >> and > >> >> http://www.ietf.org/mail-archive/web/oauth/current/msg06328.html > for example. > >> >> > >> >> But the text and examples in -18/-19 would suggest that client_id > >> >> is to be omitted when using HTTP Basic. Text in > >> >> http://tools.ietf.org/html/draft-ietf-oauth-v2-19#section-2.4.1 > >> >> and example in > >> >> http://tools.ietf.org/html/draft-ietf-oauth-v2-19#section-4.1.3 > >> >> > >> >> I don't have a strong preference for either direction but do feel > >> >> it needs to be more explicitly spelled out. Scenarios that should > >> >> be accounted for are, for both clients in possession of a client > >> >> password and clients without, using client_id/client_secret, using > >> >> HTTP Basic and using other means of authentication/identification. > >> >> _______________________________________________ > >> >> 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
