Re: [OAUTH-WG] redirect uri validation

ok with me.

On Sun, 4 Sep 2011 15:13:01 -0700, Eran Hammer-Lahav wrote:
> That's not complete. A valid redirection URI is not enough to verify
> client identity at the time it is presented, but it is enough in many
> cases to prevent leaking credentials later on.
>
> How about a slight change:
>
>           A valid redirection URI is not sufficient to verify the
> client's identity when asking for
>           end-user authorization, but can be used to prevent
> delivering credentials to a
>           counterfeit client after obtaining end-user authorization.
>
> EHL
>
>> -----Original Message-----
>> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
>> Sent: Monday, August 15, 2011 1:36 PM
>> To: Eran Hammer-Lahav
>> Cc: eran@sled.com; oauth@ietf.org
>> Subject: Re: [OAUTH-WG] redirect uri validation
>>
>> 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-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
>> >> Behalf Of Eran Hammer-Lahav
>> >> Sent: Sunday, August 14, 2011 11:09 PM
>> >> To: Torsten Lodderstedt
>> >> Cc: torsten@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:torsten@lodderstedt.net]
>> >>> Sent: Monday, July 25, 2011 10:42 AM
>> >>> To: Eran Hammer-Lahav
>> >>> Cc: torsten@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