Hi Eran,
Am 15.08.2011 08:57, schrieb Eran Hammer-Lahav:
Added to 1.4.2:
When issuing an implicit grant, the authorization server does not
authenticate the
client and [[in some cases]], the client identity [[can]] be
verified via the redirection URI
used to deliver the access token to the client. The access token
may be exposed to the
resource owner or other applications with access to the resource
owner's user-agent.
Hope this is sufficient.
What do you want to express? Clients can sometimes be verified via
redirection URI?
My intention was to point out that an invalid redirect URI is a
counter-evidence for a client's identity but a valid redirect URI is
_not_ an evidence for its identity.
I would suggest to add the text below to section 10.1., last paragraph
after the sentence
"For
example, by requiring the registration of the client redirection URI
or enlisting the resource owner to confirm identity."
proposed text:
Please note: while an invalid redirection URI indicates a counterfeit
client, a valid redirection URI is not sufficient to confirm a client's
identity.
regards,
Torsten.
EHL
-----Original Message-----
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Eran Hammer-Lahav
Sent: Sunday, August 14, 2011 11:09 PM
To: Torsten Lodderstedt
Cc: tors...@lodderstedt-online.de; oauth@ietf.org
Subject: Re: [OAUTH-WG] redirect uri validation
Where would you suggest I add this?
EHL
-----Original Message-----
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Monday, July 25, 2011 10:42 AM
To: Eran Hammer-Lahav
Cc: tors...@lodderstedt-online.de; oauth@ietf.org
Subject: Re: [OAUTH-WG] redirect uri validation
Hi Eran,
OAuth 1.0 was highly criticized for failing to address client
identity in public clients. I believe OAuth 2.0 offers a much
better story, within the boundaries>of what’s possible today.
Agreed. I think we must honestly discuss the value of client
authentication/identification itself. I personally think it is
over-emphazised right now. The strength of OAuth 2.0 is that it
allows solutions where neither client nor resource server have
access or
do store end-user credentials.
Client authentication is nice but not the main feature.
Do you have any specific suggestions not already mentioned on the list?
I would suggest to mention that while an invalid redirect_uri
indicates a counterfeit clients a valid redirect does not prove the calling
client's identity.
regards,
Torsten.
EHL
_______________________________________________
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
