+1 for option 2 - flow based organization
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran
Hammer-Lahav
Sent: Tuesday, January 11, 2011 11:19 PM
To: OAuth WG
Subject: [OAUTH-WG] Specification organization (Endpoints vs. Flows) - Vote by
1/17
(Vote at the end, pleas
I prefer #1.
EHL
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran
Hammer-Lahav
Sent: Tuesday, January 11, 2011 11:19 PM
To: OAuth WG
Subject: [OAUTH-WG] Specification organization (Endpoints vs. Flows) - Vote by
1/17
(Vote at the end, please read)
Background
Bet
(Vote at the end, please read)
Background
Between draft -00 and -05 the document used a flow-based organization. This was
changed to an endpoint-based organization in draft -06. I have received
requests to go back to the flow-based organization, and with -12, have been
planning to do that. It
On Tue, Jan 11, 2011 at 2:44 PM, Torsten Lodderstedt
wrote:
> Do you see any need to restrict the power of this token or is it as powerful
> as the tokens obtained using the code? I'm asking because this token is sent
> out without authenticating the client whereas exchange of code to tokens can
>
On Tue, Jan 11, 2011 at 1:21 PM, Eran Hammer-Lahav wrote:
> But that's just an annoying implementation detail.
Yes. The user-agent flow is a set of annoying implementation details
that are very, very useful if you want to make the protocol efficient.
> If the only different now between the hybr
>The frames timing issue is interesting, but doesn't it suggest a
profile where the whole code step is bypassed (e.g. by receiving code
and token)?
The user-agent profile callback URL should end up looking like this:
/callback#code=&token=
The token component is there so immediately return a u
the only difference I see is the code in the fragement will not show up
in HTTP referers.
Am 11.01.2011 22:21, schrieb Eran Hammer-Lahav:
But that's just an annoying implementation detail. If the only different now
between the hybrid and web server flows is one character ('?' vs '#'), and all
I just posted a new revision of
http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/.
Please consider it for the re-chartering process.
Additionally, Mark and me are still working on the security document. It
takes longer time than expected because of the topic's inherent
compl
Am 11.01.2011 06:44, schrieb Manger, James H:
- Authentication schemes
You propose to use the authentication scheme name "OAuth2" for the
WWW-Authenticate header but another scheme name "MAC" for the
authorization header. I've never seen such an asymmetric approach before.
Don't you think people
But that's just an annoying implementation detail. If the only different now
between the hybrid and web server flows is one character ('?' vs '#'), and all
the other security considerations and rules (matching, registration, etc.) are
the same, I don't see any point in going back to -05 structur
On Tue, Jan 11, 2011 at 12:45 PM, Eran Hammer-Lahav wrote:
> The exact same argument can be made that the hybrid flow meets all the use
> cases of the web-server flow... which means we can keep the current single
> flow specification as is... :-)
>
> What am I missing? (I'm asking).
The hybrid
The exact same argument can be made that the hybrid flow meets all the use
cases of the web-server flow... which means we can keep the current single flow
specification as is... :-)
What am I missing? (I'm asking).
EHL
> -Original Message-
> From: Brian Eaton [mailto:bea...@google.com]
On Mon, Jan 10, 2011 at 3:42 PM, Eran Hammer-Lahav wrote:
> These are two very different client profiles. In one, the client is
> completely authenticated, residing solely in the user-agent. The other is a
> mix authenticated and unauthenticated, where parts of the client can keep a
> secrets b
13 matches
Mail list logo
