Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt

From: [email-masked]
Date: Thu, 20 Jan 2011 16:45:01 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Open Authentication Protocol Working Group of the IETF.

	Title           : The OAuth 2.0 Authorization Protocol
	Author(s)       : E. Hammer-Lahav, et al.
	Filename        : draft-ietf-oauth-v2-12.txt
	Pages           : 46
	Date            : 2011-01-20

This specification describes the OAuth 2.0 authorization protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-12.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 20 Jan 2011 17:56:50 -0700

Draft -12 is finally out.

This is almost a complete rewrite of the entire document, with the primary goal of moving it back to a similar structure used in -05. I have been thinking about this for a few months and finally came up with a structure that combines the two approaches.

The draft includes some major cleanups, significantly simpler language, reduces repeated prose, and tried to keep prose to the introduction and normative language in the rest of the specification. I took out sections that broke the flow, and did my best to give this a linear narrative that is easy to follow.

The draft includes the following normative changes:

   o  Clarified 'token_type' as case insensitive.
   o  Authorization endpoint requires TLS when an access token is issued.
   o  Removed client assertion credentials, mandatory HTTP Basic authentication support for client credentials, WWW-Authenticate header, and the OAuth2 authentication scheme.
   o  Changed implicit grant (aka user-agent flow) error response from query to fragment.
   o  Removed the 'redirect_uri_mismatch' error code since in such a case, the authorization server must not send the error back to the client.
   o  Defined access token type registry.

I would like to spend the coming week receiving and applying feedback before requesting a WGLC for everything but the security considerations section (missing) 2/1.

EHL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of [email-masked]
> Sent: Thursday, January 20, 2011 4:45 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt
> 
> implementation to automatically retrieve the ASCII version of the Internet-
> Draft.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 20 Jan 2011 22:41:48 -0700

Forgot to mention that I don't have any outstanding comments in my queue so if your feedback was not incorporated into -12, and you feel strongly about it, bring it up again.

EHL

> Of Eran Hammer-Lahav
> Sent: Thursday, January 20, 2011 4:57 PM
> To: [email-masked]
> Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt
> 
> This is almost a complete rewrite of the entire document, with the primary
> goal of moving it back to a similar structure used in -05. I have been thinking
> about this for a few months and finally came up with a structure that
> combines the two approaches.
> 
> The draft includes some major cleanups, significantly simpler language,
> reduces repeated prose, and tried to keep prose to the introduction and
> normative language in the rest of the specification. I took out sections that
> broke the flow, and did my best to give this a linear narrative that is easy to
> follow.
> 
>    o  Removed client assertion credentials, mandatory HTTP Basic
> authentication support for client credentials, WWW-Authenticate header,
> and the OAuth2 authentication scheme.
>    o  Removed the 'redirect_uri_mismatch' error code since in such a case, the
> authorization server must not send the error back to the client.
> I would like to spend the coming week receiving and applying feedback
> before requesting a WGLC for everything but the security considerations
> section (missing) 2/1.
> 
> EHL
> 
> 
> 
> > Internet- Draft.
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Mike Jones <[email-masked]>
Date: Fri, 21 Jan 2011 18:38:06 +0000

Please (re-)add my comments into your queue that the client assertion credentials and WWW-Authenticate header should be retained.  Also, per Marius' note of January 20th, Google has plans to use the client assertion credentials as well.

You argue that interop is not hindered by removing features that could be defined as extensions.  And that since additional knowledge is required to use these features that is outside the scope of the specification, that there is no value in retaining them.

The problem with those lines of reasoning is that the same arguments could be applied to the whole specification.  People *could* implement OAuth flows with no OAuth specification at all.  So why not get rid of all of it?  Simply, that interop is enhanced by having common ways to do common things -- even if some additional knowledge is required to do them.

Please retain these features.

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav
Sent: Thursday, January 20, 2011 9:42 PM
To: [email-masked]
Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt

EHL

> This is almost a complete rewrite of the entire document, with the 
> primary goal of moving it back to a similar structure used in -05. I 
> have been thinking about this for a few months and finally came up 
> with a structure that combines the two approaches.
> 
> The draft includes some major cleanups, significantly simpler 
> language, reduces repeated prose, and tried to keep prose to the 
> introduction and normative language in the rest of the specification. 
> I took out sections that broke the flow, and did my best to give this 
> a linear narrative that is easy to follow.
> 
> authentication support for client credentials, WWW-Authenticate 
> header, and the OAuth2 authentication scheme.
>    o  Removed the 'redirect_uri_mismatch' error code since in such a 
> case, the authorization server must not send the error back to the client.
> before requesting a WGLC for everything but the security 
> considerations section (missing) 2/1.
> 
> EHL
> 
> 
> 
> > From: [email-masked] [mailto:[email-masked]] On 
> > Behalf Of [email-masked]

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 21 Jan 2011 12:11:29 -0700

