I believe we should adopt this revised text.
-- Mike
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of John
Bradley
Sent: Sunday, July 01, 2012 2:22 PM
To: oauth@ietf.org WG
Subject: [OAUTH-WG] New Text for Sec
+1
Phil
On 2012-07-02, at 8:17, Mike Jones michael.jo...@microsoft.com wrote:
I believe we should adopt this revised text.
-- Mike
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
John Bradley
Sent:
I'm generally OK with the change, though it does change One problem I
have with this is that it can give a false sense of security about the
information being sent to the token endpoint and how trustworthy it is.
A client_id is public knowledge, and so someone impersonating a client
on the
Using the code flow with a public client in itself creates a false sense of
security.
I suspect that most developers think public == implicit and confidential ==
code.
While it is clear that there is a whole group of native apps that are public
using the code flow.
For those clients the
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol Working Group of
the IETF.
Title : Assertion Framework for OAuth 2.0
Author(s) : Brian Campbell
Draft -04 of the Assertion Framework for OAuth 2.0 (now with a new name!)
has been published. This draft includes significant changes that attempt to
incorporate comments and proposed new text from the document shepherd[1].
The new draft is available at
I sent some text to the list on public clients using the code flow.
If that gets accepted then I think this should be the additional security
consideration to address the issues eased by the MS security researchers and
myself.
Alternate title suggestion #1 Resource owner Impersonation
Not sure why this has to be a MUST in section 3.2.1 as the token endpoint has
to the choice to reject it either way (provided or not)
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of John
Bradley
Sent: Sunday, July 01, 2012 2:22 PM
To: oauth@ietf.org WG
Subject:
While the client may be forced to provide the client_id there are no
requirements for the endpoint to process the client_id (or how that is done) so
not sure what good the change actually does
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Justin Richer
Sent: Monday,
The token endpoint can always reject it.
The issue is if the client can count on it being rejected if the client_id is
wrong.
If the Authorization server is allowed to not to compare the client_id to the
one it issued the token to there is no point in making the change.
As Justin pointed out
The change to 4.1.3 requires the endpoint to process it. At least as much as
the the text for the Confidential client is requiring it.
John B.
On 2012-07-02, at 5:45 PM, Anthony Nadalin wrote:
While the client may be forced to provide the client_id there are no
requirements for the endpoint
I read 4.1.3 as the client_id just has to have been issued to a (or any)
public client
From: John Bradley [mailto:ve7...@ve7jtb.com]
Sent: Monday, July 02, 2012 2:54 PM
To: Anthony Nadalin
Cc: Justin Richer; oauth@ietf.org
Subject: Re: [OAUTH-WG] New Text for Sec 3.2.1 4.1.3
The change to
Would this be clearer:
ensure the authorization code was issued to the authenticated
confidential client, or to the public client identified by the
'client_id' in the request,
The intent is always that the code must be presented by the client to which it
was issued. That is acceded by
13 matches
Mail list logo
