Subject: [OAUTH-WG] First draft of OAuth 2.0

From: David Recordon <[email-masked]>
Date: Fri, 19 Mar 2010 18:28:45 -0700

As I mentioned a few weeks ago [1], I started working on editing the first draft of OAuth 2.0 over the past two weeks.  While I realize that it's 6pm Friday (sorry about that), I hope to have a solid discussion about it at Monday's meeting.  You can find the current draft of it – plus all of the document history – on my public GitHub account a thttp://github.com/daveman692/OAuth-2.0.  Eran will be doing an initial editing pass before Monday and then spend more time with it next week.

I've attached both a HTML and TXT copy to this email and plan to officially submit it as an Internet Draft.

The following are highlighted changes from draft-hardt-oauth-01:
   1.  A Web Client flow designed for use within JavaScript.  It also
       supports the use cases of the rich app profile so that they're
       not two separate flows.
   2.  A new device flows which is based on the Netflix/Tivo flow (TV
       shows you a code that you type in on your computer).
       http://www.ietf.org/mail-archive/web/oauth/current/msg01346.html
   3.  Remove captchas from the username/password flow.  They haven't
       been successfully implemented within this context and create
       complexity especially when we use other signals to detect
       compromised accounts.
       http://www.ietf.org/mail-archive/web/oauth/current/msg01293.html
   4.  Don't allow bearer tokens without either SSL and/or signatures.
       While some providers may offer this ability, they should be out
       of spec for doing so though technically it won't break the flows.
   5.  Abstract the refresh token flow out of each profile into its own
       section.  Support the ability to request access token secrets
       when refreshing.
   6.  Support signatures for making API requests but not for getting
       access tokens.  If you want to use signatures, you'll get an
       access token and then make a refresh call where you ask for a
       token secret.  This causes the auth server to mark the token as
       no longer being valid as a bearer token via SSL.  This
       performance tradeoff seems realistic given many use cases focus
       on high-volume API transactions and thus the one additional
       request at the onset should be noise.  The signature mechanism is
       currently from OAuth 1.0.

Obviously I couldn't have made so much progress so quickly if it weren't for WRAP and I hope that 2.0 both addresses the WRAP use cases as well as those we all have been discussing here.  I hope that I haven't missed anyone who contributed to prior work and am happy to add other authors if I have (and they wish to be added)!

Thanks,
--David

[1] http://www.ietf.org/mail-archive/web/oauth/current/msg01225.html

---

From: Eve Maler <[email-masked]>
Date: Sun, 21 Mar 2010 12:03:55 -0700

David, great stuff -- thanks for putting this together!  Here are a few comments and questions from a quick read on the plane down to Anaheim, in spec order (the weight/priority therefore varies widely).

Abstract

- "delegate": The use of this word seems like it's different from how it's been used in the past, e.g. in "user delegation".  It's not a big deal, but possibly confusing.

Introduction:

