Subject: [OAUTH-WG] Draft -12 feedback deadline

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 26 Jan 2011 01:59:31 -0700

I plan to publish a quick fix to editorial issues raised in a -13 on Monday 1/31. If you have editorial feedback, please post it to the list by Friday 1/28 so that I can respond and incorporate if needed. This is not a deadline for normative issues, only editorial, but you can post feedback on both. I plan to request an official WG review of -13 to begin next week.

EHL

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 26 Jan 2011 12:09:24 -0800

- 4.1. Authorization Code. It is stated that authorization code is
suitable for clients that can hold a secret. Not necessarily true, it
is the best flow for native apps, for example.

- 4.1.2 Authorization Response. Minor typo in last sentence on page
16: "size of any value is issues" => "size of any value it issues"?

- 4.1.3. Access Token Request. redirect_uri is required, and must
match the one in the original request. But the one in the original
request is sort of optional (if registration provides one).

- 4.3. Resource Owner Password Credentials. The 3rd paragraph states
that the client MUST discard the credentials once it obtains an access
token. I think it SHOULD discard once it obtains a *refresh* token.

- 4.5. Extensions. For new grant types, we are not using a registry. Is that OK?

- 5.2. Error Response. The fist part of the first paragraph talks
about 401 and client credentials in the Authorization header. Since
this was dropped from core, this looks strange.

And there are the other two issues I raised in a separate thread.

Thanks,
Marius

On Wed, Jan 26, 2011 at 12:59 AM, Eran Hammer-Lahav <[email-masked]> wrote:
> I plan to publish a quick fix to editorial issues raised in a -13 on Monday
> 1/31. If you have editorial feedback, please post it to the list by Friday
> 1/28 so that I can respond and incorporate if needed. This is not a deadline
> for normative issues, only editorial, but you can post feedback on both. I
> plan to request an official WG review of -13 to begin next week.
>
>
>
> EHL
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Skylar Woodward <[email-masked]>
Date: Thu, 27 Jan 2011 11:36:54 +0100

> is the best flow for native apps, for example.

We concur with this as well. Our current implementation supports the auth flow for apps that can and cannot keep secrets (and our developer UI makes a clear distinction between these two in app registration). While most native apps should be able to perform a Implicit Grant flow, it helps to make permissible Auth Code flow as it allows a developer to reuse a flow with which he's already familiar. That is, Auth Code flow becomes the default flow with which developers will familiarize themselves with - the question is just whether or not an client credentials are required on token request.

I actually can't think of a case as Marius suggest where an Auth Code flow is better than Implicit for a native app, except for the point about reusing existing developer knowledge.  However, we do have the issue of the Out-of-Band flow (which is an important issue for us) which I'll address below.

-- 3.1.1, 4.1.2, and Out-of-Band flows

It is an important consideration for us that clients that cannot capture a redirect from the user-agent be able to use authentication flow. In the past this has been dubbed and Out-of-Band (OOB) flow. However, the reorganization of the document clearly marks out both Auth and Implicit as flows reserved for clients "capable of receiving incoming requests (via redirection) from the authorization server."  This language makes these incompatible with OOB clients.  In addition, other language inhibits this use:

- 3.1.1 definition of the redirection URI, requirement as an absolute URI, and other requirements of use
- restriction of 4.1 flow to clients that can keep secrets (eg, excludes OOB device clients)

Originally we had planned on the auth-code flow with a redirect_url of "oob" for such clients. Given the revised language, we'd likely avoid this now. Perhaps I missed considerations for OOB going forward.  If not, and short of revising the language in 4.1 to accommodate OOB, I assume the best path forward is an extension to section 4 as a consideration for clients that can't receive such incoming redirect requests.  Such a flow would be nearly identical to Auth Code but without the requirement of a redirect UI, open to clients without credentials, and a response_type of "oob_code."

-- Other feedback on flow-based reorganization.

The clear delineation of flows for clients with secrets and those without is the most spectacular improvement to the spec since v10, in my opinion. This includes Section 2 on Client Auth as well as the designation of the Auth Code flow for clients with credentials, and the restriction of the Implicit flow for those without. We consider this critical to a proper understanding of the protocol and how it should be used.

However, considering the Auth Code mechanic can be used without client auth as well, consider the following re-statement of client auth considerations for 4.1 and 4.2  (addition of terms "Verifiable" and "Forgeable" optional and open to editorial, of course)

1.3.5  Verifiable Client - a client that can keep secrets and can authenticate with the authorization server.  Examples include..
1.3.6  Forgeable Client - a client whose identity cannot be verified because the client is unable to keep authentication credentials secret.  Examples include...

4.1 Authorization Code

This flow is suitable for VERIFIABLE and FORGEABLE clients. As a redirection based protocol...

4.1.3
The authorization server MUST:
- Validate client credentials for VERIFIABLE clients.

4.2 Implicit Grant

This flow is suitable only for FORGEABLE clients.  As a redirection based protocol...

---

From: "Richer, Justin P." <[email-masked]>
Date: Thu, 27 Jan 2011 15:04:44 -0500

Overall, I much prefer the organization of this document, and I think it's going to make a lot more sense to implementers. My thoughts, per section:

1.2

"Tokens may be pure capabilities." To a non-security-engineer such as myself, this bit reads very oddly on its own. I understand that "capability" has another meaning in the security world, so can we either reference that definition or give a small prose example, like "capabilities, such as ...". 

1.3

Should these introductions link down to their implementation sections? Seems like a useful xref.

1.3.2, 4.2

I'm not sold on calling this "Implicit", though "user agent" and "direct" aren't much better. 

1.3.2

"round trip" should be "round trips"

1.3.4

Perhaps add something along the lines of "Client credentials are also useful inside of enterprise environments where there is a high degree of trust between applications, or for direct data exchange between systems with no explicit end users."

2.

"client identified" should be "client identifier"

Should we strengthen the first "SHOULD NOT" to a "MUST NOT", since this is about assumptions of security made by the AS? This is possibly bikeshedding as the AS could always still say "We know that the secret-storage security of some clients might be bad but that's OK." 

3.2 

Can we make the token endpoint MUST support POST and MAY support GET? I understand the arguments for favoring POST, but they don't always apply to all environments. (Brought this up a while ago, seems like it's not a breaking change to allow.)

4.2

While it doesn't use the full client credentials defined in section 2, it does still use the client identifier. The identifier is usually just one half of the credentialing pair. As the opening paragraph is worded now it's a bit confusing and makes it sounds like you don't need a client_id parameter at all (an assumption which is of course contradicted by 4.2.1).

5.2

"parameters are including" should be "parameters are included"

[side note: should I revise the XML encoding to have an explicit example for error responses? I would still like to make the XML encoding extension a WG item and eventual RFC.]

6.

I'd like to see a paragraph on redelegation practices, but I'm not sure it belongs in the core as it's really more of a way of *using* refresh tokens and scopes in a slightly different way than it is really a *new* thing. All the mechanisms are there to support it, a recipe just hasn't been written out for it. Is there desire for an extension doc for this?

8.2

Already talked about relaxing the MUST to SHOULD here under different cover, as this actually lines up better with text in other sections stating that the Auth and Token endpoints MAY have query-string parameters which MUST be preserved.

 -- Justin