The client_id of a public client is self asserted in the request to the token endpoint, the authorization server can reject it if it is wrong without relying on it to be correct.
I agree that the word identify in both places seems like a contradiction on the surface. 4.1.3 could be softened from 'identified by' to 'indicated by' For your first point, are there public clients without client_id? If so how would a user revoke access? One reading of 4.3 step c is that the server must authenticate the client. If the intent really is to allow totally anonymous clients then I see your point. Thoughts from others? John B. Sent from my iPad On 2012-07-25, at 12:07 PM, Brian Campbell <[email protected]> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
