On Wed, May 26, 2010 at 8:51 PM, Evan Gilbert wrote:
>
>
> On Tue, May 25, 2010 at 1:43 PM, Murali VP wrote:
>
>> Anyway to find out what the outcome was from the May 20th interim meeting?
>> I
>> wanted to participate but had to be at Google I/O.
>>
>> 3.5. User-Agent Flow
>>
>> 1. Since the c
On Tue, May 25, 2010 at 1:43 PM, Murali VP wrote:
> Anyway to find out what the outcome was from the May 20th interim meeting?
> I
> wanted to participate but had to be at Google I/O.
>
> 3.5. User-Agent Flow
>
> 1. Since the client_id is public, the only check that prevents from
> any client po
uditing?
>
> /thomas/
>
>
>
> __
>
>
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
> Allen Tom
> Sent: Tuesday, May 25, 2010 10:17 PM
> To: Murali VP; oauth@ietf.org
> Subject: Re: [OAUTH-WG] OAuth 2.0 questions/suggestions (based on draft 2-
To: Murali VP; oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth 2.0 questions/suggestions (based on draft 2-05)
Yes - one of the design goals for Oauth-WRAP was to eliminate the request token.
It is very tricky for SPs to implement the Request Token due to data
replication issues. The Request token
Yes one of the design goals for Oauth-WRAP was to eliminate the request
token.
It is very tricky for SPs to implement the Request Token due to data
replication issues. The Request token could be issued to the client in one
data center, and then immediately submitted by the browser to a differen
Anyway to find out what the outcome was from the May 20th interim meeting? I
wanted to participate but had to be at Google I/O.
3.5. User-Agent Flow
1. Since the client_id is public, the only check that prevents from
any client posing as a registered client is the redirect_uri, this is
fine, exc
