In thinking some more about this. Affecting grants other than code was unintentional, and due to document structure.
I will talk to Brian today and come up with some wording that could go to the RFC editor to make that clear. John B. On 2012-07-25, at 12:07 PM, Brian Campbell wrote: > In -29 the quoted text below was introduced to §3.2.1 Client > Authentication [1] to protect clients against authorization code > substitution. However, the text's placement under 3.2. Token Endpoint > [2] and some of the wording suggest that public clients must use > client_id on all requests to the token endpoint, regardless of grant > type, even though the change was introduced only to mitigate an issue > with the authentication code. > > "A public client that was not issued a client password MUST use the > "client_id" request parameter to identify itself when sending > requests to the token endpoint. This allows the authorization server > to ensure that the code was issued to the same client. Sending > "client_id" prevents the client from inadvertently accepting a code > intended for a client with a different "client_id". This protects > the client from substitution of the authentication code. (It > provides no additional security for the protected resource.)" > > Was the change intended to be that broad? I think it goes too far. > There are cases, like extension grants and even the resource owner > credentials grant type, where it's useful to allow requests from > unidentified clients. > > Could that text (or the spirit of it) be moved somewhere under the > specific sections on the Authorization Code Grant so that it only > applies to that grant type? > > > A somewhat related issue is the following text from §2.3. Client > Authentication > > "the authorization server MUST NOT rely > on public client authentication for the purpose of identifying the > client." > > which seems to contradict the text from §3.2.1 above as well as the > following from 4.1.3. Access Token Request [3] > > "o ensure the authorization code was issued to the authenticated > confidential client or to the public client identified by the > "client_id" in the request, > > Should the text in §2.3 be loosened or somehow qualified so it doesn't > read like a contradiction? > > Thanks, > Brian > > > [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-30#section-3.2.1 > [2] http://tools.ietf.org/html/draft-ietf-oauth-v2-30#section-3.2 > [3] http://tools.ietf.org/html/draft-ietf-oauth-v2-30#section-2.3 > [3] http://tools.ietf.org/html/draft-ietf-oauth-v2-30#section-4.1.3 > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