- I'm glad there's a hint here of "autonomously or on behalf of an end-user", but I notice the distinction between "user delegation flows" and "autonomous-client flows" introduced by WRAP seems to have been made more implicit in this draft.  UMA has an interest in understanding very carefully how flows get distinguished along these lines, and in fact we may need to define even more flows and types of flows for our own purposes (see our Lexicon at http://kantarainitiative.org/confluence/display/uma/Lexicon for more).  Hope to discuss this a bit tomorrow.  (And see more below in my comments on 2.5.)

- "provisioning tokens": I'd say resource owners don't personally provision tokens, but rather signal that authorization servers should do so on their behalf.

- The use of "server" in the intro is very natural.  See terminology comments below for more.

1.3. Terminology

- access token: The client might instead be making requests on behalf of itself, not "the user", right?

- authorization server and protected resource: These definitions cry out to have a formal definition of "server" (or "protected resource server"?) in this section as well, since "server" is already invoked quite naturally in a few places to mean the server of a protected resource.  Though the definition of protected resource says it's the resource served by an HTTP server, a few remaining WRAP-inherited instances of the term elsewhere try to force it to be both. I have some additional comments below that rely on a nice clean distinction between the authorization server and the server of a protected resource, because even though they're often colocated in pure-OAuth use cases, UMA makes strategic use of the option to separate them.  (Oh, also: s/A HTTP/An HTTP/)

- client identifier: s/used used/used/

- resource owner: "such that it issues...": This is a bit awkward.  Maybe say "to approve the issuing of an access token to a client"?

1.3.1. Endpoints

- "such as via documentation": FWIW, because UMA goes for dynamic introduction of various parties, we're using hostmeta and XRD to do this sort of thing.  Is there any wider interest in providing a (perhaps merely advisory) method of documentation that involves these technologies (or similar), to get greater interop?

- "API request": Because I'm coming from a mindset that sees all web resources as possibly being "OAuth-protected", and because we want to ensure the option of loose coupling between authorization server and protected resource server, I'm struggling to figure out (a) if calling this "API request" is too limiting given that maybe every resource on the server (e.g. every photo in a directory) is subject to a request for access, and (b) if this is something the protected resource server itself should advertise (vs. the authorization server), as appropriate.

- "user authorization request": s/resource owners's/resource owner's/g (the typo appears in a bunch of places)

2. Getting an Access Token

- "MUST implement at least one...": Are its implementation choices something the authorization server should advertise in documentation?

- It would be helpful to give really concrete examples/use cases of all of the profiles in the intro, so people can determine from this single place which profiles interest them.

2.1. Web Server Flow

- "without acquiring and end-user's credentials": Is this an obliquely stated version of "avoiding the 'password anti-pattern'"?  I think it could be useful to mention this phrase here somewhere.  Also, it's a little confusing to mention the resource owner and an end-user without seeming to connect them.

- oauth_callback_url: It says this is required, but what if the authorization server already required the client to pre-register this?

- "MUST first verify the identity of the resource owner": Should this be followed with "...and seek their approval of the authorization request" or similar?  (This whole thing doesn't seem testable since it's outside the view of the protocol, so I'm wondering if uppercase MUST is warranted.)

- oauth_error_reason: Does "user_denied" mean "the user denied the request"?  Since the spec holds out the (slim) possibility of the resource owner not being an end-user, should this be "resource_owner_denied" or "request_denied" or something?

- I'm thinking oauth_error_reason is where UMA could define an extension that gives an error like "claims_required".  I need to sort this out with my gang, but provide it here as food for thought.  Should we be defining our own parameter instead (and if so, should this spec say something about cases where this is done by others)?  Alternatively, should this spec allow for extended error codes in some formal fashion?

- "The server must retain the scope...": I *think* this means the authorization server, given that it's the one issuing the token, so this should be explicitly stated.  Keep in mind that UMA has reason to keep the kinds of servers architecturally separate, which means we needed to build a way for an UMA host (effectively an OAuth protected resource server) to be able to correlate the client's desired scope (as retained by the authorization server and baked into the issued token somehow, such that it can be validated when presented by the client) and the actual type of access attempted by the client.  Actually, I think OAuth has this need too, so perhaps UMA isn't all that different.

2.2. Web Client Flow

- s/a mobile device/on a mobile device/

- "the client is downloaded to the resource owner's user-agent": I *think* I can make sense of this, but the order just seems weird and backwards. :-)  Is the client, in fact, functioning as an HTTP user-agent itself?  Or is the client downloaded to the user's physical device (in which a separate user-agent is colocated)?

- "SHOULD verify that the callback URI provided ... is valid": Why not MUST?  It seems eminently doable.

2.3. Device Flow

- "The client MAY both poll and have...": Cleaner to say "The client MUST either poll or have an interface element, or both."

2.4. Username and Password Flow

- "The client MUST discard the resource owner's username...": This is obviously very desirable, but seems untestable.  Is the uppercase MUST warranted?

- "The authorization server ... MAY verify that the client is authorized to use this flow": Why and how would this MAY work?  I'm not quite understanding the goal here.

2.5. Client Identifier and Secret Flow

- "This flow is suitable when the client is also the resource owner": I think this was supposed to be the "two-legged"/"autonomous-client" solution, but this phrase throws that into doubt for me.  What was the intent here?  Note that UMA (like a lot of others) is interested in solving automated self-registration of an autonomous client at an authorization server.  (In case it's of interest, we've been trying to sort out the legal implications of parties who are *not* the resource owner seeking authorized access; this is where our "claims_required" stuff comes in.  Sometimes the client represents "itself", or rather a company or org acting on its own behalf; sometimes it represents a person different from the resource owner; etc.  See our Lexicon at http://kantarainitiative.org/confluence/display/uma/Lexicon.)

- Probably this is an effect of needing more time for study, but why does this profile not use oauth_error_code like the others do, relying only on a 401?

3. Refreshing an Access Token

- "The authorization server MUST verify that the resource owner...": This seems untestable.  Is the uppercase MUST warranted?

- "the protected resource MUST NOT allow the user of the corresponding access token without its secret": This is a case where "[protected resource] server" would work way better than "protected resource", as resources don't allow or disallow actions; they just exist.

4.1.2. Client Calls Protected Resource Using URL Query Parameter

- "Prior to making a request": Just FYI, UMA makes use of a key stage prior to a client making an access-token-bearing request; the client (UMA requester) can hit the resource out of the blue, and in this way learns the relevant access token request endpoint from the protected resource server (UMA host).

- "the following examples use the HTTP GET method": Should the wording here and in the next section ("The client constructs an HTTP 'POST'...") be rationalized to be more similar?

Look forward to discussing more tomorrow,

	Eve

> [1] http://www.ietf.org/mail-archive/web/oauth/current/msg01225.html

Eve Maler
[email-masked]
http://www.xmlgrrl.com/blog

---

From: John Panzer <[email-masked]>
Date: Sun, 21 Mar 2010 12:53:57 -0700

+1 to ensuring that dynamic introduction is possible.  I see a lot of
discussions that end up saying that this or that can be spec'd in the
server docs and the client hard coded to the docs; this is fine for
some features but not for very general ones that everybody needs to
use.

On Sunday, March 21, 2010, Eve Maler <[email-masked]> wrote:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
--
John Panzer / Google
[email-masked] / abstractioneer.org / @jpanzer

---

From: David Recordon <[email-masked]>
Date: Sun, 21 Mar 2010 13:43:30 -0700

The goal of the, "the authorization server advertises (such as via documentation) the URIs of the following three endpoints" wording was to allow for a discovery process that is defined separately from this spec.  Is that unclear?  Have other words to propose?

Eve, thanks for the detailed feedback!  Future email coming with commits or comments for each one.

--David

---

From: David Recordon <[email-masked]>
Date: Sun, 21 Mar 2010 15:51:32 -0700

Thanks!  Comments inline and updated the repo
(http://github.com/daveman692/OAuth-2.0/commit/3193098ff45168dd0a65456334428b20215f848a).

> - "delegate": The use of this word seems like it's different from how it's been used in the past, e.g. in "user delegation".  It's not a big deal, but possibly confusing.

Rephrased a bit, but someone should just rewrite the abstract to begin with.

> - I'm glad there's a hint here of "autonomously or on behalf of an end-user", but I notice the distinction between "user delegation flows" and "autonomous-client flows" introduced by WRAP seems to…

Made it more implicit, but not trying to remove the autonomous-client
flows.  Reworded a little.

> - "provisioning tokens": I'd say resource owners don't personally provision tokens, but rather signal that authorization servers should do so on their behalf.

Rephrased, but the entire introduction needs (re)writing.

> - access token: The client might instead be making requests on behalf of itself, not "the user", right?

Thanks, changed.

> - authorization server and protected resource: These definitions cry out to have a formal definition of "server" (or "protected resource server"?) in this section as well, since "server" is already…

Added the OAuth 1.0 definition.  Had it before, but someone convinced
me to remove it.

> - client identifier: s/used used/used/

Thanks!

> - resource owner: "such that it issues...": This is a bit awkward.  Maybe say "to approve the issuing of an access token to a client"?

Thanks!

> - "such as via documentation": FWIW, because UMA goes for dynamic introduction of various parties, we're using hostmeta and XRD to do this sort of thing.  Is there any wider interest in providing a…

This wording isn't meant to limit future discovery technologies.
Rephrased to "The client discovers the following three URI endpoints
from the server (such as via reading documentation):"

> - "API request": Because I'm coming from a mindset that sees all web resources as possibly being "OAuth-protected", and because we want to ensure the option of loose coupling between authorization…

Changed to "endpoint(s)" and removed "authorization" from the previous
sentence.  I think that we should stick with the "API Request"
wording.

> - "user authorization request": s/resource owners's/resource owner's/g (the typo appears in a bunch of places)

Thanks, fixed three times.

> - "MUST implement at least one...": Are its implementation choices something the authorization server should advertise in documentation?

I imagine so, but doing so seems orthogonal to the spec.

> - It would be helpful to give really concrete examples/use cases of all of the profiles in the intro, so people can determine from this single place which profiles interest them.

Each flow starts with one or two sentences trying to describe when
they should be used.  I'm perfectly willing to admin that they might
not be complete.  Happy to accept text from anyone! (Same goes for the
intro.)

> - "without acquiring and end-user's credentials": Is this an obliquely stated version of "avoiding the 'password anti-pattern'"?  I think it could be useful to mention this phrase here somewhere.…

Added.

> - oauth_callback_url: It says this is required, but what if the authorization server already required the client to pre-register this?

Always required even if pre-registered.  Makes the request really
explicit about what the client intends to have happen without relying
on magic.

> - "MUST first verify the identity of the resource owner": Should this be followed with "...and seek their approval of the authorization request" or similar?  (This whole thing doesn't seem testable…

I'll rely on Eran's editing pass to correct my must/MUST usage. :)

Could make seeking approval more defined, though the next sentence
begins with "If the resource owner approves the authorization
request".

> - oauth_error_reason: Does "user_denied" mean "the user denied the request"?  Since the spec holds out the (slim) possibility of the resource owner not being an end-user, should this be "resource_o…

Changed to "owner_denied".

> - I'm thinking oauth_error_reason is where UMA could define an extension that gives an error like "claims_required".  I need to sort this out with my gang, but provide it here as food for thought.…

Error codes are coming up quite a bit.  In general you should rely on
HTTP error responses, but there are cases where they're not specific
enough.  I'd really appreciate a list of error reasons that
implementors would like to see in the protocol.  A combined list will
help make it happen.  Seems like we should start a thread about this.

> - "The server must retain the scope...": I *think* this means the authorization server, given that it's the one issuing the token, so this should be explicitly stated.  Keep in mind that UMA has re…

Yes, the authorization server is what's meant.  Changed five times.

> - s/a mobile device/on a mobile device/

Thx.

> - "the client is downloaded to the resource owner's user-agent": I *think* I can make sense of this, but the order just seems weird and backwards. :-)  Is the client, in fact, functioning as an HTT…

Both.

> - "SHOULD verify that the callback URI provided ... is valid": Why not MUST?  It seems eminently doable.

Changed to MUST given that callback URL verification is one of the few
ways to protect this flow.

> - "The client MAY both poll and have...": Cleaner to say "The client MUST either poll or have an interface element, or both."

Changed.

> - "The client MUST discard the resource owner's username...": This is obviously very desirable, but seems untestable.  Is the uppercase MUST warranted?

Lowercased.

> - "The authorization server ... MAY verify that the client is authorized to use this flow": Why and how would this MAY work?  I'm not quite understanding the goal here.

Idea is that this flow will probably not be offerred to any client.  I
think Raffi is working on some text around making this flow seem
scarier already.  The goal is to discourage it's use given that the
other flows do a better job of protecting user security.

> - "This flow is suitable when the client is also the resource owner": I think this was supposed to be the "two-legged"/"autonomous-client" solution, but this phrase throws that into doubt for me.…

You're right.  Can you help reword please?

> - Probably this is an effect of needing more time for study, but why does this profile not use oauth_error_code like the others do, relying only on a 401?

See earlier reply on error codes.  Happy to add some if they're well defined.

> - "The authorization server MUST verify that the resource owner...": This seems untestable.  Is the uppercase MUST warranted?

Will let Eran fix.

> - "the protected resource MUST NOT allow the user of the corresponding access token without its secret": This is a case where "[protected resource] server" would work way better than "protected res…

hmm, does read a bit better in most cases.  Means changing the
definition as well.  What do others thing?

> - "Prior to making a request": Just FYI, UMA makes use of a key stage prior to a client making an access-token-bearing request; the client (UMA requester) can hit the resource out of the blue, and…

Sure, don't see this spec as limiting that.

> - "the following examples use the HTTP GET method": Should the wording here and in the next section ("The client constructs an HTTP 'POST'...") be rationalized to be more similar?

Hoping Eran cleans this up a bit more.

> Look forward to discussing more tomorrow,

Definitely, looking forward to it!

Thanks again!

--David

---

From: Eve Maler <[email-masked]>
Date: Sun, 21 Mar 2010 18:12:01 -0700

> The goal of the, "the authorization server advertises (such as via documentation) the URIs of the following three endpoints" wording was to allow for a discovery process that is defined separately…

So perhaps this wants to be a thin spec that can be combined with the OAuth core spec, if there's general interest in it.  (In the UMA spec, we were already in the position of making up some XRD to describe a couple of WRAP endpoints, along with UMA endpoints and metadata.  It would be nice to have a canonical version of the former, at the least.)

> Eve, thanks for the detailed feedback!  Future email coming with commits or comments for each one.

Hopefully sometime before the actual meeting tomorrow, I'll respond with spec text ideas where you -- very reasonably :-) -- asked me to supply some.

	Eve

Eve Maler
[email-masked]

---

From: Eve Maler <[email-masked]>
Date: Sun, 21 Mar 2010 20:26:09 -0700

Selected thoughts in response:

> Rephrased a bit, but someone should just rewrite the abstract to begin with.

I can stab at this by Friday, if someone else doesn't get there first...

> not be complete.  Happy to accept text from anyone! (Same goes for the

Another item I may get a chance to play with by the end of the week.

> help make it happen.  Seems like we should start a thread about this.

I'll raise the question of the claims_required code at the UMA meeting on Thursday, and feed back any input.

> You're right.  Can you help reword please?

How about simply: "This flow is suitable when the client acts autonomously in seeking access and is thus not accessing protected resources within the context of a given end-user."

> definition as well.  What do others thing?

(I think it's all hanging together nicely now, but I'm biased. :-)  Note that there are still some instances of "protected resource" that now want to be "server" -- I see one in the first sentence of 4.1.1, and this probably happens all over section 4.

A final new comment: The spec says nothing at all about how a token gets validated, which may be fine, but given that several different means of token validation have been discussed (here and on the WRAP list of late), should something explicit be said that puts the validation method out of scope for this spec?

	Eve

	Eve

Eve Maler
[email-masked]

---

From: David Recordon <[email-masked]>
Date: Sun, 21 Mar 2010 21:36:30 -0700

> I can stab at this by Friday, if someone else doesn't get there first...

Awesome!

> How about simply: "This flow is suitable when the client acts autonomously in seeking access and is thus not accessing protected resources within the context of a given end-user."

Done, thanks!

> A final new comment: The spec says nothing at all about how a token gets validated, which may be fine, but given that several different means of token validation have been discussed (here and on th…

I think that this should remain out of scope.  As far as OAuth is
concerned the token should be opaque and up to authorization servers
and protected resource servers to choose what goes into each token.

--David

---

From: "Manger, James H" <[email-masked]>
Date: Mon, 22 Mar 2010 23:11:34 +1100

Thanks for writing this draft for OAuth 2.0, David.
A couple of comments.

1. CLIENT SECRET
Client authentication needs to be independent of OAuth.
The Web Server Flow sends oauth_client_secret to the access token request endpoint along with other oauth_ parameters. This is a poor design.

Consider, for instance, a service that authenticates clients with TLS client certs. Such clients don't have a shared secret to put in the oauth_client_secret parameter so they cannot perform protocol in this OAuth 2 draft.
Even if client certs are rare, the issue is that there is no reason why client certs should prevent OAuth 2 from working.

Servers that can authenticate clients are likely to offer them various APIs in addition to the OAuth get-a-token calls. The same client authentication mechanism used for those calls should be reused for the get-a-token calls.

I suggest dropping the oauth_client_secret, perhaps adding text such as:
"Servers that require clients to be pre-registered may require this client request to be authenticated."

2. STATE
OAuth has various parameter that are used to carry state for another party in a message, which is helpful for building scalable systems. OAuth should avoid duplicating these fields or defining their semantics when they are opaque to the party carrying them. This will keep the protocol simpler, without losing any functionality.

oauth_client_state is unnecessary as it is always accompanied by oauth_callback_url that can encode the state directly. The examples could include, say, ...callback_url=http://client.example.com/cb%3Fstate=FSR63fs&oauth_mode=... to reflect likely cases. It is still simple to compare the callback to a pre-register value if required (eg compare suffix, or compare ignoring additional query params).

oauth_scope is unnecessary as it is server-specific and can be encoded directly in the server-specific URIs. A client with no server-specific knowledge has no way of using oauth_scope, which is a sign it is better omitted from the spec and left to specific servers when describing their access/authz URIs. I have no problems with a service saying its user authz URI is, say, http://example.com/authz?scope={all|blog}.

And a few minor issues:

3. If you want to return error params in the body of a 401 the important feature is setting Content-Type to application/x-www-form-urlencoded. This isn't mentioned in the text or example.

4. The Username and Password Flow has oauth_client_secret in the example but not in the expected list of parameters.

5. Just call it TLS (not TLS/SSL).

-- 
James Manger

---

From: "Manger, James H" <[email-masked]>
Date: Mon, 22 Mar 2010 23:29:55 +1100

Another +1 for "dynamic introduction".
Putting the required details (eg user authz URI) in a 401 HTTP WWW-Authenticate header feels like a better approach to me than XRD in this instance.

At the moment in the OAuth 2 draft (and in WRAP) identical 401 responses can mean:
1. Send the user to an authz server to authorize you.
2. Make a request to another server to swap your long term credentials for temporary ones.
3. Refresh your credentials at another server.
4. Authentication failed, go away.
This does not feel like a web-style approach.

--
James Manger

----------
From: [email-masked] [mailto:[email-masked]] On Behalf Of John Panzer
Sent: Monday, 22 March 2010 6:54 AM
To: Eve Maler
Cc: OAuth WG
Subject: Re: [OAUTH-WG] First draft of OAuth 2.0

---

From: Luke Shepard <[email-masked]>
Date: Mon, 22 Mar 2010 07:53:59 -0700

Few responses inline.

> "Servers that require clients to be pre-registered may require this client request to be authenticated."

It would be great to support client certificates as a means to authenticate OAuth applications. However, that should be a new flow, as it has different security characteristics.

<snip>

> 4. The Username and Password Flow has oauth_client_secret in the example but not in the expected list of parameters.

Mistake. It should not have client secret. This flow also could benefit from client certs, if available, but again, that is a new flow definition.

> 5. Just call it TLS (not TLS/SSL).

Many people are familiar with SSL, not TLS, and so this clarifies for those readers.

---

From: David Recordon <[email-masked]>
Date: Mon, 22 Mar 2010 10:52:16 -0700

Thanks for the feedback!  Inline...

> "Servers that require clients to be pre-registered may require this client request to be authenticated."

Agreed with Luke.  This should be a new flow if you're using TLS client certs.

> oauth_client_state is unnecessary as it is always accompanied by oauth_callback_url that can encode the state directly. The examples could include, say, ...callback_url=http://client.example.com/cb…

Has there been any discussion of the oauth_client_state parameter on
the list?  I don't really remember it.

> oauth_scope is unnecessary as it is server-specific and can be encoded directly in the server-specific URIs. A client with no server-specific knowledge has no way of using oauth_scope, which is a s…

Scope is something that we've seen used by many OAuth 1.0 providers so
adding a consistant parameter to represent it makes sense.  There's
still not alignment on what individual scopes actually mean, but
hopefully we'll get there (outside of this spec).

> 3. If you want to return error params in the body of a 401 the important feature is setting Content-Type to application/x-www-form-urlencoded. This isn't mentioned in the text or example.

hmm, I'll double check but I think it's mentioned in the flows which
contain explicit error parameters.  There's an entire other debate
about if it's too difficult to parse form encoded parameters in a HTTP
response (versus a request where they normally are).  I've also been
asking folks to start documenting the error conditions they'd like to
see represented.

> 4. The Username and Password Flow has oauth_client_secret in the example but not in the expected list of parameters.

Fixed, thanks!

> 5. Just call it TLS (not TLS/SSL).

+1 to what Luke said.  SSL means something to far more people than TLS does.

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 23 Mar 2010 09:54:57 +1100

Luke & David,

The different security characteristics of TLS client certs (or TLS-PSK, or TLS-SRP, or HTTP BASIC, or cookies, or IPsec...) vs oauth_client_secret-in-body don't require any change to the *flow*. The interaction model does not change.

We need to limit the complexity of adding new flows to situations were they are necessary:
Web servers can keep app secrets, web clients cannot => separate flows.
Web servers can redirect browsers, devices have no browser => separate flows.
3-legged involves 3 parties, 2-legged only has 2 parties => separate flows.
"red" client auth, "blue" client auth => same flows work.

This is not an issue about client certs -- certs are just one stark example.

-- 
James Manger

----------
Subject: Re: [OAUTH-WG] OAuth 2.0: client_secret, state

> "Servers that require clients to be pre-registered may require this client request to be authenticated."

Luke said:

David said:

---

From: Allen Tom <[email-masked]>
Date: Mon, 22 Mar 2010 16:20:48 -0700

Hi All -

Regarding the client secret - one of the design goals for OAuth-WRAP was to
cleanly separate the AuthZ server from the Protected Resource. The Protected
Resource should only have to know how to validate Access Tokens issued by
its AuthZ server.

The HMAC-SHA1 signature method defined in 4.2.1.1 of the Oauth 2.0 spec
violates this principle because it requires the protected resource to have
the client secret in order to validate the signature. Distributing the
client secret to all Protected Resources can have negative security and
performance implications.

http://www.ietf.org/mail-archive/web/oauth/current/msg01396.html#compute_sig

I recommend removing the client secret from the signature calculation, and
instead using only the Access Token secret.

Allen

---

From: David Recordon <[email-masked]>
Date: Mon, 22 Mar 2010 18:50:33 -0700

Hey Allen,
Thanks for the feedback! I'm planning to remove the client secret from
the signature mechanism as I heard this from someone else as well.

--David

---

From: Richard Barnes <[email-masked]>
Date: Mon, 22 Mar 2010 22:19:24 -0700

Actually, Brian and I discussed this very topic at some length after  
the OAuth after-party today.  If you think about it, it is impossible  
to completely separate the Authz Server (AS) from the Protected  
Resource (PR) -- in all of the possible cases, the AS needs to be able  
to pass secure messages to the PR, in one form or another.

In the signing cases, this is obvious: The AS needs to provide the PR  
with a key to validate signatures (either a MAC key or a public key).   
However, it remains true even for bearer tokens, since the AS needs to  
communicate to the PR which tokens are valid tokens.  This  
communication needs to be secure, so that tokens can't be spoofed.

In either case (signing or bearer), secured validation information has  
to get passed from the AS to the PR.  Based on the phrase "validate  
Access Tokens", it sounds like you're already acknowledging that the  
token can have internal structure that constitutes a secure message  
from the AS (e.g., if token == request-uri + signature).  But even  
that assumes that the AS and the PR share a key pair (symmetric or  
asymmetric).

If you make the same two assumptions -- shared keys and structured  
tokens -- then the signing cases can also work via the token: You can  
just encrypt the validation key (MAC key or public key) with the  
shared key and put it in the token.

So from the perspective of the need for a relationship between AS and  
PR, there is absolutely no difference between the "bearer token" and  
"signing" use cases.

--Richard

---

From: Chuck Mortimore <[email-masked]>
Date: Tue, 23 Mar 2010 01:09:59 -0700

Just getting a chance to review this – I apologize for not getting this before the meeting started.

We’d like to see some form of an Assertion Profile, similar to section 5.2 from draft-hardt-oauth-01.   We have strong customer use-cases for an assertion based flow, specifically SAML bearer tokens, and I believe Microsoft may have already shipped a minor variation on this ( wrap_SAML ) in Azure.

Here’s a rough stab – hopefully others interested in this profile can comment.

---------------------------------------------

Assertion Flow

This flow is used when the client wishes to exchange an existing security token or assertion for an oauth_access_token.    This flow is suitable when the client is acting on behalf of either itself or the end-user, it is not possible to use one of the end-user authorized flows, and a password based profile is not desirable.

Prior to making a request using this flow, the client MUST have obtained a client identifier, and established a means for obtaining an assertion to be presented to the authorization server.  Both the assertion formats, the method for obtaining those assertions, and the method of validating those assertions are beyond the scope of this specification.

The client constructs an HTTP "POST" request to the access token request endpoint and includes the following REQUIRED parameters:

    oauth_mode
        The parameter value MUST be set to "flow_assertion" (case sensitive).
    oauth_client_identifier
        The client identifier.
    oauth_assertion_format
        The assertion format – likely a normative URI, for instance: urn:oasis:names:tc:SAML:2.0:cm:bearer
    oauth_assertion
        <assertion> - b64 encoded

The client MAY also include the following OPTIONAL parameters as well as any additional parameters as defined by the authorization server:

    oauth_scope
        If the authorization server has defined a manner for the client to request certain capabilities of the access token, this parameter SHOULD be used to do so.

For example, the client makes the following HTTPS request:

    POST /access_token HTTP/1.1
    Host: server.example.com
    oauth_mode=flow_assertion&oauth_client_identifier=s6BhdRkqt3& oauth_assertion_format= urn:oasis:names:tc:SAML:2.0:cm:bearer& oauth_assertion=<base64 encoded saml>

The authorization server MUST verify that the presented assertion is valid and derive the resource owner.  The authorization server MAY verify that the client is authorized to use this flow. If the request is authorized, the access token is included in the HTTP response body using the "application/x-www-form-urlencoded" content type as defined by [W3C.REC‑html40‑19980424] (Ragget, D., Ed., Le Hors, A., Ed., and I. Jacobs, Ed., “HTML 4.0 Specification,” .) with a 200 status code (OK).

The response contains the following REQUIRED parameter:

    oauth_access_token
        The access token.

The authorization server MAY also include the following parameters:

    oauth_expires
        The lifetime of the access token in seconds.
    oauth_refresh_token
        The refresh token.

For example:

    HTTP/1.1 200 OK
    Content-Type: application/x-www-form-urlencoded

    oauth_access_token=FJQbwq9OD8&oauth_refresh_token=gO3CHNqpH8

The authorization server must retain the scope, duration, and other attributes approved by the resource owner, and enforce these restrictions when receiving a client request made with the tokens issued.

Once the client receives and stores the token credentials, it can proceed to access protected resources on behalf of the resource owner by making authenticated requests (Section 4 (Accessing a Protected Resource)) using the access token received.

If the request fails verification, the authorization server SHOULD respond with the appropriate HTTP response status code. The authorization server MAY include further details about why the request was rejected in the response body.

For example:

    HTTP/1.1 401 Authorization Required
    WWW-Authenticate: OAuth realm="example"

---------------

Also, your examples of the initial post in 2.4 and 2.5 seem to be missing the oauth_mode parameter.

Thanks for your work here!

-cmort

On 3/19/10 6:28 PM, "David Recordon" <[email-masked]> wrote:

Thanks,
--David

---

From: Mark Mcgloin <[email-masked]>
Date: Tue, 23 Mar 2010 11:42:03 +0000

+1 for assertion profile. Was there any reason why it was dropped?

>We’d like to see some form of an Assertion Profile, similar to section 5.2
from draft-hardt-oauth-01.   We have strong customer use-cases for an
assertion based flow, specifically SAML bearer tokens, and I >believe
Microsoft may have already shipped a minor variation on this ( wrap_SAML )
in Azure.

Mark McGloin

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 23 Mar 2010 12:50:33 +0100

+1 for assertion support

what about enhancing the flow #2.4 to accept any kind of user  
credentials (username/password, SAML assertions, other authz servers  
tokens)

regards,
Torsten.

Am 23.03.2010 um 12:42 schrieb Mark Mcgloin <[email-masked]>:

>> Just getting a chance to review this – I apologize for not getting 
>>  this
> before the meeting started.
>

---

From: John Panzer <[email-masked]>
Date: Tue, 23 Mar 2010 10:25:23 -0700

On Sun, Mar 21, 2010 at 6:12 PM, Eve Maler <[email-masked]> wrote:

> > The goal of the, "the authorization server advertises (such as via
> documentation) the URIs of the following three endpoints" wording was to
> allow for a discovery process that is defined separately from this spec.  Is
> that unclear?  Have other words to propose?
>
> So perhaps this wants to be a thin spec that can be combined with the OAuth
> core spec, if there's general interest in it.  (In the UMA spec, we were
> already in the position of making up some XRD to describe a couple of WRAP
> endpoints, along with UMA endpoints and metadata.  It would be nice to have
> a canonical version of the former, at the least.)
>

So,

Minimally, perhaps the spec should say "advertises (such as via
documentation or discovery process beyond the scope of this document) the
URIs of the following three endpoints..."  just to give people a heads up
that there may be external auto-discovery happening.

Beyond that, it might be nice to see if there could be a separate, svelte
auth discovery document of some sort, even if not part of the core spec.
 Even something UMA-specific could serve as a good example for others.

My main worry is that SPs might start to think that they can do all kinds of
arbitrary things in their documentation to find the endpoints (register here
to generate the endpoints for your app, etc.) and thus go down a path that
means they can't ever participate in auto-discovery.  Which is a fine path
if they explicitly decide they don't care about auto-discovery and interop,
but a poor path if they just didn't see the signs about the quicksand and
alligators and non-interoperability.

---

From: David Recordon <[email-masked]>
Date: Tue, 23 Mar 2010 10:44:50 -0700

Thanks John; incorporated your wording.
http://github.com/daveman692/OAuth-2.0/commit/4c93341a85c70c0954945be636a8dce359fccb0f

On Tue, Mar 23, 2010 at 10:25 AM, John Panzer <[email-masked]> wrote:
>> So perhaps this wants to be a thin spec that can be combined with the
>> OAuth core spec, if there's general interest in it.  (In the UMA spec, we
>> were already in the position of making up some XRD to describe a couple of
>> WRAP endpoints, along with UMA endpoints and metadata.  It would be nice to
>> have a canonical version of the former, at the least.)
>
> So,

