Subject: [OAUTH-WG] Feedback on draft-recordon-oauth2-01

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

David

Although you stated you were taking WRAP and adding signatures, I found many other differences between the specs. I'm baffled at why you essentially started from scratch on this document rather than taking WRAP and adding the device profile and signatures. 

Per your previous email:

	My goal by removing some of the non-obvious things was to encourage
	the discussion which has now started

Here are numerous discussion points on your draft. I look forward to a response on each one.

-- Dick

1.2.1 The security and risk profile of a JavaScript or other RIA is different from a Rich App. The user can easily be fooled to run a RIA, but in general must be actively involved installed a Rich App. A RIA has an identity mechanism (URL it came from). Combining these makes it tougher to analyse the security issues and requires prohibits taking advantage of one context.

1.2.3 Google has been using captchas in their flows for some time. I'd like to hear from Google and others that have deployed captchas here that they do NOT want it as an option before it is removed.

1.2.4 I think this is a security consideration, not a specification MUST. Many use cases are fine moving cookies in the clear where the cookie.

1.2.5 All refresh token requests are not the same. I see that I mistakenly dropped a feature in draft-hardt-oauth-01. In 5.4.8 of WRAP 0.9.7.1 the refresh request also includes the client identifier and client secret. This enables a catastrophic loss of refresh tokens at a PR to be recovered by changing the client secret and not requiring the client to have to reacquire authorization from the user.

1.2.6 How is an AS supposed to mark an Access Token as no longer being valid? Are you implying that there is a Access Token revocation mechanism? I did not see where the spec discusses the invalidation of an Access Token. Did I miss it somewhere?

Other changes from WRAP that were not highlighted.

A) The User Delegation profiles were put in a separate section from the autonomous client flows to highlight to readers the difference in the flows. Your draft merges them which could be confusing. It was often confusing to readers of WRAP previously.

B) Change from using profile to flow. Personally I think flow is better. Would be interested to hear others thoughts.

C) Placement of Acquiring an Access Token prior to Accessing a Protected Resource. Most new readers will be Client or PR developers. What they care about is accessing a PR. Once they see that they need an Access Token to access a PR, they then understand they need to get an Access Token. They then can jump to the profile/flow that is relevant for them.

(D) The Parameter Considerations section was removed. We had found this section useful to collect common information about parameters.

1.3 Terminology

1.3 access token: why is this a now a unique identifier? the deployed usage of Access Tokens in WRAP is that this is a token, not an identifier. This was a significant feature in WRAP, that the Access Tokens are claims, not identifiers. This is also why the Access Token size could be larger. 

1.3 client: what do you mean by "OAuth-authenticated request"?
 
1.3 refresh token:. why does the refresh token need to be unique? can the AS hand the same one out to a client later on or does it need to track which ones it has handed out?

1.3 server: Why is server defined when we have protected resource? I don't understand the difference.

1.3.1 Why is this a subsection of Terminology? I find the use of the term server here very confusing. Is the PR a different machine? The Authorization Server? Why does the client discover them from the server?

1.3.1 255 character Access Token length recommendation. This was a joke right? There was a discussion of this on the list and no one was agreeing with Facebook reps on limiting the Access Token. Since it is a recommendation, people can go over, so what is the point? The real limit is what can be included in HTTP headers or in a query string, not the size of a MySQL record.

1.3.1 URL safe characters. What is the basis for this requirement? Many existing systems will likely have other non URL safe chars in their existing Access Tokens. You are now creating  Microsoft's deployed Simple Web Tokens that are used in WRAP are not URL safe.

1.3.1 Why is the Access Token length and character set in a section entitled Endpoints? Why did you drop Parameter Considerations? That section would have been the logical place to have included information such as this.

2 "five core flows" ... this implies any other flow is inferior. Why are they core? Per comment above, in WRAP we found it useful to separate the user delegation flows from the autonmous client flows.

2 "Common scenarios involve the resource owner delegating to a client to act on their behalf, adding another party (the resource owner) to the protocol."  Which protocol is the resource owner being added to?

