Sounds great Eran,
1. Add a parameter to the token response to include an extensible token
scheme.
Yes. I suggest a parameter named scheme. The value can be an HTTP
authentication scheme name (eg scheme:BASIC) for which the response is
providing credentials. Not all possibilities are
Yes, I'm willing to write guides for the profiles that I use, once
things settle down and we know what the protocol actually is. :) I'd
argue that Facebook's developer docs are a start for bearer tokens
using the UX extension and web server/user agent profiles already.
I think that the most
+1 on the split. I think it's an elegant approach, and it won't be any
harder to follow than a monolithic spec with multiple optional sections.
Especially if we put together the right guidance as a gateway to the
spec.
OAuth 1.0 (and -a) really talk about three different things: how to get
a
I think of the signature issues as falling into two classes... I think
they map to your classification as well...
* *Signing tokens* is important for interoperability especially
looking forward to a time when tokens issued by multiple
Authorization Servers are accepted at a given
+1 I think this is a great path forward
On 9/28/10 2:25 AM, Eran Hammer-Lahav wrote:
(Please take a break from the other threads and read this with an open
mind. I have tried to make this both informative and balanced.)
--- IETF Process
For those unfamiliar with the IETF process, we
Eran-
Thanks for writing a great explanation of where we are so far. I agree that it
makes sense to logically separate getting a token from using a token, and
we should structure it so that there can be extension specs about how to use a
token. It also seems clear that we should do some more
These use cases are not in the draft
https://datatracker.ietf.org/doc/draft-zeltsan-use-cases-oauth.
Could you write them up?
Thanks,
Zachary
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
George Fletcher
Sent: Tuesday, September 28,
-Original Message-
From: Luke Shepard [mailto:lshep...@facebook.com]
Sent: Tuesday, September 28, 2010 9:16 AM
As far as the charter: this workgroup has had a focus on building an
interoperable, easy-to-use, developer-friendly standard that is actually used.
With the goal of
* Is there an example of an OAuth 2.0 server that can't use bearer tokens for
protected resource requests and thus requires signatures?
The use case I see for signatures that isn't solved (as well) by tokens is 3
way integrations where it is useful to manage a secret as a way to manage the
+1 seems like a pragmatic compromise
On Tue, Sep 28, 2010 at 12:44 PM, Marius Scurtescu
mscurte...@google.com wrote:
On Tue, Sep 28, 2010 at 9:05 AM, George Fletcher gffle...@aol.com wrote:
+1 I think this is a great path forward
+1
Marius
___
+1.
--
John Panzer / Google
jpan...@google.com / abstractioneer.org http://www.abstractioneer.org/ /
@jpanzer
On Mon, Sep 27, 2010 at 11:25 PM, Eran Hammer-Lahav e...@hueniverse.comwrote:
(Please take a break from the other threads and read this with an open
mind. I have tried to make this
+1
Eran, thanks for framing this up...
On Sep 28, 2010, at 12:14 PM, Brian Campbell wrote:
+1 seems like a pragmatic compromise
On Tue, Sep 28, 2010 at 12:44 PM, Marius Scurtescu
mscurte...@google.com wrote:
On Tue, Sep 28, 2010 at 9:05 AM, George Fletcher gffle...@aol.com wrote:
+1 I
On 9/28/10 12:25 AM, Eran Hammer-Lahav wrote:
(Please take a break from the other threads and read this with an open
mind. I have tried to make this both informative and balanced.)
--- IETF Process
For those unfamiliar with the IETF process, we operate using rough
consensus. This means
+1
The proposal makes sense. I particularly like the side effect that the use of
access tokens is no longer bound to HTTP.
Hui-Lan Lu
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran
Hammer-Lahav
Sent: Tuesday, September 28, 2010
+1
The proposal makes sense. I particularly like the good side effect that the use
of access tokens is no longer bound to HTTP.
Hui-Lan Lu
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran
Hammer-Lahav
Sent: Tuesday, September 28,
-Original Message-
From: Dick Hardt [mailto:dick.ha...@gmail.com]
Sent: Tuesday, September 28, 2010 5:09 PM
I am mildly concerned that breaking the spec into multiple parts makes it
harder for the spec reader to understand what is going on. Where does a
complete example of getting
16 matches
Mail list logo