---

From: David Recordon <[email-masked]>
Date: Tue, 23 Mar 2010 10:47:59 -0700

Hey Chuck,
Thanks for rewriting the SAML flow into the style of my draft!  I
really appreciate it.

I originally dropped the SAML flow because I hadn't seen support for
it on the mailing list(s) the past two months.  I think that our
default should be making the spec as short and simple as possible so
removed a few things from WRAP in order to start conversations like
this one.  It's now clear that Google, Microsoft, Salesforce, and IBM
all need the SAML profile.  Chuck, I'll merge your wording in.  Want
to be listed as an author?

We're also going to need to figure out which flows should be in the
core spec versus which should be developed at the same time but in
individual documents.

Thanks,
--David

On Tue, Mar 23, 2010 at 4:50 AM, Torsten Lodderstedt
<[email-masked]> wrote:
> +1 for assertion support
>
> what about enhancing the flow #2.4 to accept any kind of user credentials
> (username/password, SAML assertions, other authz servers tokens)
>
> regards,
> Torsten.
>
>>> Just getting a chance to review this – I apologize for not getting this
>>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 23 Mar 2010 19:14:14 +0100

Hi David,

I have a couple of questions/comments:

§2 - The flows use shared secrets for client authentication only. What 
about adding support for public-key-based signatures for that purpose as 
an alternative? That's one of the use cases on 
http://trac.tools.ietf.org/wg/oauth/trac/wiki/SignaturesWhy