Re: client assertion credentials

The actual  decision to move the section out and call for someone to edit a new document was made by the chair. I will not put it back unless instructed by the chair based on working group consensus and a revised language that addresses my concerns. And you are still ignoring all the issues I raised...

Re: WWW-Authenticate header

You have made no arguments to retain this header or scheme. As -12 clearly shows, it has no place in the document since at no point is it necessary to return an OAuth2 authentication challenge (and what does it even mean?). As currently defined, each token type uses its own authentication scheme which comes with its own WWW-Authenticate header. The bearer token specification should define its own challenge and as I commented earlier, should not use 'OAuth2' as its scheme because it is confusing and prejudicial. I will not put it back unless instructed by the chair based on working group consensus on a new proposed language that fits the new organization of -12.

EHL

> From: Mike Jones [mailto:[email-masked]]
> Sent: Friday, January 21, 2011 10:38 AM
> To: Eran Hammer-Lahav; [email-masked]
> Subject: RE: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt
> 
> Please (re-)add my comments into your queue that the client assertion
> credentials and WWW-Authenticate header should be retained.  Also, per
> Marius' note of January 20th, Google has plans to use the client assertion
> credentials as well.
> 
> You argue that interop is not hindered by removing features that could be
> defined as extensions.  And that since additional knowledge is required to
> use these features that is outside the scope of the specification, that there is
> no value in retaining them.
> 
> The problem with those lines of reasoning is that the same arguments could
> be applied to the whole specification.  People *could* implement OAuth
> flows with no OAuth specification at all.  So why not get rid of all of it?
> Simply, that interop is enhanced by having common ways to do common
> things -- even if some additional knowledge is required to do them.
> 
> Forgot to mention that I don't have any outstanding comments in my queue
> so if your feedback was not incorporated into -12, and you feel strongly
> about it, bring it up again.
> 
> EHL
>

---

From: Mike Jones <[email-masked]>
Date: Fri, 21 Jan 2011 22:17:15 +0000

I understand that despite me providing answers to the issues you raised, such as those below and those in previous exchanges, that it's your desire to portray things as me ignoring your issues, even though it's not true.  So be it.  I'll let others be the judge of that.

I will also add that you appear to have dismissed many of the issues I and others raised out of hand without seriously considering them, such as those about specification stability, compatibility, and providing a migration path forward for existing implementations both of OAuth 2.0 drafts and WRAP.  You may not like those issues, but they are substantive and pertinent to the acceptance of OAuth 2.0, or its lack of acceptance, in the marketplace.

				Sincerely,
				-- Mike

-----Original Message-----
From: Eran Hammer-Lahav [mailto:[email-masked]] 
Sent: Friday, January 21, 2011 11:11 AM
To: Mike Jones; [email-masked]
Subject: RE: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt

EHL

> Marius' note of January 20th, Google has plans to use the client 
> assertion credentials as well.
> 
> You argue that interop is not hindered by removing features that could 
> be defined as extensions.  And that since additional knowledge is 
> required to use these features that is outside the scope of the 
> specification, that there is no value in retaining them.
> 
> The problem with those lines of reasoning is that the same arguments 
> could be applied to the whole specification.  People *could* implement 
> OAuth flows with no OAuth specification at all.  So why not get rid of all of it?
> Forgot to mention that I don't have any outstanding comments in my 
> queue so if your feedback was not incorporated into -12, and you feel 
> strongly about it, bring it up again.
> 
> EHL
> 
> > Behalf Of Eran Hammer-Lahav
> > I took out sections that broke the flow, and did my best to give 
> > this a linear narrative that is easy to follow.
> >
> > I would like to spend the coming week receiving and applying 
> > feedback before requesting a WGLC for everything but the security

---

From: Anthony Nadalin <[email-masked]>
Date: Sat, 22 Jan 2011 01:19:34 +0000

We should then have a consensus call to remove items like this

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav
Sent: Friday, January 21, 2011 11:11 AM
To: Mike Jones; [email-masked]
Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt

EHL

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 25 Jan 2011 17:02:04 -0800

>From an older email, adapted to v12:

1. The token_type parameter is required in responses from the server.
If the server supports multiple formats, which one will be used? In
this case, would it make sense to allow the client to request a
specific format?

