Re: [OAUTH-WG] temperature check: json input to token endpoint

2010-07-12 Thread Justin Richer
I'd like to keep form-encoded inputs. I think it makes sense to use a well-established key-value mechanism, and the asymmetry at play here is what the web is made of (post a form, get HTML/XML/JSON/whatever). Along those lines, I'd actually like to relax the restriction of using "POST" and allow f

Re: [OAUTH-WG] "access grant" terminology

2010-07-12 Thread Eve Maler
How about "approval", as in delegation approval or association approval (since the resource owner is approving or consenting to the association of these two services on the owner's behalf for delegated access purposes, with specific tokens later representing specific access authorizations)?

Re: [OAUTH-WG] temperature check: json input to token endpoint

2010-07-12 Thread Eran Hammer-Lahav
Proxies and caches. EHL On Jul 12, 2010, at 8:48, "Justin Richer" wrote: > I'd like to keep form-encoded inputs. I think it makes sense to use a > well-established key-value mechanism, and the asymmetry at play here is > what the web is made of (post a form, get HTML/XML/JSON/whatever). > >

Re: [OAUTH-WG] Authorization Header Format in draft-10

2010-07-12 Thread Eran Hammer-Lahav
Yep. I should not write ABNF after a day of editing. EHL On Jul 12, 2010, at 1:39, "Michael D Adams" wrote: > On Sun, Jul 11, 2010 at 8:19 PM, Eran Hammer-Lahav > wrote: >> My bad. I forgot to update the ABNF for the parameters. >> >> credentials= "OAuth" RWS access-token RWS [ 1#aut

[OAUTH-WG] Moving the User Experience Extension draft forward

2010-07-12 Thread David Recordon
I wrote this draft last month based on discussions on the mailing list, the OpenID user experience extension (which Facebook, Google, and Yahoo! have deployed), and some OAuth 2.0 implementation experience from Facebook. It defines language and display preferences which the client can include in re

Re: [OAUTH-WG] Moving the User Experience Extension draft forward

2010-07-12 Thread Eran Hammer-Lahav
Now that core is pretty stable, we should start adding a few new WG items. This is a no brainer. EHL On 7/12/10 12:51 PM, "David Recordon" wrote: I wrote this draft last month based on discussions on the mailing list, the OpenID user experience extension (which Facebook, Google, and Yahoo! h

Re: [OAUTH-WG] "access grant" terminology

2010-07-12 Thread Eran Hammer-Lahav
Approval feels like something temporary that happens in a specific moment, unlike grant or credential which are 'issued'. EHL On 7/12/10 6:39 AM, "Eve Maler" wrote: How about "approval", as in delegation approval or association approval (since the resource owner is approving or consenting to

[OAUTH-WG] OAuth 2.0 Token Upgrade Extension

2010-07-12 Thread David Recordon
The ability to upgrade OAuth 1.0 tokens and secrets to OAuth 2.0 access tokens has come up on the list a few times. Attached is a draft assertion format which allows a client to trade an OAuth 1.0 token/secret pair for an OAuth 2.0 access token. The assertion format is a JSON object with values for

Re: [OAUTH-WG] Moving the User Experience Extension draft forward

2010-07-12 Thread Manger, James H
.David, > I'd like this draft [draft-recordon-oauth-v2-ux-02.txt] to become a working > group document I disagree. This shouldn't be a working group document. It should be moved into the core. The 2 parameters it defines (language and display) should be moved to the core OAuth doc now t

Re: [OAUTH-WG] Moving the User Experience Extension draft forward

2010-07-12 Thread David Recordon
Obviously I'm fine with this being merged into core if that's what the group wants to do. :) On Mon, Jul 12, 2010 at 5:49 PM, Manger, James H < james.h.man...@team.telstra.com> wrote: > .David, > > > > > I'd like this draft [draft-recordon-oauth-v2-ux-02.txt] to become a > working group documen

Re: [OAUTH-WG] Moving the User Experience Extension draft forward

2010-07-12 Thread Eran Hammer-Lahav
I think it belongs in a separate spec (even if at the end if might mean more work for others and me). I don't think the UX bits are well understood or enjoy enough experience to become part of core. They also tend to change often as the state of the art in UX evolves. With -10, I am going to ta

[OAUTH-WG] Alternative ways to pass Authorization Request Parameters

2010-07-12 Thread Nat Sakimura
As of -10, the Authorization Request Parameters are required to be passed as part of the Authorization Request URI query component. I would like to see it relaxed a bit so that they do not have to be a part of the URL but can be passed by reference. In the proposal that I have submit a while ago,

[OAUTH-WG] issuing new refresh tokens

2010-07-12 Thread Brian Eaton
Draft 10 has the following sentence in section 4.1.4: http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-4.1.4 "The authorization server MAY issue a new refresh token." That carries a surprising amount of baggage. I suggest removing the sentence, or changing it to MUST NOT, pending a disc

[OAUTH-WG] "shared symmetric secret"

2010-07-12 Thread Brian Eaton
Section 5: http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-5 Calling access tokens "shared symmetric secrets" is misleading, because if they are implemented well the authorization server and protected resource do not store a copy of the secret. Instead they store a one-way hash of the t

[OAUTH-WG] required authentication methods

2010-07-12 Thread Brian Eaton
Section 5 does not appear to list any authentication method that the server is required to support: http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-5. How about resource servers MUST support the Authorization header and may support other methods? _

Re: [OAUTH-WG] required authentication methods

2010-07-12 Thread Brian Eaton
Ah, never mind, this got added to draft-10 already. Thanks. On Mon, Jul 12, 2010 at 10:42 PM, Brian Eaton wrote: > Section 5 does not appear to list any authentication method that the > server is required to support: > http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-5. > > How about re

[OAUTH-WG] expired_token error code

2010-07-12 Thread Brian Eaton
http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-5.2.1 The "expired_token" error code doesn't scale well and won't be implemented reliably. It should be merged with "invalid_token". Suggested language: invalid_token The access token provided is invalid. Resource servers SHOUL

Re: [OAUTH-WG] return to draft 6 spec org?

2010-07-12 Thread Brian Eaton
On Sun, Jul 11, 2010 at 7:37 AM, Eran Hammer-Lahav wrote: > I think the way to solve it is to make them more detailed and normative. > This will retain the general framework as current specified, but will > provide a reference-able description of useful profiles. This will also make > it easier to