§2.4 - Looks like a POST-Request in combination with a password-based 
user authentication. What about using a standard BASIC Authorization 
Header instead of oauth_username and oauth_password? In that way, 
existing code for BASIC-Authentication can easily be ported to OAUTH.

§3
- Why is the parameter oauth_client_secret required for refreshing 
access tokens? Use cases 2.2 and 2.3 do not require the client to use 
(possess) a secret. Does this imply such client are not entitled to 
refresh tokens? I would suggest to simply remove this parameter.

- Why is the refresh method the only way to obtain token secrets? This 
forces every client needing a token secret to perform two calls (and get 
a useless access token in the first call). I would suggest to add the 
parameter oauth_want_secret to all flows in §2.

- "If an access token secret is included in the response, the protected 
resource MUST NOT allow the use of the corresponding access token 
without its secret .... " Why is that neccessary?

- response value oauth_signature_methods: Why is it the obligation of an 
autorization server to know the signature methods a protected resource 
supports? IMHO this is a question of the protocol between client and 
protected resource and the client should pass in to the request the 
desired signature method. In that way the authorization server is able 
to create adequate secret.

§4.1 Why do you want to enforce such a strong coupling between bearer 
tokens and TLS per spec? I would recommend to split protocol definition 
and security considerations as in RFC2617. There, BASIC authentication 
is defined without any references to transport security mechanisms and 
the relevant considerations/recommandations are discussed in the 
security consideration section. IMHO this would simplify the 
specification because bearer token requests and requests w/ access 
tokens + signature would just be variant of the same protocol definition.

