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

On Sat, Jul 10, 2010 at 8:03 PM, Eran Hammer-Lahav wrote: > I think authorization credential is going to confuse most readers. The spec > refers to credentials almost exclusively when dealing with identifier and > password (client, end-user), or as a general term for client authentication. > Autho

Re: [OAUTH-WG] What to do about 'realm'

On Sun, Jun 27, 2010 at 6:51 PM, Eran Hammer-Lahav wrote: > 1. Leave it as required under the definition of RFC 2617 (i.e. provide no > help, developers will need to ready 2617 and figure out what to do with it). > > 2. Update 2617 to remove the requirement – this is not going to be easy or > poss

Re: [OAUTH-WG] Basic questions about using the HTTP Authorization header

On Sat, Jul 10, 2010 at 10:41 PM, Andrew Arnott wrote: > Eran, > Is the draft 10 spec going to outline what characters are allowed in the > access token?  And if not (or if all characters are allowed), is it going to > include details about (or a reference to a doc about) how to properly escape >

[OAUTH-WG] simplify authorization header?

The current spec has the client create a "name='value'" syntax exactly once, in the Authorization header. We could eliminate a fair chunk of client code by removing the name="value" syntax and going with the approach taken by the Basic, NTLM, and Negotiate schemes: Authorization: OAuth2 No more

[OAUTH-WG] redirect URI matching in section 3

Section 3 says [[ provide guidance on how to perform matching ]]. I can write the guidance on performing redirect URI matching, but it varies per profile. User-Agent profile with registered client: matching is critical, MUST verify is appropriate Web server profile with client secret you trust:

Re: [OAUTH-WG] Basic questions about using the HTTP Authorization header

Eran, Is the draft 10 spec going to outline what characters are allowed in the access token? And if not (or if all characters are allowed), is it going to include details about (or a reference to a doc about) how to properly escape the access token when specifying it in the HTTP Authorization hea

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

that's a good idea from my point of view since it allows for more structured input. regards, Torsten. Hey folks - Today, the token endpoint takes form-encoded inputs, and sends JSON outputs. This requires developers to use both form encoding and a json parser. Many services expose symmetric

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

Hey folks - Today, the token endpoint takes form-encoded inputs, and sends JSON outputs. This requires developers to use both form encoding and a json parser. Many services expose symmetric APIs for non-browser endpoints. For example, an API call normally takes JSON input and returns JSON outpu

Re: [OAUTH-WG] user-agent flow needs a rewrite

On Sat, Jul 10, 2010 at 9:05 PM, Eran Hammer-Lahav wrote: > There is no user-agent flow anymore. Yeah. That's a bug. =( > The request was to allow it to > obtain both when using a web-based component together with the user-agent. Right, this didn't use to be possible, but Brian Ellin asked for

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

I think it would be a good idea to return to the draft 6 organization. Draft 6: normative language for each flow was called out separately, and was described from start to finish, in chronological order, with no interruption. Each step showed what a client should send, and what an authorization s

Re: [OAUTH-WG] user-agent flow needs a rewrite

There is no user-agent flow anymore. There is a profile (of the generic endpoints described in the rest of the spec). Draft -09 added the ability to get both an authorization code and an access token. Your description makes it sound like draft -09 broke something when it was never proposed that

[OAUTH-WG] user-agent flow needs a rewrite

The draft 9 spec has no efficient way for a javascript client to request a verification code. The spec creates extra client-to-server round trips. There is also some inaccurate description of the properties of the profile. The problems are located in section 1.4.2: http://tools.ietf.org/html/dra

Re: [OAUTH-WG] client credentials flow got dropped?

See 'grant_type=none' described in 4.1. EHL On 7/10/10 8:12 PM, "Brian Eaton" wrote: Hi folks - Draft 6 section 2.9.1 had a section called "Client Requests Access Token": http://tools.ietf.org/html/draft-ietf-oauth-v2-06#page-34. In this flow a client presented a client_id and client_secret,

Re: [OAUTH-WG] client credentials returning a refresh token

How about write some new text about what refresh tokens are for and when they should be issued. I think this can benefit from its own section. The rest is mostly editorial. EHL On 7/10/10 8:09 PM, "Brian Eaton" wrote: Hey folks - The client credentials flow should never return a refresh tok

[OAUTH-WG] client credentials flow got dropped?

Hi folks - Draft 6 section 2.9.1 had a section called "Client Requests Access Token": http://tools.ietf.org/html/draft-ietf-oauth-v2-06#page-34. In this flow a client presented a client_id and client_secret, and got an access token in return. I can't find the corresponding section in draft 7. I

[OAUTH-WG] client credentials returning a refresh token

