On 6/28/10 1:27 PM, "Marius Scurtescu" wrote:
>
> Again, all I am saying is that it would help to have a very detailed
> use case for this token_and_code mode, to see if it is really needed.
> Or, an actual implementation.
I have no objections. I will include it in -09 but will mark it as
co
On Fri, Jun 25, 2010 at 12:07 PM, Eran Hammer-Lahav wrote:
>
>> -Original Message-
>> From: Marius Scurtescu [mailto:mscurte...@google.com]
>> Sent: Thursday, June 17, 2010 2:56 PM
>
>> >> Basically, why cannot be that problem solved by 2 different requests,
>> >> both done by the JavaScri
> -Original Message-
> From: Marius Scurtescu [mailto:mscurte...@google.com]
> Sent: Thursday, June 17, 2010 2:56 PM
> >> Basically, why cannot be that problem solved by 2 different requests,
> >> both done by the JavaScript layer?
> >>
> >> If latency is a problem, it would be good to kn
@ietf.org)
>> Subject: Re: [OAUTH-WG] Proposal: simplification of the end-user
>> authorization endpoint
>>
>> Yes, I am aware of that thread. I did ask some questions there which are
>> unanswered.
>
> Please repeat them so we can address them now.
That's what
> -Original Message-
> From: Marius Scurtescu [mailto:mscurte...@google.com]
> Sent: Thursday, June 17, 2010 11:08 AM
> To: David Recordon
> Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] Proposal: simplification of the end-user
> a
uth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] Proposal: simplification of the end-user
> authorization endpoint
>
> I think I'm missing something on the combined case here. How does the server
> trust the javascript client code to pass it back valid data? Is it assumed to
Sure, a refresh token as well depending on the AS implementation.
On Thu, Jun 17, 2010 at 11:17 AM, Marius Scurtescu
wrote:
> On Thu, Jun 17, 2010 at 11:09 AM, Eran Hammer-Lahav
> wrote:
>> We added an optional authorization code which can only be used after
>> exchanging it for an access toke
On Thu, Jun 17, 2010 at 11:09 AM, Eran Hammer-Lahav wrote:
> We added an optional authorization code which can only be used after
> exchanging it for an access token with required client authentication (client
> secret).
Just to make sure I understand the new flow, the authorization code is
sup
Richer [mailto:jric...@mitre.org]
Sent: Thursday, June 17, 2010 11:05 AM
To: Marius Scurtescu
Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Proposal: simplification of the end-user authorization
endpoint
I think I'm missing something on the combined case here. How
Yes, I am aware of that thread. I did ask some questions there which
are unanswered.
Basically, why cannot be that problem solved by 2 different requests,
both done by the JavaScript layer?
If latency is a problem, it would be good to know exactly where. I
assume that authorization codes are issu
I think I'm missing something on the combined case here. How does the
server trust the javascript client code to pass it back valid data? Is
it assumed to just rely on an established browser session at that point
that the javascript client has access to?
-- Justin
On Thu, 2010-06-17 at 13:48 -04
Hey Marius, take a look at
http://www.ietf.org/mail-archive/web/oauth/current/msg02657.html from
Twitter.
On Thu, Jun 17, 2010 at 10:48 AM, Marius Scurtescu
wrote:
> Shifting from client type profile names to flow type profiles sounds good.
>
> Not too sure about the combined case, token_and_cod
Shifting from client type profile names to flow type profiles sounds good.
Not too sure about the combined case, token_and_code. I am not opposed
to it, but I think it would help us wrap our heads around it if a
detailed use case was presented.
Thanks,
Marius
On Wed, Jun 16, 2010 at 11:05 PM,
+1, although "request" sounds a bit wierd. Don't you like
"response_type" or just "response"?
Am 17.06.2010 08:05, schrieb Eran Hammer-Lahav:
This is a joint proposal from David Recordon and me:
** Background:
The latest draft (-08) unified the web-server and user-agent client types into a
I like this, thought the name "request_type" or something seems more
appropriate title for the parameter.
On Thu, Jun 17, 2010 at 3:12 PM, David Recordon wrote:
> It took me a little while to shift my mind from thinking about how we
> had drafted the flows previously, but given how similar the fl
It took me a little while to shift my mind from thinking about how we
had drafted the flows previously, but given how similar the flows
already were it seems far more clear to have the client ask for a
token and/or code versus specifying types of web_server or user_agent.
Servers can still document
This is a joint proposal from David Recordon and me:
** Background:
The latest draft (-08) unified the web-server and user-agent client types into
a single authorization request format. This was done because once we added an
optional authorization code to the user-agent response, it became al
17 matches
Mail list logo
