(Distributing to a wider audience)
Thanks for letting us know about your implementation, Jeff!
-- Mike
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Jeff
Lindsay
Sent: Tuesday, April 05, 2011 8:43 PM
To: OAu
We use JWT a lot and end up needing it while using curl, or needing quick
JWT generation... so I added a jwt command line utility in PyJWT. It doesn't
support all crypto methods yet (since PyJWT doesn't either), but it has a
pretty nice interface for encoding/decoding.
You can install it with just
It seems that some are confused by my role here with respect to representing
the views of my employer, Yahoo!.
I have repeated this on many occasions but for the sake of clarity will do so
again. I am here representing myself alone. I do not speak for my employer, and
my views do not necessaril
Also, change "which in turns directs" to "which in turn directs".
-- Mike
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Manger, James H
Sent: Tuesday, April 05, 2011 5:51 PM
To: oauth@ietf.org
Subject: [O
A few, mainly editorial, points on the latest OAuth 2.0 core draft
[draft-ietf-oauth-v2-15]:
Abstract: Currently it is:
The OAuth 2.0 authorization protocol enables granting third-party
applications limited access to HTTP service on behalf of an end-user
by orchestrating an approval
My only uneducated view is that I do not want to deal with this in the MAC
draft (which is being transform into a completely generic HTTP authentication
scheme and will move out of this WG with the next draft). Other than that, I
don't have an opinion.
EHL
From: oauth-boun...@ietf.org [mailto:
In working on the SASL mechanism spec for OAuth we have to deal with Channel
Binding. Sparing you the gory details there I believe that the right thing to
do is to add the channel binding information into the tunneled HTTP/OAuth
authentication. For those OAuth profiles like MAC and SAML that
> -Original Message-
> From: Marius Scurtescu [mailto:mscurte...@google.com]
> Sent: Tuesday, April 05, 2011 4:29 PM
> Isn't this sentence "Additional error codes used with unregistered extensions
> MAY be registered." contradicting what you are saying above? It seems to
> open the door
We have native clients using the first 3 as well with good success
-cmort
On 4/4/11 2:00 PM, "Brian Eaton" wrote:
On Mon, Apr 4, 2011 at 1:06 PM, Phil Hunt wrote:
> Very quickly here is the attack...
> 1) Paul starts dance at good Client & good AS, App requests authorization.
> Note: outbou
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Open Authentication Protocol Working Group of
the IETF.
Title : The OAuth 2.0 Authorization Protocol
Author(s) : E. Hammer-Lahav, et al.
Filena
I submitted a new draft (well two, I forgot one change in -14). Open issues are
marked with [[ Pending Consensus ]] are considered unsafe to implement.
Changes:
* Many minor editorial changes.
* Expanded abstract.
* Added note to intro about this being an HTTP-specific protocol.
* Additional ref
On Tue, Apr 5, 2011 at 3:51 PM, Eran Hammer-Lahav wrote:
> The following is my new proposal, based on Mike Jones’ and my earlier
> proposals. It is basically a combination of the two.
Looks good.
> This proposal does not allow defining new error codes unless another
> extension is involved (new
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Open Authentication Protocol Working Group of
the IETF.
Title : The OAuth 2.0 Authorization Protocol
Author(s) : E. Hammer-Lahav, et al.
Filena
Didn't receive any objections to this change. Will apply to -14.
EHL
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran
Hammer-Lahav
Sent: Tuesday, March 29, 2011 4:14 PM
To: OAuth WG
Subject: [OAUTH-WG] Proposed change to OAuth parameters registry
I would like to ma
The following is my new proposal, based on Mike Jones' and my earlier
proposals. It is basically a combination of the two.
This proposal does not allow defining new error codes unless another extension
is involved (new grant type, request parameter, token type). The reason for not
defining an
Thanks for the candid feedback, Bob. I agree that the specs can be more
clearly delineated and I'll make that an editorial goal in the next round of
revisions. In particular, I agree that a non-JWT example should be added to
the JWS spec.
I intentionally kept complete JWT examples in the JWT
Hi Mike,
I'm going to start implementing draft 4 in the near future. At a cursory
reading, I'm concerned that splitting the specifications has not simplified
the language, rather it has confused the specification, and introduced
generalisation where there were formerly simple, specific cases.
If
+1 for making the specification clear. It should say that the native
application clients participating in the authorization code flow do not use the
client secrets.
Zachary
-Original Message-
From: tors...@lodderstedt.net [mailto:tors...@lodderstedt.net]
Sent: Tuesday, April 05, 2011 1
In respect to current deployments we have a pretty broad deployment of
different clients using implicit grant. We also support the code flow as
described here, but haven't found good reason to use it.
- cmort
On Apr 5, 2011, at 6:24 AM, "Justin Richer" wrote:
> Phil,
>
> It's completely w
Yes agreed. The way I read it any flow can omit client credential if they have
another means to identify it.
Phil
Sent from my phone.
On 2011-04-05, at 6:24, Justin Richer wrote:
> Phil,
>
> It's completely within the normative language of the spec to do things
> this way right now -- the
Phil,
It's completely within the normative language of the spec to do things
this way right now -- the question is how the editorial text surrounding
the normative text presents different flows and use cases and how to map
between them. As it's written in the latest drafts, it sounds like the
impl
DO NOT REPLY TO THIS EMAIL.
To Eran's point, before reaching the end of this thread after limited
access to email over the weekend, I was going to shut this thread down
anyways.
I'm not going to issue a call for consensus on this issue, because I
don't believe anyone on the list (except for a s
22 matches
Mail list logo