§4.2.2 The WWW-Authenticate header does not give the client any hint 
what signature methods to use. How shall the client that information obtain?

regards,
Torsten.

---

From: Paul Madsen <[email-masked]>
Date: Tue, 23 Mar 2010 14:17:09 -0400

Separate from the Client trading a SAML assertion for an Access Token as 
in this flow, we are interested in defining how a Client might use SAML 
SSO messages to get an Access Token (comparable to OpenID/OAuth hybrid).

Anybody else interested?

paul

On 3/23/2010 1:47 PM, David Recordon wrote:
>> Am 23.03.2010 um 12:42 schrieb Mark Mcgloin<[email-masked]>:
>>
>>      
>>> assertion based flow, specifically SAML bearer tokens, and I>believe

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 23 Mar 2010 19:17:53 +0100

Hi David,

would it simplify the specification if there would be a generic workflow 
in section 2 which defines the parameters that are common to all flows?

regards,
Torsten.

---

From: Allen Tom <[email-masked]>
Date: Tue, 23 Mar 2010 11:42:09 -0700

Hi Richard,

>From a security perspective, it might be undesirable to distribute the
client secret to all potential protected resources that a client might want
to access.

In many ways, distributing the client secret to all PRs is undesirable in
the same way that it's undesirable to distribute the user's password to all
PRs. Even if the client secret is encrypted into the Access Token, it has to
be extracted by the PR to verify the signature (at least using the current
version of the Oauth 2.0 spec).

