Re: [OAUTH-WG] Proposed note to RFC Editor
Hi John, I would expect sending a client_id is a MUST for public clients in the authz code grant type. That's not how I read the proposed text for section 3.1. regards, Torsten. John Bradley schrieb: The changes introduced in Draft 29 had unintended consequences on parts of the spec caused by Sec 4.3, 4.4 and 6 referencing Sec 3.2.1 as part of client authentication. This change restricts the requirement to send client_id to only Sec 4.1.4 for clients that are not authenticated per Sec 3.2.1 Section 3.2.1 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.) Change to A client MAY use the "client_id" request parameter to identify itself when sending requests to the token endpoint. In the "authorization_code" grant_type request to the token endpoint, an unauthenticated client sends "client_id" to prevent itself 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.) ** This allows any client to send client ID and explains the threat to code. 4.1.3. Access Token Request Add client_id REQUIRED if the client is NOT authenticating with the authorization server as described in Section 3.2.1 ** This makes client_id only REQUIRED for the code flow if the client is not otherwise authenticated. Change ensure the authorization code was issued to the authenticated confidential client or to the public client identified by the "client_id" in the request, To: ensure the authorization code was issued to the authenticated confidential client, or if the client is public, ensure the code was issued to "client_id" in the request, ** That removes the implication of authentication. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Proposed note to RFC Editor
Understood, however at this point major reworking of the token endpoint is going to have to wait on the next release of OAuth. I suspect that there will eventually be a 2.1. For now this should let us close the book on this 3 year odyssey and address some of the other issues like JWT etc. John B. On 2012-07-26, at 6:29 PM, Manger, James H wrote: >>> The changes introduced in Draft 29 had unintended consequences on >>> parts of the spec caused by Sec 4.3, 4.4 and 6 referencing Sec 3.2.1 >>> as part of client authentication. > >> this change breaks >> https://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ > and https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/ > > > An underlying cause of this issue is that a single URI (the token endpoint) > is overloaded for a dozen different tasks by a bunch of specs — and the list > of tasks is still growing. > > OAuth2 has built a RPC-style API, but almost pretends not to have done so by > using grant_type names/URIs and a parameter registry instead of a more formal > SOAP-style structure. > > John’s proposed note to the RFC editor should address the immediate issue. > Perhaps future enhancements, though, could consider a more RESTful approach. > I think that would significantly clarify some of the complexities OAuth2 > grapples with and minimise clashes between the various flows. > > -- > James Manger ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Proposed note to RFC Editor
>> The changes introduced in Draft 29 had unintended consequences on >> parts of the spec caused by Sec 4.3, 4.4 and 6 referencing Sec 3.2.1 >> as part of client authentication. > this change breaks > https://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ and https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/ An underlying cause of this issue is that a single URI (the token endpoint) is overloaded for a dozen different tasks by a bunch of specs — and the list of tasks is still growing. OAuth2 has built a RPC-style API, but almost pretends not to have done so by using grant_type names/URIs and a parameter registry instead of a more formal SOAP-style structure. John’s proposed note to the RFC editor should address the immediate issue. Perhaps future enhancements, though, could consider a more RESTful approach. I think that would significantly clarify some of the complexities OAuth2 grapples with and minimise clashes between the various flows. -- James Manger ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Proposed note to RFC Editor
+1 =nat via iPhone On 2012/07/27, at 7:36, Dick Hardt wrote: > +1 > > On Jul 26, 2012, at 3:06 PM, Mike Jones wrote: > >> +1 >> >> Given that the current spec inadvertently broke both the SAML profile and >> JWT profile, I believe we need to make these changes. >> >>-- Mike >> >> -Original Message- >> From: Brian Campbell [mailto:bcampb...@pingidentity.com] >> Sent: Thursday, July 26, 2012 1:56 PM >> To: John Bradley >> Cc: oauth WG; Mike Jones >> Subject: Re: Proposed note to RFC Editor >> >> I agree with the proposed changes and they do adequately address the >> concerns I raised in a previous message about the unintended breaking >> changes introduced in 29. Thanks for writing that up John. >> >> On Thu, Jul 26, 2012 at 2:33 PM, John Bradley wrote: >>> The changes introduced in Draft 29 had unintended consequences on >>> parts of the spec caused by Sec 4.3, 4.4 and 6 referencing Sec 3.2.1 >>> as part of client authentication. >>> >>> This change restricts the requirement to send client_id to only Sec >>> 4.1.4 for clients that are not authenticated per Sec 3.2.1 >>> >>> >>> >>> >>> Section 3.2.1 >>> >>> >>> 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.) >>> >>> >>> Change to >>> >>> A client MAY use the "client_id" request parameter to identify itself >>> when sending requests to the token endpoint. >>> In the "authorization_code" grant_type request to the token endpoint, >>> an unauthenticated client sends "client_id" to prevent itself 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.) >>> >>> >>> ** This allows any client to send client ID and explains the threat to code. >>> >>> >>> 4.1.3. Access Token Request >>> >>> >>> >>> Add >>> client_id >>> REQUIRED if the client is NOT authenticating with the >>> authorization server as described in Section 3.2.1 >>> >>> >>> >>> >>> ** This makes client_id only REQUIRED for the code flow if the client >>> is not otherwise authenticated. >>> >>> Change >>> >>> >>>ensure the authorization code was issued to the authenticated >>>confidential client or to the public client identified by the >>>"client_id" in the request, >>> >>> >>> To: >>>ensure the authorization code was issued to the authenticated >>>confidential client, or if the client is public, ensure the code was >>>issued to "client_id" in the request, >>> >>> >>> ** That removes the implication of authentication. >>> >>> >>> >> >> >> ___ >> 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 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Proposed note to RFC Editor
+1 On Jul 26, 2012, at 3:06 PM, Mike Jones wrote: > +1 > > Given that the current spec inadvertently broke both the SAML profile and JWT > profile, I believe we need to make these changes. > > -- Mike > > -Original Message- > From: Brian Campbell [mailto:bcampb...@pingidentity.com] > Sent: Thursday, July 26, 2012 1:56 PM > To: John Bradley > Cc: oauth WG; Mike Jones > Subject: Re: Proposed note to RFC Editor > > I agree with the proposed changes and they do adequately address the concerns > I raised in a previous message about the unintended breaking changes > introduced in 29. Thanks for writing that up John. > > On Thu, Jul 26, 2012 at 2:33 PM, John Bradley wrote: >> The changes introduced in Draft 29 had unintended consequences on >> parts of the spec caused by Sec 4.3, 4.4 and 6 referencing Sec 3.2.1 >> as part of client authentication. >> >> This change restricts the requirement to send client_id to only Sec >> 4.1.4 for clients that are not authenticated per Sec 3.2.1 >> >> >> >> >> Section 3.2.1 >> >> >> 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.) >> >> >> Change to >> >> A client MAY use the "client_id" request parameter to identify itself >> when sending requests to the token endpoint. >> In the "authorization_code" grant_type request to the token endpoint, >> an unauthenticated client sends "client_id" to prevent itself 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.) >> >> >> ** This allows any client to send client ID and explains the threat to code. >> >> >> 4.1.3. Access Token Request >> >> >> >> Add >> client_id >>REQUIRED if the client is NOT authenticating with the >>authorization server as described in Section 3.2.1 >> >> >> >> >> ** This makes client_id only REQUIRED for the code flow if the client >> is not otherwise authenticated. >> >> Change >> >> >> ensure the authorization code was issued to the authenticated >> confidential client or to the public client identified by the >> "client_id" in the request, >> >> >> To: >> ensure the authorization code was issued to the authenticated >> confidential client, or if the client is public, ensure the code was >> issued to "client_id" in the request, >> >> >> ** That removes the implication of authentication. >> >> >> > > > ___ > 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
Re: [OAUTH-WG] Proposed note to RFC Editor
+1 Given that the current spec inadvertently broke both the SAML profile and JWT profile, I believe we need to make these changes. -- Mike -Original Message- From: Brian Campbell [mailto:bcampb...@pingidentity.com] Sent: Thursday, July 26, 2012 1:56 PM To: John Bradley Cc: oauth WG; Mike Jones Subject: Re: Proposed note to RFC Editor I agree with the proposed changes and they do adequately address the concerns I raised in a previous message about the unintended breaking changes introduced in 29. Thanks for writing that up John. On Thu, Jul 26, 2012 at 2:33 PM, John Bradley wrote: > The changes introduced in Draft 29 had unintended consequences on > parts of the spec caused by Sec 4.3, 4.4 and 6 referencing Sec 3.2.1 > as part of client authentication. > > This change restricts the requirement to send client_id to only Sec > 4.1.4 for clients that are not authenticated per Sec 3.2.1 > > > > > Section 3.2.1 > > > 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.) > > > Change to > > A client MAY use the "client_id" request parameter to identify itself > when sending requests to the token endpoint. > In the "authorization_code" grant_type request to the token endpoint, > an unauthenticated client sends "client_id" to prevent itself 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.) > > > ** This allows any client to send client ID and explains the threat to code. > > > 4.1.3. Access Token Request > > > > Add > client_id > REQUIRED if the client is NOT authenticating with the > authorization server as described in Section 3.2.1 > > > > > ** This makes client_id only REQUIRED for the code flow if the client > is not otherwise authenticated. > > Change > > > ensure the authorization code was issued to the authenticated > confidential client or to the public client identified by the > "client_id" in the request, > > > To: > ensure the authorization code was issued to the authenticated > confidential client, or if the client is public, ensure the code was > issued to "client_id" in the request, > > > ** That removes the implication of authentication. > > > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Proposed note to RFC Editor
I agree with the proposed changes and they do adequately address the concerns I raised in a previous message about the unintended breaking changes introduced in 29. Thanks for writing that up John. On Thu, Jul 26, 2012 at 2:33 PM, John Bradley wrote: > The changes introduced in Draft 29 had unintended consequences on parts of > the spec caused by > Sec 4.3, 4.4 and 6 referencing Sec 3.2.1 as part of client authentication. > > This change restricts the requirement to send client_id to only Sec 4.1.4 > for clients that are not authenticated per Sec 3.2.1 > > > > > Section 3.2.1 > > > 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.) > > > Change to > > A client MAY use the "client_id" request parameter to identify itself > when sending requests to the token endpoint. > In the "authorization_code" grant_type request to the token endpoint, > an unauthenticated client sends "client_id" to prevent itself 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.) > > > ** This allows any client to send client ID and explains the threat to code. > > > 4.1.3. Access Token Request > > > > Add > client_id > REQUIRED if the client is NOT authenticating with the > authorization server as described in Section 3.2.1 > > > > > ** This makes client_id only REQUIRED for the code flow if the client is not > otherwise authenticated. > > Change > > > ensure the authorization code was issued to the authenticated > confidential client or to the public client identified by the > "client_id" in the request, > > > To: > ensure the authorization code was issued to the authenticated > confidential client, or if the client is public, ensure the code was > issued to "client_id" in the request, > > > ** That removes the implication of authentication. > > > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Proposed note to RFC Editor
The changes introduced in Draft 29 had unintended consequences on parts of the spec caused by Sec 4.3, 4.4 and 6 referencing Sec 3.2.1 as part of client authentication. This change restricts the requirement to send client_id to only Sec 4.1.4 for clients that are not authenticated per Sec 3.2.1 Section 3.2.1 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.) Change to A client MAY use the "client_id" request parameter to identify itself when sending requests to the token endpoint. In the "authorization_code" grant_type request to the token endpoint, an unauthenticated client sends "client_id" to prevent itself 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.) ** This allows any client to send client ID and explains the threat to code. 4.1.3. Access Token Request Add client_id REQUIRED if the client is NOT authenticating with the authorization server as described in Section 3.2.1 ** This makes client_id only REQUIRED for the code flow if the client is not otherwise authenticated. Change ensure the authorization code was issued to the authenticated confidential client or to the public client identified by the "client_id" in the request, To: ensure the authorization code was issued to the authenticated confidential client, or if the client is public, ensure the code was issued to "client_id" in the request, ** That removes the implication of authentication. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] overreach of the scope of when client_id is required from public clients?
I agree that we need to mitigate this unintended side effect of the change. Stephen and chairs, I don't know where we are with the RFC editor submission process, but if you need to do anything to put a hold on that, it might be a good idea. The fact that this change breaks https://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ and https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/ is pretty clear evidence that we can't just let this go. Thanks for looking into a mitigating change, John. -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley Sent: Thursday, July 26, 2012 9:39 AM To: Brian Campbell Cc: oauth Subject: Re: [OAUTH-WG] overreach of the scope of when client_id is required from public clients? 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 > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth ___ 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
Re: [OAUTH-WG] overreach of the scope of when client_id is required from public clients?
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 > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] overreach of the scope of when client_id is required from public clients?
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 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 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-ie