For example, if the authorization server supports both MAC and BEARER,
which one will the server issue?

2. Section 8.2. What about applications using legacy parameters? Does
not make much sense to register them, and they cannot be changed to
x_. Broken record: using a prefix for all registered parameters is
much cleaner (as opposed to requiring that all no-registered
parameters use a prefix).

For Google it is impossible to comply with this requirement.

Marius

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 26 Jan 2011 00:08:20 -0700

Thanks Marius.

> From: Marius Scurtescu [mailto:[email-masked]]
> Sent: Tuesday, January 25, 2011 5:02 PM
> To: Eran Hammer-Lahav
> Cc: [email-masked]
> If the server supports multiple formats, which one will be used? In this case,
> would it make sense to allow the client to request a specific format?
> 

It might in some cases, but I suspect most providers are going to decide which scheme provides the right level of security for them and just use that. If you are going to allow both MAC and BEARER, you are basically letting clients decide which level to operate at. Do you have a need or plan to support multiple token types?
 
> 2. Section 8.2. What about applications using legacy parameters? Does not
> make much sense to register them, and they cannot be changed to x_.
> Broken record: using a prefix for all registered parameters is much cleaner (as
> opposed to requiring that all no-registered parameters use a prefix).
> 

What legacy parameters do you have? Since OAuth 2.0 endpoints are brand new, this is probably about extension parameters in the authorization endpoint from OAuth 1.0 or AuthSub? I think the legacy parameters problem is pretty small, given the number of existing *token* and *authorization* endpoints with custom parameters (that were not pulled into the specification such as scope), but it would be good to know what we are dealing with.

Overall, this is a pretty minor issue. I assume you don't have any conflicts today with the v2 specification. Any conflicts you might have in the future (for which this x_ prefix is meant for) with new extensions is probably going to be minor. And Google can always join the work to make sure they pick a less conflicting name... this is where the registration process really helps to avoid clashes.

EHL

---

From: Justin Richer <[email-masked]>
Date: Wed, 26 Jan 2011 09:13:03 -0500

> x_. 

I *guarantee* that there will be many noncompliant implementations of
this, built on server frameworks with required parameters on all
endpoints. Not everyone is a Facebook or Google who can just define a
new top-level endpoint with clean parameter space. OAuth2 is going to be
integrated into *existing* systems that already have their allowable
extra parameters carved out, and these systems are not going to change
their parameters just to support OAuth. Once again, I'll say that if the
choice comes down to changing around existing parameters or not
supporting OAuth, most people are going to just not support OAuth.

> Broken record: using a prefix for all registered parameters is

And once again, a strong +1 to this, even though I know it's far too
late to make such a breaking change to the spec. I really think this was
a bad decision and is going to come back and bite us in the future.

 -- Justin

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 26 Jan 2011 09:05:23 -0700

It's been close to a year and no bite marks.

EHL

> From: Justin Richer [mailto:[email-masked]]
> Sent: Wednesday, January 26, 2011 6:13 AM
> To: Marius Scurtescu
> Cc: Eran Hammer-Lahav; [email-masked]
> I *guarantee* that there will be many noncompliant implementations of this,
> built on server frameworks with required parameters on all endpoints. Not
> everyone is a Facebook or Google who can just define a new top-level
> endpoint with clean parameter space. OAuth2 is going to be integrated into
> *existing* systems that already have their allowable extra parameters
> carved out, and these systems are not going to change their parameters just
> to support OAuth. Once again, I'll say that if the choice comes down to
> changing around existing parameters or not supporting OAuth, most people
> are going to just not support OAuth.
> 
> > Broken record: using a prefix for all registered parameters is much
> > cleaner (as opposed to requiring that all no-registered parameters use
> > a prefix).
> 
> And once again, a strong +1 to this, even though I know it's far too late to
> make such a breaking change to the spec. I really think this was a bad
> decision and is going to come back and bite us in the future.
> 
>  -- Justin

---

From: Justin Richer <[email-masked]>
Date: Wed, 26 Jan 2011 11:17:08 -0500

And also not much adoption into older (established) systems, yet. That's
where I see the trouble really happening. Most of the deployments we've
seen with OAuth2 have been with new systems or custom-built websites
where the devs had full control over API parameters.

 -- Justin

---

From: William Mills <[email-masked]>
Date: Wed, 26 Jan 2011 09:14:04 -0800

> a bad decision and is going to come back and bite us in the future.

Yep.

---

From: Skylar Woodward <[email-masked]>
Date: Wed, 26 Jan 2011 18:32:41 +0100

