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. 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? 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
