On Fri, Jun 25, 2010 at 12:07 PM, Eran Hammer-Lahav e...@hueniverse.com 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
-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 know exactly
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
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
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 record...@gmail.com wrote:
It took me a little while to shift my mind from thinking about how we
had drafted the flows previously, but given
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,
On Thu, Jun 17, 2010 at 11:09 AM, Eran Hammer-Lahav e...@hueniverse.com 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
Sure, a refresh token as well depending on the AS implementation.
On Thu, Jun 17, 2010 at 11:17 AM, Marius Scurtescu
mscurte...@google.com wrote:
On Thu, Jun 17, 2010 at 11:09 AM, Eran Hammer-Lahav e...@hueniverse.com
wrote:
We added an optional authorization code which can only be used after
client authentication (client secret).
EHL
-Original Message-
From: Justin 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
-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
authorization endpoint
Yes, I am
] 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 I did below.
Basically, why cannot be that problem solved by 2 different requests
11 matches
Mail list logo