+1

More feedback on the token specs (and v12) is in my queue for tonight, but this has also been a concern of mine and this seems to be a more elegant protection against conflicts than adding a "version" parameter.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 26 Jan 2011 10:48:56 -0700

This is not aimed at anyone in particular.

Replying +1 is not justification for a major breaking change. This was raised in the past and consensus was that this is not a major concern. Over the past 10 months not a single actual issue was raised about conflicts in legacy platforms. If you have an *actual* issue with a platform, please provide the full details, including why known mechanisms such as Apache rewrite rules can't solve the it.

We're must be done discussing hypotheticals and theorizing about how this protocol will get adopted by those not represented here. That was fine a year ago, but at this point, whoever is in this group gets to make the decision based on our collective deployment experience. I honestly can't be bothered to care about deployment issues in some undeclared legacy platforms no one here is struggling with.

I've been doing this work continuously for over three and a half years and have learned that trying to optimize for the 'adoptions by others not present' is a complete waste of time. Suggesting that adoption will be significantly affected because of lack of parameter prefix or the inclusion of half-baked client assertion mechanism is just silly.
 
EHL

> Of Skylar Woodward
> Sent: Wednesday, January 26, 2011 9:33 AM
> To: William Mills
> Cc: [email-masked]
> More feedback on the token specs (and v12) is in my queue for tonight, but
> this has also been a concern of mine and this seems to be a more elegant
> protection against conflicts than adding a "version" parameter.
> 
> >>> cleaner (as opposed to requiring that all no-registered parameters
> >>> use a prefix).
> >>
> >> late to make such a breaking change to the spec. I really think this
> >> was a bad decision and is going to come back and bite us in the
> >> future.
> >>
> >> -- Justin
> >
> > Yep.

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 26 Jan 2011 13:32:10 -0800

> Replying +1 is not justification for a major breaking change. This was raised in the past and consensus was that this is not a major concern. Over the past 10 months not a single actual issue was r…

I just raised an actual issue.

Because OAuth 2 parameters are not prefixed, starting with v11 the
spec requires all other parameters to use the "x_" prefix. Google
cannot comply with that.

Dropping the x_ requirement is good enough IMO. If you are worried
about that, then you are probably afraid of an actual issue as well.

Marius

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 26 Jan 2011 13:42:47 -0800

> It might in some cases, but I suspect most providers are going to decide which scheme provides the right level of security for them and just use that. If you are going to allow both MAC and BEARER,…

For now we are planning to support only bearer, but I am sure some
form of signed tokens will follow sooner than later. At which point we
would have to support both.

In most cases I think it is up to the client to decide.

> What legacy parameters do you have? Since OAuth 2.0 endpoints are brand new, this is probably about extension parameters in the authorization endpoint from OAuth 1.0 or AuthSub? I think the legacy…

It is about parameters used by the authentication endpoints (aka login
page). The new OAuth 2 endpoints have no control over that.

> Overall, this is a pretty minor issue. I assume you don't have any conflicts today with the v2 specification. Any conflicts you might have in the future (for which this x_ prefix is meant for) with…

I don't think it makes much sense to register these existing
parameters, and they cannot be changed either. I guess that other
authorization servers will have similar issues.

Here are some examples from the top of my head:
- hd - domain hint, for hosted domain
- hl - language selecter
- authuser - multiple session user selector

Marius

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 26 Jan 2011 15:29:39 -0700

How about turn the MUST to a SHOULD for using the x_ prefix?

EHL

> Sent: Wednesday, January 26, 2011 1:32 PM
> To: Eran Hammer-Lahav
> Cc: [email-masked]
> > Replying +1 is not justification for a major breaking change. This was raised
> in the past and consensus was that this is not a major concern. Over the past
> 10 months not a single actual issue was raised about conflicts in legacy
> platforms. If you have an *actual* issue with a platform, please provide the
> full details, including why known mechanisms such as Apache rewrite rules
> can't solve the it.
> 
> Because OAuth 2 parameters are not prefixed, starting with v11 the spec
> requires all other parameters to use the "x_" prefix. Google cannot comply
> with that.
> 
> Dropping the x_ requirement is good enough IMO. If you are worried about
> that, then you are probably afraid of an actual issue as well.
> 
> 
> Marius

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 26 Jan 2011 14:44:53 -0800

> How about turn the MUST to a SHOULD for using the x_ prefix?

OK, let's go with that.

Thanks,
Marius

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 26 Jan 2011 15:57:39 -0700

