Re: [OAUTH-WG] treatment of client_id for authentication and identification

New tweak:

            The security ramifications of allowing unauthenticated access by public clients to the
            token endpoint, as well as the issuance of refresh tokens to public clients MUST be
            taken into consideration.

EHL

> -----Original Message-----
> From: Richer, Justin P. [mailto:jricher@mitre.org]
> Sent: Friday, August 19, 2011 4:56 AM
> To: Eran Hammer-Lahav; Lu, Hui-Lan (Huilan); Brian Campbell
> Cc: oauth
> Subject: RE: [OAUTH-WG] treatment of client_id for authentication and
> identification
> 
> I find the original text clearer, myself.
> 
>  -- Justin
> ________________________________________
> From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Eran
> Hammer-Lahav [eran@hueniverse.com]
> Sent: Thursday, August 18, 2011 5:16 PM
> To: Lu, Hui-Lan (Huilan); Brian Campbell
> Cc: oauth
> Subject: Re: [OAUTH-WG] treatment of client_id for authentication and
> identification
> 
> > -----Original Message-----
> > From: Lu, Hui-Lan (Huilan) [mailto:huilan.lu@alcatel-lucent.com]
> > Sent: Thursday, August 18, 2011 1:45 PM
> > To: Eran Hammer-Lahav; Brian Campbell
> > Cc: oauth
> > Subject: RE: [OAUTH-WG] treatment of client_id for authentication and
> > identification
> >
> > Eran Hammer-Lahav wrote:
> > > Added to 2.4.1:
> > >
> > > client_secret
> > >                 REQUIRED. The client secret. The client MAY omit the
> > > parameter if the client secret
> > >                 is an empty string.
> >
> > I would suggest rewording the above as follows:
> > client_secret
> >       REQUIRED unless it is an empty string. The client secret.
> 
> "unless its value is an empty string". Do people read this new text to mean
> OPTIONAL if not empty?
> 
> > > Added to 3.2.1:
> > >
> > >             A public client that was not issued a client password MAY use the
> > >             'client_id' request parameter to identify itself when sending
> > >             requests to the token endpoint.
> >
> > It is difficult to parse the last sentence of 3.2.1: "The security
> > ramifications of allowing unauthenticated access by public clients to
> > the token endpoint MUST be considered, as well as the issuance of
> > refresh tokens to public clients, their scope, and lifetime."
> >
> > I think it should be rewritten and reference relevant parts of
> > security considerations.
> 
> Text?
> 
> EHL
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth