+1
While it's good to have one document, it's better to have two good documents
instead of one that we're unhappy with.
There'll be Implementer's Guides and Tutorials later who will do the job
of explaining how to make sense of the two (which of course doesn't mean I'm
advocating specifications
Note there will be three documents not two.
The suggested change does not address the issue that myself and others had
raised with having signatures be in the core. The suggestion was that having
signatures be a different spec made them reusable by other groups and enabled a
more comprehensive
On 2010-09-30, at 11:33 AM, Eran Hammer-Lahav wrote:
-Original Message-
From: Dick Hardt [mailto:dick.ha...@gmail.com]
Sent: Thursday, September 30, 2010 7:45 AM
The suggested change does not address the issue that myself and others had
raised with having signatures be in the
-Original Message-
From: Mark Mcgloin [mailto:mark.mcgl...@ie.ibm.com]
Sent: Wednesday, September 29, 2010 12:55 AM
I echo Dick's sentiment, mildly
-1 to splitting acquiring and using a token. It may not confuse people
actively
engaged in the WG but what about everyone else?
Thanks Mark.
-Original Message-
From: Mark Mcgloin [mailto:mark.mcgl...@ie.ibm.com]
Sent: Wednesday, September 29, 2010 8:28 AM
I think acquiring and using a token can be considered core as you always
need both. I don't have valid security consideration linkage between
acquiring
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
+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
+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
-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
+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
17 matches
Mail list logo