> Sent: Wednesday, January 26, 2011 1:43 PM
> To: Eran Hammer-Lahav
> Cc: [email-masked]
 
> >> this case, would it make sense to allow the client to request a specific
> format?
> >>
> >> For example, if the authorization server supports both MAC and
> >> BEARER, which one will the server issue?
> >
> > It might in some cases, but I suspect most providers are going to decide
> which scheme provides the right level of security for them and just use that.
> If you are going to allow both MAC and BEARER, you are basically letting
> clients decide which level to operate at. Do you have a need or plan to
> support multiple token types?
> 
> For now we are planning to support only bearer, but I am sure some form of
> signed tokens will follow sooner than later. At which point we would have to
> support both.
> 

Interesting. Given that you are not planning on supporting this in the near future, I think we should wait until there is more deployment experience in allowing the client to negotiate the token type. But of course, you are welcome to submit a proposal for inclusion on the WG new charter.

EHL

---

From: William Mills <[email-masked]>
Date: Wed, 26 Jan 2011 15:17:17 -0800

Actually I was envisioning a situation where you have multiple possibly disparate endpoints that rely on authenticator like Google or Yahoo.  One company decides they want to allow federated login and accept SAML assertions, another accepts bearer, yet a 3rd IMAP server accepts both some form of signed auth and bearer.  I think discovery for a service should allow the service to specify the type(s) of auth accepted and the client can choose one that it supports and pass that on to the token server.  The resource server has to know what auth types are supported by the token server.  I would rather have this explicit in the discovery information and support multiple types in the same SASL mechanism than have to offer N mechanisms (or 2N if channel binding is in play).

> Sent: Wednesday, January 26, 2011 2:58 PM
> To: Marius Scurtescu
> Cc: [email-masked]
> specific
> form of
> Interesting. Given that you are not planning on supporting this in the
> near future, I think we should wait until there is more deployment
> experience in allowing the client to negotiate the token type. But of
> course, you are welcome to submit a proposal for inclusion on the WG
> new charter.
> 
> EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 26 Jan 2011 20:26:35 -0700

This is a good example of why this is currently out of scope. We have little to no implementation experience with such a setup.

EHL

> From: William Mills [mailto:[email-masked]]
> Sent: Wednesday, January 26, 2011 3:17 PM
> To: Eran Hammer-Lahav; Marius Scurtescu
> Cc: [email-masked]
> Actually I was envisioning a situation where you have multiple possibly
> disparate endpoints that rely on authenticator like Google or Yahoo.  One
> company decides they want to allow federated login and accept SAML
> assertions, another accepts bearer, yet a 3rd IMAP server accepts both some
> form of signed auth and bearer.  I think discovery for a service should allow
> the service to specify the type(s) of auth accepted and the client can choose
> one that it supports and pass that on to the token server.  The resource
> server has to know what auth types are supported by the token server.  I
> would rather have this explicit in the discovery information and support
> multiple types in the same SASL mechanism than have to offer N
> mechanisms (or 2N if channel binding is in play).
>

---

From: William Mills <[email-masked]>
Date: Wed, 26 Jan 2011 22:39:55 -0800

Well, I guess I better get going with the SASL thing and get a working implementation done based on -12 and the bearer token spec.

> Sent: Wednesday, January 26, 2011 7:27 PM
> To: William Mills; Marius Scurtescu
> Cc: [email-masked]
> This is a good example of why this is currently out of scope. We have
> little to no implementation experience with such a setup.
> 
> EHL
> 
> > > > >> If the server supports multiple formats, which one will be
> used?
> > > In
> > > > > It might in some cases, but I suspect most providers are going
> to
> > > decide
> > > > which scheme provides the right level of security for them and
> just
> > > use that.
> > > > clients decide which level to operate at. Do you have a need or
> plan
> > > to
> > > > signed tokens will follow sooner than later. At which point we
> would
> > > have to
> > > > support both.
> > > >

---

From: "Richer, Justin P." <[email-masked]>
Date: Thu, 27 Jan 2011 08:40:14 -0500

In an ideal world, everything that lives alongside the official oauth parameters is known to oauth, but we don't live in an ideal world and the spec needs to be able to cope with that. 

I can live with the relaxation here as well -- it's a reasonable compromise, though not the ideal. I'm also assuming that the relaxation would apply to the registry requirement as well? 

 -- Justin
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Marius Scurtescu [[email-masked]]
Sent: Wednesday, January 26, 2011 5:44 PM
To: Eran Hammer-Lahav
Cc: [email-masked]
Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt

OK, let's go with that.

Thanks,
Marius