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
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 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
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
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
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
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
>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
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
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
>
(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
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
+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
13 matches
Mail list logo