If the client secret is distributed to the PR, the PR would be able to
impersonate the client. (Unlike Oauth 1.0, the PR and the AuthZ server are
separate entities)

Admittedly, with Oauth-WRAP, the PR would still have a client's access
token, however, the access token could be scoped to be only valid for the
PR, so a PR might not be able to impersonate the client by replaying the
access token, and also the Access Token has a limited lifetime.

Hope that helps to clarify things,
Allen

---

From: Dick Hardt <[email-masked]>
Date: Tue, 23 Mar 2010 11:58:41 -0700

David: perhaps if you asked the list about features before dropping
them we would not all have to argue with you about why to put them
back in. Frankly I was surprised that you did not circulate the draft
to me as editor of WRAP.

WG Chairs: Is this draft now the draft that the WG is working on and
is David now the editor for the WG?

-- Dick

On 2010-03-23, at 10:47 AM, David Recordon <[email-masked]> wrote:

>> credentials
>>>> We’d like to see some form of an Assertion Profile, similar to
>>>>  section
>>>> 5.2
>>>
>>> assertion based flow, specifically SAML bearer tokens, and I
>>> >believe

---

From: David Recordon <[email-masked]>
Date: Tue, 23 Mar 2010 12:01:14 -0700

Inline and thanks for the feedback!

On Tue, Mar 23, 2010 at 11:14 AM, Torsten Lodderstedt
<[email-masked]> wrote:
> §2 - The flows use shared secrets for client authentication only. What about
> adding support for public-key-based signatures for that purpose as an
> alternative? That's one of the use cases on

I think it's reasonable to design a flow which uses public-keys to
authenticate the client for an access token. You'd probably do
something like this for the device flow if you actually want to
authenticate the device as TPM is becoming more prevalent.  Including
the secret over SSL keeps the protocol simpler for developers.

> §2.4 - Looks like a POST-Request in combination with a password-based user
> authentication. What about using a standard BASIC Authorization Header
> instead of oauth_username and oauth_password? In that way, existing code for
> BASIC-Authentication can easily be ported to OAUTH.

You're the first to mention that AFAIK. I'd be interested in if it
would be useful to service providers like Twitter who already use
basic and digest auth.  My guess is that just including the username
and password as parameters is actually simpler given that you'll be
building this in an authorization flow.  Most sites which use
basic/digest for API authentication are doing so to actually make API
requests so they'll need to write new code to support OAuth in the
first place.

> §3
> - Why is the parameter oauth_client_secret required for refreshing access
> tokens? Use cases 2.2 and 2.3 do not require the client to use (possess) a
> secret. Does this imply such client are not entitled to refresh tokens? I
> would suggest to simply remove this parameter.

It shouldn't be required.  Fixed!
http://github.com/daveman692/OAuth-2.0/commit/a30843724f241f3ea1052c83dcfec0127a11fe00

> forces every client needing a token secret to perform two calls (and get a
> useless access token in the first call). I would suggest to add the

Protocol simplicity. Signatures are meant to be used in advanced cases
and should not distract 95% of developers who will never touch them.
The main use cases for signatures is based around performance in
extremely high volume API interactions. Thus one extra HTTP request at
the start should pale in comparison to the number of API requests
which will actually be made using that secret.

> resource MUST NOT allow the use of the corresponding access token without
> its secret .... " Why is that neccessary?

