Am 16.06.2010 00:35, schrieb Brian Eaton:
On Tue, Jun 15, 2010 at 8:54 AM, Torsten Lodderstedt
wrote:
Wouldn't it be an alternative solution, if the AS first tries to
authenticate the user using SPNEGO within the Web Server flow? This should
work in the inhouse scenario. If it fails, it c
I don't care about IPR.
I asked for it to be submitted as I-D because for now, I think we have
consensus to move it forward in that form. We can always merge it into core,
but for now, it is not part of core. Don't worry about this too much at this
moment. What you need to do is get consensus t
I was wondering when you suggested to write an I-D about the request
by reference (which started as mobile WebApp flow), you wanted it for
the IPR reason or meant that it should be separate from the core. To
cover both case, I have submit the I-D
http://datatracker.ietf.org/doc/draft-sakimura-oauth
Not sure what you are referring to.
EHL
> -Original Message-
> From: Nat [mailto:sakim...@gmail.com]
> Sent: Thursday, June 17, 2010 4:42 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] Status update
>
> What about the 'request_url' indirection (witho
What about the 'request_url' indirection (without sig and enc)?
On 2010/06/18, at 6:36, Eran Hammer-Lahav wrote:
With the exception of extensibility, I consider draft -08 to be
feature complete. This means that the draft contains all the
features and components needed and other then editori
On Thu, Jun 17, 2010 at 2:30 PM, Eran Hammer-Lahav wrote:
>
>
>> -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] Propos
With the exception of extensibility, I consider draft -08 to be feature
complete. This means that the draft contains all the features and components
needed and other then editorial work is close to finished. I plan to finish
work on the -09 draft by Mon or Tue next week which will include the
e
> -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
>
> Ye
OK, nevermind, I think I wasn't reading things correctly. I've re-read
both the current spec and the proposal below and I think I've answered
my own question. My question was essentially "how does the Javascript
client get the authorization code back to the server?", but now I see
that it doesn't h
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
What do you mean by valid data?
In the user-agent case, the server returns an access token. We added an
optional authorization code which can only be used after exchanging it for an
access token with required client authentication (client secret).
EHL
-Original Message-
From: Justin Ri
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,
hi,
this seems to be a typo, notice the inconsistency of definition of
grant_type value and example of grant_type parameter.
this apply to oauth spec 2 draft 08
==
4. Obtaining an Access Token
...
grant_type
REQUIRED. The access grand type included in the request.
+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'm going to write an I-D for multiple access tokens. If someone else
would like to contribute, please contact me.
regards,
Torsten.
Am 17.06.2010 03:56, schrieb Eran Hammer-Lahav:
This use case seems to have some support for an extension, but enough
resistance for being added to core. I sug
Hi Eran,
At 10:14 14-06-10, Eran Hammer-Lahav wrote:
I am now making daily changes to the draft. I check these changes in
daily (sometimes more) to my github account [1] but I'm not clear
how often do people here wants me to submit those as I-D revisions.
Frequent submission makes it harder for
hi,
this seems to be a typo, notice the inconsistency of definition of
grant_type value and example of grant_type parameter.
this apply to oauth spec 2 draft 08
==
4. Obtaining an Access Token
...
grant_type
REQUIRED. The access grand type included in the request.
P.S. It has extra things like Signing and Encrypting of the Request
payload for some use-case stated in the introduction, but the core is the
"request_url". (The draftactually is largely copy and paste of OpenID
Artifact Binding, which is based on OAuth2.0).
> A new version of I-D, draft-sakimura
22 matches
Mail list logo