"Unlike the others, Client Identifier and Secret flow (Client Identifier and Secret Flow) is intended for a client acting on behalf of itself and not a separate resource owner. For example, when a client is accessing non-private data or modifying data about itself."  This is a much narrower use case than what motivated the Client Account and Password Profile. draft-hardt-oauth-wrap-01 5.1 was motivated for autonomous clients calling an API. The data is likely private and not about itself.

2.1 In contrast to 1.3.1 where the endpoint is obtained from the server, now the client obtains it from the authorization server. Which is it?

2.1 there are a number of steps here. Would be useful to break into separate sections similar to draft-hardt-oauth-wrap-01 to guide discussion.

2.1 are there any checks the AS needs to do wrt. the initial request such as check the callback URL?

2.1 "The way in which the server handles the user authorization request (such as via cookies), including whether it uses a secure channel such as TLS/SSL is beyond the scope of this specification. However, the server MUST first verify the identity of the resource owner. If the resource owner approves the authorization request, the authorization server MUST generate a verification code and associate it with the client identifier and callback URI. "
Why MUST the AS generate a verification code? I would hope the AS would also do some checking on the parameters from the client such as matching the client identifier with the callback URL.

2.1 "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)."

What steps does the AS do to authorize the request? 

2.1 "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."

What is this sentence doing in this section? How is the AS to enforce these restrictions? Why is the client making requests to the authorization server?

2.1 "oauth_error_reason
Value must be one of "callback_url_mismatch" or "expired_verification_code" (case sensitive)."
What if it is a different error such as invalid client secret or client identifier? What if the oauth_mode is not supported?

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

    oauth_error_reason=expired_verification_code
Where did the WWW-Authenticate header suddenly come from? Where do these values of realm come from? This is an example, but I don't see where including this header was specified.

2.2 As mentioned above, the security considerations for a RIA and Rich App are not the same.

2.2 Once again, this is a long section and breaking it up into steps would make it easier to refer to a step.

Why does a Rich App now have to have a callback URL? How does the Rich App get the verification code? draft-hardt-oauth-wrap-01 captured a number of best practices for how a Rich App can get the verification code. 

2.3 oauth_verification_rate_limit: What is an AS supposed to do if a Client calls more often?

2.4 "This flow is used when the authorization server generally trusts the client to temporarily collect the end-user's username and password and it is impossible to use one of the other authorization flows." what determines "generally trust" from other trust situations?

2.4 "The authorization server MUST verify that the resource owner's credentials are accurate and MAY verify that the client is authorized to use this flow."
Why is verifying the client is authorized to use this flow a MAY rather than MUST? 

2.5 Why was this renamed to Client Identifier and Secret Flow? In draft-hardt-oauth-wrap-01 we specifically called it an Account Name and Password flow to avoid confusion with how client identifier and client secret are used in other parts of the protocol. As noted in the introduction above, this is a common use case. It seems that the terms secret and password are being used interchangeably, which is confusing.

3. See 1.2.5 for why it makes sense to have different refresh flows

3. Having a new parameter to get a secret looks like a hack. We have the oauth_mode parameter, make it another mode.

3. How is the AS supposed to know which PR the client is going to talk to? How does it know what signature methods are supported by the PR?

4.1.1 why does is the parameter name oauth_access_token rather than just access_token? It is in the context of an OAuth authentication.

4.1.1. "The protected resource MAY include further details about why the request was rejected in the response body or headers."  this sounds like a vague way of providing additional error information. Seems it would make sense to standardize best practices here.

4.2 Why does the client not sign requests to the AS if it has a client secret to sign requests with? Signing is much better than including a secret in a call.

4.2 Why refer to [draft‑hammer‑oauth‑10] (Hammer-Lahav, E., Ed., “The OAuth 1.0 Protocol,”  for the computing the signature string. Could you not copy that text over here? Are you anticipating there will be a separate spec for computing the signature?

4.2.1.1 Lots of TODOs here. I thought that OAuth 1.0A had this all figured out. Why are there TODOs???

Examples??? Where are the examples??? Do you not plan to have examples? Is it coming? WRAP had a couple of good examples IMHO. Not sure why you would not want to use those.