When acting as a bearer token the access token is all powerful and
must be kept secret between the client and servers. In the signature
flow (if you're not also using SSL) then the access token is sent over
the wire. Thus a MITM could get the access token and make SSL requests
without this requirement.

> protected resource and the client should pass in to the request the desired
> signature method. In that way the authorization server is able to create
> adequate secret.

hmm. I guess the protected resource(s) always knows about the
authorization server though it's conceivable that the authorization
server doesn't know about every protected resource. This seems far
simpler than the client needing to negotiate the signature mechanism
with each protected resource. Is there someone developing a deployment
where the drafted model (from 1.0a) doesn't work?

> §4.1 Why do you want to enforce such a strong coupling between bearer tokens
> and TLS per spec? I would recommend to split protocol definition and
> security considerations as in RFC2617. There, BASIC authentication is
> defined without any references to transport security mechanisms and the
> relevant considerations/recommandations are discussed in the security
> consideration section. IMHO this would simplify the specification because
> bearer token requests and requests w/ access tokens + signature would just
> be variant of the same protocol definition.

I think this comes out of making the spec really easy to implement.
The style of the spec is very much designed for implementors writing
code as they're reading.

> §4.2.2 The WWW-Authenticate header does not give the client any hint what
> signature methods to use. How shall the client that information obtain?

Right now it's obtained via the signature methods parameter. Is there
an easy way to add it in this 401 response?

Thanks!
--David

---

From: Chuck Mortimore <[email-masked]>
Date: Tue, 23 Mar 2010 12:05:23 -0700

No worries - I figured it would be easier to push for it's inclusion if the work were minimal.

We will definitely need to implement this style of profile, as will many others, so it's essential it ends in some spec.   Personally I'd rather see a relatively thin spec that includes the critical profiles, rather than core + profile + bindings + etc like SAML.   However I'm open to any approach that get's the profile included.

I'd be happy to be listed as an author, but it's more important that whomever authored the original assertion profile get listed/credit.   Not sure if that was Dick or one of the other authors...perhaps they can chime in.

-cmort

On 3/23/10 10:47 AM, "David Recordon" <[email-masked]> wrote:

Hey Chuck,

Thanks,
--David

On Tue, Mar 23, 2010 at 4:50 AM, Torsten Lodderstedt
<[email-masked]> wrote:
>>> Just getting a chance to review this - I apologize for not getting this
>>
>>> We'd like to see some form of an Assertion Profile, similar to section
>>> 5.2
>>

---

From: David Recordon <[email-masked]>
Date: Tue, 23 Mar 2010 12:10:27 -0700

> No worries - I figured it would be easier to push for it's inclusion if the

Yeah, definitely!

> We will definitely need to implement this style of profile, as will many
> others, so it's essential it ends in some spec.   Personally I'd rather see
> a relatively thin spec that includes the critical profiles, rather than core
> + profile + bindings + etc like SAML.   However I'm open to any approach
> that get's the profile included.

I'd like to pull the username/password and SAML flows into their own
documents.  I don't think that we want to propagate the usage of the
password anti-pattern and while I'm hearing clearly that the SAML flow
is needed, I don't think it will be used by the majority of deployers.

We should develop both of these flows at the same time as the core
spec so that they all go together.

> I'd be happy to be listed as an author, but it's more important that
> whomever authored the original assertion profile get listed/credit.   Not
> sure if that was Dick or one of the other authors...perhaps they can chime
> in.

Sure. I'd rather make sure everyone gets credit and then we can work
out what the spec says at the end.  OAuth 1.0 lists almost twenty
contributors.  I tried to be extremely humble in my acknowledgments
section especially given that I hadn't spoken to every WRAP author.

> This (early) draft was written pretty quickly and is heavily based on
> The OAuth 1.0 Protocol [draft-hammer-oauth-10], OAuth WRAP
> [draft-hardt-oauth-01] and further discussion on the IETF OAuth
> Working Group mailing list. Those authors and editors include Allen
> Tom (Yahoo!), Brian Eaton (Google), Dick Hardt, Eran Hammer-Lahav
> (Yahoo!) and Yaron Goland (Microsoft).

--David

---

From: David Recordon <[email-masked]>
Date: Tue, 23 Mar 2010 12:16:30 -0700

On Tue, Mar 23, 2010 at 11:58 AM, Dick Hardt <[email-masked]> wrote:
> back in.

My goal by removing some of the non-obvious things was to encourage
the discussion which has now started! Many of the design decisions
that went into WRAP haven't entirely been shared in public. Since one
of our major goals is developer simplicity it's reasonable to start
with less and justify everything that's being added.  As the working
group has seen, I'm really willing to add things back in once the
reasoning has been explained (error codes, SAML flow, etc).

> Frankly I was surprised that you did not circulate the draft
> to me as editor of WRAP.

I focused on getting feedback from consumer web deployers of OAuth 1.0
(Twitter and Digg) who haven't participated in these discussions yet
as they're extremely important to technology adoption.  I also spoke
to Google, Microsoft, and Yahoo! as they were the three companies who
developed WRAP together.  I'm sorry if I rubbed you the wrong way, but
until this IETF meeting I didn't know that you were planning to deploy
OAuth 2.0 as you were no longer working for Microsoft.  This shouldn't
prevent us from working together on making OAuth 2.0 rock. :)

---

From: David Recordon <[email-masked]>
Date: Tue, 23 Mar 2010 12:19:42 -0700

Missed it, included now!
http://github.com/daveman692/OAuth-2.0/commit/099c51025d33e9a9350468c3e57482785d9826e8

On Tue, Mar 23, 2010 at 12:09 PM, Chuck Mortimore
<[email-masked]> wrote:
> By the way, did you see my little note at the end?   It was kind of buried.
>
>
> I think the oauth_mode param is missing from your initial POST examples in
> 2.4 and 2.5
>
> -cmort
>
>

---

From: Richard Barnes <[email-masked]>
Date: Tue, 23 Mar 2010 13:28:53 -0700

Allen,

Right, the PR needs to have the client's access token so that it knows  
which access tokens to accept.  The AS issues the access token, so in  
order for the PR to know the access token, the AS need to send a  
secure message to the PR saying that "this access token is OK".  This  
communication can happen either directly or indirectly:
-- Direct: AS tells PR which access tokens are valid
-- Indirect: AS signs access token

Either way, the PR has to be able to authenticate messages from the  
AS, so it has to have a public key or shared key for the AS.  That  
same key could be used to communicate keys to validate signatures from  
clients (access token secrets).

So disallowing signatures actually doesn't save you anything in terms  
of the crypto that the PR and AS need.

--Richard

---

From: Chuck Mortimore <[email-masked]>
Date: Tue, 23 Mar 2010 17:15:33 -0700

Outside the scope of what this WG should be tackling in the core spec IMO, but I'd be interested in working on a profile.   There is a lot of this use-case being done in an ad-hoc manner on my platform.

-cmort

On 3/23/10 11:17 AM, "Paul Madsen" <[email-masked]> wrote:

Anybody else interested?

paul

---

From: Brian Eaton <[email-masked]>
Date: Tue, 23 Mar 2010 17:56:07 -0700

> http://github.com/daveman692/OAuth-2.0/commit/a30843724f241f3ea1052c83dcfec0127a11fe00

It was required in WRAP because is lets you recover if a client web
server that holds many refresh tokens is compromised.  You rotate the
client secret, and then the attacker loses access to user data.

Please add it back. =)

---

From: David Recordon <[email-masked]>
Date: Tue, 23 Mar 2010 18:51:06 -0700

What about clients which don't have access to the client secret? For
example, rich desktop applications and devices.

Seems like if the client secret is optional then a server can enforce
in policy what type of clients must pass it in.

--David

---

From: David Recordon <[email-masked]>
Date: Tue, 23 Mar 2010 19:00:04 -0700

And I realize that this issue was created because WRAP describes a
different refresh token flow for each profile whereas this draft
combines them all together. I think it's important to realize that
implementors will want to write one refresh_token(identifier,
refresh_token, secret?) function and expect it to work for each flow.

The language I used today was that the client secret should be
included if the client has access to it.

---

From: Dick Hardt <[email-masked]>
Date: Tue, 23 Mar 2010 21:42:50 -0700

On 2010-03-23, at 12:05 PM, Chuck Mortimore wrote:

> No worries – I figured it would be easier to push for it’s inclusion if the work were minimal.    
> 
> We will definitely need to implement this style of profile, as will many others, so it’s essential it ends in some spec.   Personally I’d rather see a relatively thin spec that includes the critical profiles, rather than core + profile + bindings + etc like SAML.   However I’m open to any approach that get’s the profile included.
> 
> I’d be happy to be listed as an author, but it’s more important that whomever authored the original assertion profile get listed/credit.   Not sure if that was Dick or one of the other authors...perhaps they can chime in.

It was me, but David was not interested in getting my feedback let alone list me as an author prior to publication.

---

From: Dick Hardt <[email-masked]>
Date: Tue, 23 Mar 2010 21:44:59 -0700

