Me too! :-)
EHL
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Phil Hunt
> Sent: Monday, March 14, 2011 10:12 PM
> Cc: oauth@ietf.org WG
> Subject: Re: [OAUTH-WG] Vote: Location of OAuth Errors Registry, deadline
> Friday, March 18
>
>
As I indicated earlier, I don't agree yet with the choices and would like more
information on the registry and use cases.
Phil
phil.h...@oracle.com
On 2011-03-14, at 6:29 PM, Eran Hammer-Lahav wrote:
> It's a clear example of defining facilities without *ANY* use cases or
> requirements.
>
Hey Torsten - glad to see this spec out there, and we plan to implement in the
future. Only 1 quick comment:
"the authorization server is supposed to detect the token type automatically."
I think it would be better to have the client explicitly state the token
type. The client will know,
My vote is D, or C -- if you really have a use case for extensible errors in
Bearer.
As for consistency, the WG should attempt to keep error codes sensible and
consistently applied.
From: Mike Jones
To: "oauth@ietf.org"
Sent: Friday, March 11, 2011 3:04 PM
S
It's a clear example of defining facilities without *ANY* use cases or
requirements.
We have clear use cases and actual registration requests for the current
registries defined in v2.
What's most annoying about this entire push for an error registry is that the
author and supporters have all f
Draft looks good - readability is up considerably from previous drafts.
Getting pretty close IMO
Comments:
1) I'd vote for dropping the following from 1.4.2. In turn I'd discuss some
of the security considerations, such as difficulty of protecting a
client_secret in almost all use-cases o
Has anyone extended error codes? Is there a list of error codes
currently being used in the wild that need standardizing?
--David
On Mon, Mar 14, 2011 at 11:28 PM, Mike Jones
wrote:
> This is not new. This is meeting the need expressed in draft 10, Section
> 3.2.1 and draft 11, Section 4.3.1
This is not new. This is meeting the need expressed in draft 10, Section 3.2.1
and draft 11, Section 4.3.1 as "[[ Add mechanism for extending error codes ]]".
It's there to provide a coordination mechanism among OAuth-related
specifications so that different specs use the same errors for the sa
Cool!
On Mon, Mar 14, 2011 at 7:35 PM, Marius Scurtescu wrote:
> The announcement:
> http://googlecode.blogspot.com/2011/03/making-auth-easier-oauth-20-for-google.html
>
> The documentation page:
> http://code.google.com/apis/accounts/docs/OAuth2.html
>
> Other than the core spec it implements:
>
I still haven't seen an explanation of what this registry accomplishes
or why it's become needed in the past few weeks.
--David
On Fri, Mar 11, 2011 at 11:04 PM, Mike Jones
wrote:
> As you know, the OAuth 2.0 Bearer Token draft -03 established the OAuth
> Errors Registry to increase interoperab
The announcement:
http://googlecode.blogspot.com/2011/03/making-auth-easier-oauth-20-for-google.html
The documentation page:
http://code.google.com/apis/accounts/docs/OAuth2.html
Other than the core spec it implements:
- revocation endpoint
- native app support using oob and localhost (I still ha
My preference would be option A
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike
Jones
Sent: Friday, March 11, 2011 3:04 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Vote: Location of OAuth Errors Registry, deadline Friday,
March 18
As you know, the OAuth 2.0 Bearer T
A -- but potentially do a short-form registry with a full-url nonregistered
means of extending error codes, like with grant types.
-- justin
From: oauth-boun...@ietf.org [oauth-boun...@ietf.org] On Behalf Of Mike Jones
[michael.jo...@microsoft.com]
Sent:
Hi all,
I just uploaded a new revision of the revocation I-D
(http://tools.ietf.org/html/draft-lodderstedt-oauth-revocation-02).
Changes:
- dropped token_type parameter
- made client authentication optional (as on the token endpoint)
- changed success status code to 200
Thank's to all reviewe
applied small correction to sections 4.4.1.2 and 4.4.1.6
Original-Nachricht
Betreff:New Version Notification for draft-lodderstedt-oauth-security-01
Datum: Mon, 14 Mar 2011 03:34:57 -0700 (PDT)
Von:IETF I-D Submission Tool
An: tors...@lodderstedt.net
CC: ma
Can we rule out Friday afternoon as people will be getting return flights.
I am trying to get approval at the moment but will definitely not be able
to attend all week. If we are discussing security considerations, can we
make Thursday the focus day - this does not mean it can't be discussed
befor
2 more days. Please reserve some time to read the entire document and provide
detailed feedback.
EHL
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Hannes Tschofenig
> Sent: Tuesday, March 01, 2011 11:32 PM
> To: OAuth WG
> Subject: [OA
Hi all,
the IETF meeting in Prague is just around the corner and we need to put the
agenda for the face-to-face meeting together.
If you plan to give a presentation please drop us a mail ASAP.
Ciao
Hannes & Blaine
___
OAuth mailing list
OAuth@ietf.o
Hi Mike,
Hi all,
As some of you had notice we do not vote.
Soliciting the feedback from the working group on this issue is, however, a
good idea.
Ciao
Hannes
On Mar 12, 2011, at 1:04 AM, Mike Jones wrote:
> As you know, the OAuth 2.0 Bearer Token draft -03 established the OAuth
> Errors R
19 matches
Mail list logo