Hey folks - The client credentials flow should never return a refresh token, for the following reasons: - it's never necessary - it's a security problem - it's inefficient - it's confusing I'll go over each of those points in detail, but here are the changes to the spec I'd like to see. Page 8:

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

On 7/10/10 7:46 PM, "Brian Eaton" wrote: > The term "access grant" in the -09 spec is a bit odd. Normally > "access grant" or "permission grant" would refer to a specific policy > decision made by a resource owner. > > But that's not how the -09 spec uses the term. The -09 spec refers to >

[OAUTH-WG] "access grant" terminology

The term "access grant" in the -09 spec is a bit odd. Normally "access grant" or "permission grant" would refer to a specific policy decision made by a resource owner. But that's not how the -09 spec uses the term. The -09 spec refers to authorization codes and assertions as "access grants". Ag

Re: [OAUTH-WG] proposal for signatures

On Sat, Jul 10, 2010 at 2:22 PM, Dick Hardt wrote: > Obviously anything besides what you need for your use case adds complexity. > The question is: are you willing to accept some complexity so that it works > for use cases than yours? If not, then perhaps you should just define your > own signatu

Re: [OAUTH-WG] proposal for signatures

On 2010-07-10, at 1:42 PM, David Recordon wrote: > On Sat, Jul 10, 2010 at 1:29 PM, Dick Hardt wrote: > On 2010-07-10, at 1:21 PM, David Recordon wrote: >> On Sat, Jul 10, 2010 at 11:00 AM, Dick Hardt wrote: > >>> * the signature comes before the payload >>> * we used the key 'algorithm' inste

Re: [OAUTH-WG] proposal for signatures

On Sat, Jul 10, 2010 at 1:29 PM, Dick Hardt wrote: > On 2010-07-10, at 1:21 PM, David Recordon wrote: > > On Sat, Jul 10, 2010 at 11:00 AM, Dick Hardt wrote: > > * the signature comes before the payload >> * we used the key 'algorithm' instead of 'alg' and 'expires' instead of >> 'not_before' >>

Re: [OAUTH-WG] proposal for signatures

On 2010-07-10, at 1:21 PM, David Recordon wrote: > On Sat, Jul 10, 2010 at 11:00 AM, Dick Hardt wrote: > On 2010-07-10, at 9:58 AM, Paul Tarjan wrote: >> Hi OAuthers, >> >> First of all, I think I should introduce myself. I work at Facebook on the >> Platform team (anything not facebook.com).

Re: [OAUTH-WG] proposal for signatures

On Sat, Jul 10, 2010 at 11:00 AM, Dick Hardt wrote: > On 2010-07-10, at 9:58 AM, Paul Tarjan wrote: > > Hi OAuthers, > > First of all, I think I should introduce myself. I work at Facebook on the > Platform team (anything not facebook.com). Before this I was at Yahoo! > doing SearchMonkey (semant

Re: [OAUTH-WG] proposal for signatures

I agree we don't want to end up like other protocols that were too generic. :) The use case I am arguing for is sending encrypted tokens. Higher levels of assurance require this and various people brought this up as a requirement when WRAP was presented at IIW 09B. -- Dick On 2010-07-10, at 11

Re: [OAUTH-WG] proposal for signatures

We need to get this into a proper draft (which I understand is on Dirk's list) and do a round of feedback before we promote this to a WG draft. I'm happy to help with editorial work if needed. Given the wide range of use cases, I think we need to keep this work focused on the use cases driving

Re: [OAUTH-WG] proposal for signatures

On 2010-07-10, at 9:58 AM, Paul Tarjan wrote: > Hi OAuthers, > > First of all, I think I should introduce myself. I work at Facebook on the > Platform team (anything not facebook.com). Before this I was at Yahoo! doing > SearchMonkey (semantic web stuff). I've written a few OAuth applications

Re: [OAUTH-WG] proposal for signatures

Hi OAuthers, First of all, I think I should introduce myself. I work at Facebook on the Platform team (anything not facebook.com). Before this I was at Yahoo! doing SearchMonkey (semantic web stuff). I've written a few OAuth applications and libraries, both at Yahoo and in

[OAUTH-WG] I-D: multiple access tokens

I just finished the first version of my I-D on "multiple access tokens" and would like to initiate a discussion whether the WG sees this as a potential WG item. Due to the pre-meeting cutoff date for submitting new drafts, I cannot submit it to the IETF site now. Since I don't want to lose wee

Re: [OAUTH-WG] Draft -09

If you have any more feedback for -09 please submit today. I plan to publish -10 by Monday which will be the last draft for 4 weeks, and hopefully a draft we can declare as stable for implementation. So if there is anything you really want to see changed, today is your last chance for a while.