> spec so that they all go together.

Why is that? Many people don't think signatures should be there, but they are.
What would you save, a page or two? If layed out properly, a reader can 

By keeping all profiles in one document, someone easily understands the different applications of the technology, and when a different use case comes up, they know it is available rather than having to look at a different document.

-- Dick

---

From: Dick Hardt <[email-masked]>
Date: Tue, 23 Mar 2010 21:52:27 -0700

> reasoning has been explained (error codes, SAML flow, etc).

If you wanted to discuss, you could have posted questions about WRAP. I have promptly answered any questions people had. There are numerous changes in the spec where you just did not like the answer I gave you in the past.

> prevent us from working together on making OAuth 2.0 rock. :)

Hard to work with you when you just drop a whole bunch of changes and don't discuss them or ask for explanations.
I've been actively participating on the IETF list and on the calls. Not sure why I need to be working somewhere for my expertise and opinion to count. This is the IETF after all, and I was the editor of WRAP, so if you were going to incorporate WRAP, then it would seem logical to have included me. And given I have seen you in person numerous times in the last few weeks, it is not like you forgot I existed. Yes, I am miffed.

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 24 Mar 2010 04:53:14 +0000

I don't think that Microsoft ever indicated that we need the SAML flows.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Recordon
Sent: Tuesday, March 23, 2010 10:48 AM
To: Torsten Lodderstedt; Chuck Mortimore; Mark Mcgloin
Cc: OAuth WG
Subject: Re: [OAUTH-WG] First draft of OAuth 2.0

Hey Chuck,
Thanks for rewriting the SAML flow into the style of my draft!  I really appreciate it.

I originally dropped the SAML flow because I hadn't seen support for it on the mailing list(s) the past two months.  I think that our default should be making the spec as short and simple as possible so removed a few things from WRAP in order to start conversations like this one.  It's now clear that Google, Microsoft, Salesforce, and IBM all need the SAML profile.  Chuck, I'll merge your wording in.  Want to be listed as an author?

We're also going to need to figure out which flows should be in the core spec versus which should be developed at the same time but in individual documents.

Thanks,
--David

On Tue, Mar 23, 2010 at 4:50 AM, Torsten Lodderstedt <[email-masked]> wrote:
>> Microsoft may have already shipped a minor variation on this ( 
>> wrap_SAML ) in Azure.
>>
>>
>> Mark McGloin

---

From: Dick Hardt <[email-masked]>
Date: Tue, 23 Mar 2010 22:21:10 -0700

That was one of the reasons why the refresh was repeated. Unfortunately I dropped the secret mistakenly when I ported over to RFC format. See my comments on draft-recordon-oauth2 for details.

---

From: Dick Hardt <[email-masked]>
Date: Tue, 23 Mar 2010 22:53:17 -0700

On 2010-03-23, at 9:52 PM, Dick Hardt wrote:

>> that went into WRAP haven't entirely been shared in public

Would you care to share the design decisions behind the choices you made in draft-recordon-oauth2 ?

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 24 Mar 2010 07:17:48 +0100

Hi Brian,

thanks for the clarification. Should the WG document this kind of 
security design decisions somewhere?

regards,
Torsten.
> On Tue, Mar 23, 2010 at 12:01 PM, David Recordon<[email-masked]>  wrote:
>    
>>> §3

---

From: Chuck Mortimore <[email-masked]>
Date: Wed, 24 Mar 2010 09:10:36 -0700

Agreed - I think that stems from my original note...sorry if it accidentally put words in your mouth.   I do believe that the original flow was authored by Dick when he was at Microsoft, and it's my understanding that you've actually similar pushed code; I've at least seen fairly detailed information indicating it can be used for integration of ADFS and Azure.

Is Microsoft interested in the flow?    I have lot's of mutual Microsoft customers that ask me to support the pattern; I really hope that you see the same and are getting behind this.

-cmort
________________________________________
From: Anthony Nadalin [[email-masked]]
Sent: Tuesday, March 23, 2010 9:53 PM
To: David Recordon; Torsten Lodderstedt; Chuck Mortimore; Mark Mcgloin
Cc: OAuth WG
Subject: RE: [OAUTH-WG] First draft of OAuth 2.0

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Recordon
Sent: Tuesday, March 23, 2010 10:48 AM
To: Torsten Lodderstedt; Chuck Mortimore; Mark Mcgloin
Cc: OAuth WG
Subject: Re: [OAUTH-WG] First draft of OAuth 2.0

Hey Chuck,

Thanks,
--David

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 24 Mar 2010 16:17:12 +0000

Yes the flows are interesting and we would be willing to work on them

-----Original Message-----
From: Chuck Mortimore [mailto:[email-masked]] 
Sent: Wednesday, March 24, 2010 9:11 AM
To: Anthony Nadalin; David Recordon; Torsten Lodderstedt; Mark Mcgloin
Cc: OAuth WG
Subject: RE: [OAUTH-WG] First draft of OAuth 2.0

-cmort

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Recordon
Sent: Tuesday, March 23, 2010 10:48 AM
To: Torsten Lodderstedt; Chuck Mortimore; Mark Mcgloin
Cc: OAuth WG
Subject: Re: [OAUTH-WG] First draft of OAuth 2.0

Hey Chuck,

Thanks,
--David

---

From: Hans Granqvist <[email-masked]>
Date: Wed, 24 Mar 2010 09:54:51 -0700

On Tue, Mar 23, 2010 at 9:44 PM, Dick Hardt <[email-masked]> wrote:
> ...

Yes. One doc rules since the spec + its delta changes are immediately obvious.

Multiple docs lead to unnecessary restating of facts, potential
redefinitions of terms, versioning and feature creep clashes, visual
hiding of complexity, scopes, etc. + you never know if you have the
whole set of docs. Think WS-*.

-Hans

---

From: Eve Maler <[email-masked]>
Date: Wed, 24 Mar 2010 11:07:39 -0700

> whole set of docs. Think WS-*.

On reflection, I agree (having contributed to the SAML proliferation-of-specs problem).  Any profiles that meet some threshold of interest -- say, more than one party asking for it -- and that are known prior to final publication would be good to include in one package.  There are editing, review, and approval overhead costs for every separate spec that this group itself publishes.  But it should also be clear how others can produce spinoff profile specs.  SAML offered guidelines for people writing third-party profiles and extensions, and a lighter-weight version of this might be nice to have on record if there's any complexity to it.

	Eve

Eve Maler
[email-masked]

---

From: Eve Maler <[email-masked]>
Date: Wed, 24 Mar 2010 11:08:13 -0700

I might be interested too; agree that it's not core to this group.

	Eve

On 23 Mar 2010, at 5:15 PM, Chuck Mortimore wrote:

> Outside the scope of what this WG should be tackling in the core spec IMO, but I’d be interested in working on a profile.   There is a lot of this use-case being done in an ad-hoc manner on my platform.
> 
> -cmort
> 
> 

Eve Maler
[email-masked]

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 25 Mar 2010 18:23:29 -0400

> the list?  I don't really remember it.

Not sure if this was discussed or not, but I think client state can be
really useful. Yes, client state can be added to the callback URL, but
this makes validating this URL against a registered callback URL more
difficult. This ties in with the fact that the validation of these
URLs is not specified.

It is easy to imagine an Authorization Server that does strict
validation of callback URLs, in which case the only way to pass client
state through is with this extra parameter.

Marius