Yes, the intent is to allow totally anonymous clients. There are cases where that is very useful and where user revocation isn't applicable (i.e. only an access token is issued).
The changes in -29 were introduced to protect clients against authorization code substitution. Those changes are breaking changes to the code flow (in some cases) but it was felt that the security benefits warranted the change even this late in the process. However, by placing that text in §3.2.1, and having it apply to all requests to the token endpoint, the change impacts a lot more than just the authorization code grant and introduces breaking changes to functionality not subject to the authorization code substitution issue that the change was made to address. That inadvertent breaking changes isn't just theoretical either. It breaks https://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ and https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/ - see the example at the end of section 4 of each for requests to the token endpoint that legitimately have no client identification. The change also breaks features that have been available in our product for nearly a year (and presumably other products/services implementations as well). I realize it's late in the process to bring this up but the aforementioned change was also introduced very late and had a broader impact than what was intended. I'd strongly suggest that the text in the last paragraph of §3.2.1 be moved (and slightly adjusted for context) into §4.1.3 right after, or as part of, the paragraph about client authentication. And the the last paragraph of §3.2.1 should be reverted to what it was in -28. At this stage I don't know how that kind of thing is best handled - an RFC editor note? But I believe it needs to be taken care of somehow before publication. Thanks, Brian On Wed, Jul 25, 2012 at 4:21 PM, John Bradley <[email protected]> wrote: > 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 _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
