Yes, it would be helpful (and I think reasonable) to have an explanation of
why the process was changed so wildly from the past twenty-six drafts.
--David
On Fri, Jun 8, 2012 at 9:09 PM, Franklin Tse wrote:
> I think the chairs should clarify and explain, via this mailing list,
>
> 1. Whether t
I think the chairs should clarify and explain, via this mailing list,
1. Whether they have authorized Mike Jones and Dick Hardt to author and publish
the draft
2a. If they have given the authorization, why they needed to do so and why the
editor was not notified;
2b. Otherwise, whether the cur
+1
>
> From: Anthony Nadalin
>To: Eran Hammer ; "oauth@ietf.org WG (oauth@ietf.org)"
>
>Sent: Friday, June 8, 2012 7:18 PM
>Subject: Re: [OAUTH-WG] New draft process / editor role
>
>
>
>Why rant here, talk to the chairs or AD
>
>Sent from my Windows Phone
>
Why rant here, talk to the chairs or AD
Sent from my Windows Phone
From: Eran Hammer
Sent: 6/8/2012 6:58 PM
To: oauth@ietf.org WG (oauth@ietf.org)
Subject: [OAUTH-WG] New draft process / editor role
Today, a new draft of the OAuth 2.0 specification was published.
To some extent it goes to the question of who do you trust.
Most of OAuth is predicated on not sharing the users credential with the
client, because clients are not trusted.
Your situation may be different if you control the device.
If you are using multi factor authentication then using an emb
Today, a new draft of the OAuth 2.0 specification was published.
* I had nothing to do with this draft. I did not edit or authored it. I didn't
know it was being published.
* The draft was authored by Mike Jones and published by Dick Hardt.
* Neither one is an editor or an active author of the do
The new text published today for section 7.2 isn't acceptable. It seems (the
lanaguage is unclear when it comes to its actual requirements) to indicate that
any protocol used for OAuth token authentication using an error parameter named
"error" must use the new registry. Any authentication metho
I saw the new draft and assumed that Eran had published it, as he has been
doing so all along. If this is not the case, I also find this very surprising,
even though with three authors on the spec I can see how it can happen from a
mechanical level. But even so, shouldn't all three authors at le
You're right in that OAuth is optimized for the confidential clients case --
specifically, a client being a web server talking to another web server. But
what you've just described, in a nutshell, is the assertion grant type:
http://tools.ietf.org/html/draft-ietf-oauth-assertions-03
Which has b
Hi,
I have a historical question around front channel / back channel (direct)
communications and Authorization Requests. Both the code-flow and
implicit-flow utilize a front channel communication through the UA. This makes
sense for the delegated credentials case (e.g. shutterfly accessing ph
Hi Amos,
The OAuth Bearer specification now includes the Cache-Control language we'd
discussed.
See the fifth paragraph of
http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-20#section-2.3.
Thanks again,
I must say that I found it surprising, too. An explanation beforehand
from the chairs would have helped to prevent confusion.
On 6/8/12 3:28 PM, Eran Hammer wrote:
> What the hell just happened? Even if this is allowed under IETF rules,
> it is clearly against IETF spirit. There is now a published
What the hell just happened? Even if this is allowed under IETF rules, it is
clearly against IETF spirit. There is now a published draft with my name as
sole editor and text I didn't put in there. No one even suggested this is
something the chairs might do.
After all the work I put into this, t
Draft 20 of the OAuth 2.0 Bearer Token Specification has been published. I
believe that this draft addresses all DISCUSS issues and comments raised for
this specification in IESG review. No normative changes were made, other than
specifying the use of Cache-Control options when using the URI Q
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol Working Group of
the IETF.
Title : The OAuth 2.0 Authorization Framework: Bearer Token
Usage
Author(s) : Michael B. Jones
Apologies, Dick HARDT! :-)
From: Dick Hardt [mailto:dick.ha...@gmail.com]
Sent: Friday, June 08, 2012 11:09 AM
To: Mike Jones
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth Core -27 Published
On Jun 8, 2012, at 10:51 AM, Mike Jones wrote:
The chairs approved publication of OAuth Core draft -
Hi Julian,
The current draft restricts username and password to ASCII was because RFC 2616
says this about the TEXT fields used by HTTP Basic in RFC 2617:
"Words of *TEXT MAY contain characters from character sets other than
ISO-8859-1 [22] only when encoded according to the rules of
RF
On Jun 8, 2012, at 10:51 AM, Mike Jones wrote:
> The chairs approved publication of OAuth Core draft -27 today. This version
> is based upon the proposed changes that I’d circulated to the working group.
> Changes are:
> ·Adds character set restrictions for error, error_description, a
The chairs approved publication of OAuth Core draft -27 today. This version is
based upon the proposed changes that I'd circulated to the working group.
Changes are:
*Adds character set restrictions for error, error_description, and
error_uri parameters consistent with the OAuth Beare
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol Working Group of
the IETF.
Title : The OAuth 2.0 Authorization Framework
Author(s) : Eran Hammer
The implicit flow doesn't allow for refresh tokens.
The refresh token mechanism allows for the AS to revoke access to the RS when a
relatively short lived access_token expires.
Some people seem to prefer having the RS make a callback to the AS on each
access, and not use refresh tokens.
There
Hi all,
I hope this mailing list can be used for this
Im new in oAuth, Im a developer trying to use oAuth 2.0 to access google
calendar from web access, I use asp.net with VB, my customer want to migrate
some private calendar to google calendar, the application is in an
intranet, and
Hi all,
I'm looking for a better understanding of why the code flow is recommended as
the preferred OAuth flow, even when used for native (public) clients.
I totally get why it is preferred for confidential clients, as explained in
section 1.3.1. of the version 26 of the draft. The first reaso
On 2012-06-08 09:56, Mike Jones wrote:
The attached proposed edits to the Core spec update the ABNF to remove
the character set restrictions that working group participants had
objected to, and to define common syntax elements, where appropriate.
After working group review, I believe that these c
24 matches
Mail list logo
