Subject: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23

From: Marius Scurtescu <[email-masked]>
Date: Wed, 14 Mar 2012 09:53:23 -0700

Hi,

Nat Sakimura started a thread on the OpenID Connect list about a
breaking change introduced by rev 2.3

The paragraph in question is in section 2.1:

"A client application consisting of multiple components, each with its
own client type (e.g. a distributed client with both a confidential
server-based component and a public browser-based component), MUST
register each component separately as a different client to ensure
proper handling by the authorization server.  The authorization
server MAY provider tools to manage such complex clients through a
single administration interface."

http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-oauth-v2-23.txt

You can see the thread here:
http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120312/001672.html

This paragraph basically prevents response_type=code+token which is
already implemented by many providers and also relied on by OpenID
Connect.

The intent, I think, was to prevent clients from embedding the client
secret meant for a confidential client into a public client.
JavaScript based clients using the token flow do not need the client
secret, so this concern does not apply.

Thoughts?

Thanks,
Marius

---

From: Eran Hammer <[email-masked]>
Date: Wed, 14 Mar 2012 10:08:32 -0700

This was already raised and addressed on this list last week.

When someone defines and registers code+token, that specification must define how such a client is registered in light of the text below. This might mean defining a new client type, choosing the confidential client type with other normative text limiting the use of the secret in the public component, etc.

IOW, this section doesn't break anything because there is nothing else defined to break. There is no way to avoid explicitly defining these requirements for a code+token response type, or any other new response type for that matter. The text below is required to ensure that the authorization server can properly enforce the rest of the normative security language in the specification.

EH

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Marius Scurtescu
> Sent: Wednesday, March 14, 2012 9:53 AM
> To: OAuth WG
> Cc: Breno de Medeiros
> Subject: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
> 
> Hi,
> 
> Nat Sakimura started a thread on the OpenID Connect list about a breaking
> change introduced by rev 2.3
> 
> "A client application consisting of multiple components, each with its own
> client type (e.g. a distributed client with both a confidential server-based
> component and a public browser-based component), MUST register each
> component separately as a different client to ensure proper handling by the
> authorization server.  The authorization server MAY provider tools to manage
> such complex clients through a single administration interface."
> 
> The intent, I think, was to prevent clients from embedding the client secret
> meant for a confidential client into a public client.
> JavaScript based clients using the token flow do not need the client secret, so
> this concern does not apply.
> 
> Thoughts?
> 
> Thanks,
> Marius
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Breno de Medeiros <[email-masked]>
Date: Wed, 14 Mar 2012 10:16:25 -0700

Can you explain to me why response_type is necessary at all after this change.

If a javascript client (candidate for token usage) and the web server
component (candidate for code usage) cannot share registration (since
they are different components with different security contexts of the
same application) then there is no need to specify response_type. The
server can infer the response type from the client and its security
context.

My objection has nothing to do with code+token flow. I think the
change makes response_types irrelevant and is essentially a new
protocol.

As far as I understand it, the introduction of different code and
token flows was precisely to allow different security-context
components of the same client to securely operate under the same
registration. I think if we change this we need to specify a lot more
behavior, such as how a client can request authorization on behalf of
several components simultaneously.

-- 
--Breno

---

From: Eran Hammer <[email-masked]>
Date: Wed, 14 Mar 2012 11:09:20 -0700

If the server locks a client type to a particular grant type (or response type) then this is true, you don't need to specify the response type in the request. But this is based on a very limited set of potential response types. I can envision a code response type with different response syntax but same security properties, and same goes for token.

In the past, a cookie response type was proposed to use the cookie headers in the server response instead of returning a token. The security properties of such a flow are very similar to those of token (from OAuth's perspective). This means a public client would be able to request either token or cookie response type.

Also as noted, servers are allowed to provide different registration options to clients, as long as the client identifies each discrete component. There is no requirement or even suggestion that the server issues different client identifiers to such complex clients. I think this is another point missed in your reading of the text.

Hope this clarifies it.

EH

> From: Breno de Medeiros [mailto:[email-masked]]
> Sent: Wednesday, March 14, 2012 10:16 AM
> To: Eran Hammer
> Cc: Marius Scurtescu; OAuth WG
> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
> 
> component (candidate for code usage) cannot share registration (since they
> are different components with different security contexts of the same
> application) then there is no need to specify response_type. The server can
> infer the response type from the client and its security context.
> 
> My objection has nothing to do with code+token flow. I think the change
> makes response_types irrelevant and is essentially a new protocol.
> 
> As far as I understand it, the introduction of different code and token flows
> was precisely to allow different security-context components of the same
> client to securely operate under the same registration. I think if we change
> this we need to specify a lot more behavior, such as how a client can request
> authorization on behalf of several components simultaneously.
> 
> > When someone defines and registers code+token, that specification must
> define how such a client is registered in light of the text below. This might
> mean defining a new client type, choosing the confidential client type with
> other normative text limiting the use of the secret in the public component,
> etc.
> >
> > IOW, this section doesn't break anything because there is nothing else
> defined to break. There is no way to avoid explicitly defining these
> requirements for a code+token response type, or any other new response
> type for that matter. The text below is required to ensure that the
> authorization server can properly enforce the rest of the normative security
> language in the specification.
> >
> > EH
> >
> >
> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of Marius Scurtescu
> >> "A client application consisting of multiple components, each with
> >> its own client type (e.g. a distributed client with both a
> >> confidential server-based component and a public browser-based
> >> component), MUST register each component separately as a different
> >> client to ensure proper handling by the authorization server.  The
> >> authorization server MAY provider tools to manage such complex clients
> through a single administration interface."
> >>
> >> http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-oauth
> >> -v2-
> >> 23.txt
> >>

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 14 Mar 2012 11:23:50 -0700

Before v23 a web server client could use either response_type=code or
response_type=token, with the same client id. No security issues and
this was supported for quite a while.

With this latest change, if I am reading it correctly, this is not
possible anymore. The client has to use two different client ids. It
is very late in the game to introduce changes like this, unless there
is an extremely good reason.

Marius

---

From: Eran Hammer <[email-masked]>
Date: Wed, 14 Mar 2012 11:35:15 -0700

You are not reading it correctly.

This is a *registration* requirement, meaning, the client has to inform the server of the different components. If the server doesn't care, it can issue one client identifier capable of both.

This protocol assume the authorization server asked the client for its type and based on that made decisions about the credentials issued and the security properties of the client. It is also triggers a whole list of normative language handling the different client types throughout the specification.

EH

> From: Marius Scurtescu [mailto:[email-masked]]
> Sent: Wednesday, March 14, 2012 11:24 AM
> To: Eran Hammer
> Cc: Breno de Medeiros; OAuth WG
> response_type=token, with the same client id. No security issues and this
> was supported for quite a while.
> 
> With this latest change, if I am reading it correctly, this is not possible
> anymore. The client has to use two different client ids. It is very late in the
> game to introduce changes like this, unless there is an extremely good
> reason.
> 
> Marius
> 
> 
> 
> > If the server locks a client type to a particular grant type (or response type)
> then this is true, you don't need to specify the response type in the request.
> But this is based on a very limited set of potential response types. I can
> envision a code response type with different response syntax but same
> security properties, and same goes for token.
> >
> > In the past, a cookie response type was proposed to use the cookie
> headers in the server response instead of returning a token. The security
> properties of such a flow are very similar to those of token (from OAuth's
> perspective). This means a public client would be able to request either
> token or cookie response type.
> >
> > Also as noted, servers are allowed to provide different registration options
> to clients, as long as the client identifies each discrete component. There is
> no requirement or even suggestion that the server issues different client
> identifiers to such complex clients. I think this is another point missed in your
> reading of the text.
> >
> > Hope this clarifies it.
> >
> > EH
> >
> >> same
> >> application) then there is no need to specify response_type. The
> >> server can infer the response type from the client and its security context.
> >>
> >> define how such a client is registered in light of the text below.
> >> This might mean defining a new client type, choosing the confidential
> >> client type with other normative text limiting the use of the secret
> >> in the public component, etc.
> >> >
> >> requirements for a code+token response type, or any other new
> >> response type for that matter. The text below is required to ensure
> >> that the authorization server can properly enforce the rest of the
> >> normative security language in the specification.
> >> >
> >> > EH
> >> >
> >> >
> >> >> This paragraph basically prevents response_type=code+token which
> >> >> is already implemented by many providers and also relied on by
> >> >> OpenID Connect.
> >> >>
> >> >> The intent, I think, was to prevent clients from embedding the
> >> >> client secret meant for a confidential client into a public client.
> >> >> JavaScript based clients using the token flow do not need the
> >> >> client secret, so this concern does not apply.
> >> >>
> >> >> Thoughts?
> >> >>
> >> >> Thanks,
> >> >> Marius

---

From: Mike Jones <[email-masked]>
Date: Wed, 14 Mar 2012 18:42:03 +0000

All of Marius, Breno, Nat, myself, and several others on the OpenID AB list have read it this way.  I believe that either this change needs to be removed (my preference!) or a sentence needs to be explicitly added that states that "The same client_id MAY be used with both the code and token response types"  to explicitly rule out this apparently common misinterpretation of the new text.

Otherwise, I agree that it will continue to be perceived by most people as a breaking change.

				-- Mike

P.S.  When you make this change, you should also correct the typo in this sentence: "The authorization server MAY provider tools to manage such complex clients through a single administration interface" by changing "provider" to "provide".

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer
Sent: Wednesday, March 14, 2012 11:35 AM
To: Marius Scurtescu
Cc: Breno de Medeiros; OAuth WG
Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23

EH

> But this is based on a very limited set of potential response types. I 
> can envision a code response type with different response syntax but 
> same security properties, and same goes for token.
> >
> headers in the server response instead of returning a token. The 
> security properties of such a flow are very similar to those of token 
> (from OAuth's perspective). This means a public client would be able 
> to request either token or cookie response type.
> >
> to clients, as long as the client identifies each discrete component. 
> There is no requirement or even suggestion that the server issues 
> different client identifiers to such complex clients. I think this is 
> another point missed in your reading of the text.
> >
> > Hope this clarifies it.
> >
> > EH
> >
> >> If a javascript client (candidate for token usage) and the web 
> >> server component (candidate for code usage) cannot share 
> >> registration (since they are different components with different 
> >> security contexts of the same
> >> registration. I think if we change this we need to specify a lot 
> >> more behavior, such as how a client can request authorization on 
> >> behalf of
> >> This might mean defining a new client type, choosing the 
> >> confidential client type with other normative text limiting the use 
> >> of the secret in the public component, etc.
> >> >
> >> defined to break. There is no way to avoid explicitly defining 
> >> these requirements for a code+token response type, or any other new 
> >> >> "A client application consisting of multiple components, each 
> >> >> with its own client type (e.g. a distributed client with both a 
> >> >> component), MUST register each component separately as a 
> >> >> different client to ensure proper handling by the authorization 
> >> >> server.  The authorization server MAY provider tools to manage 
> >> >> such complex clients
> >> >> http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-
> >> >> oa
> >> >> uth
> >> >> -v2-
> >> >> 23.txt
> >> >>

---

From: Eran Hammer <[email-masked]>
Date: Wed, 14 Mar 2012 12:23:16 -0700

Let's take a step back for a second.

Previous versions of this document stated that during the registration process the client developer specifies the client type as described in 2.1. This has been specified under "registration requirements" since -17 published July 8th 2011. The only two types provided were (and still are) public and confidential.

While there was no MUST or SHALL directive, the text was pretty clear about the need for each client registration to be tied to a single client type.

-23 was an attempt to clarify this, by making it explicit that hybrid clients are not addressed by the specification, and have to be dealt with as two separate clients.

The specification breaks if a client has more than one type. The authorization server cannot enforce some of the security requirements if the client type is unknown. This is all based on how the specification is written and how the security consideration section is structured.

The real issue raised here is how to handle hybrid clients which are beyond the scope of this specification.

Here is an alternative text:

   A client application consisting of multiple components, each with its
   own client type (e.g. a distributed client with both a confidential
   server-based component and a public browser-based component), MUST
   register each component separately as a different client to ensure
   proper handling by the authorization server, unless the authorization
   server provides other registration options to specify such complex clients.

It's basically saying that unless the authorization server provides a special option other than 'public' and 'confidential', clients MUST register such applications separately for each component. It leaves the decision of how to deal with such clients completely up to the authorization server during the registration process.

I think we should also add a SHALL in section 2: "When registering a client, the client developer SHALL:", which is implicit already.

Another, less desirable alternative is to remove this section and add:

   The authorization server MAY provide the client with other client types
   options during the registration process. Such client types are beyond the
   scope of this specification. Such additional client types will require a
   different set of security considerations not provided by this specification.

My intention was never to introduce a (breaking) change here, just to clarify what was already the prescribed process. I'm open to other suggestions as long as they account for the deep dependency this protocol has on client type identification.

EH

> From: Mike Jones [mailto:[email-masked]]
> Sent: Wednesday, March 14, 2012 11:42 AM
> To: Eran Hammer; Marius Scurtescu
> Subject: RE: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
> 
> All of Marius, Breno, Nat, myself, and several others on the OpenID AB list
> have read it this way.  I believe that either this change needs to be removed
> (my preference!) or a sentence needs to be explicitly added that states that
> "The same client_id MAY be used with both the code and token response
> types"  to explicitly rule out this apparently common misinterpretation of the
> new text.
> 
> P.S.  When you make this change, you should also correct the typo in this
> sentence: "The authorization server MAY provider tools to manage such
> complex clients through a single administration interface" by changing
> "provider" to "provide".
> 
> Of Eran Hammer
> This is a *registration* requirement, meaning, the client has to inform the
> server of the different components. If the server doesn't care, it can issue
> one client identifier capable of both.
> 
> This protocol assume the authorization server asked the client for its type
> and based on that made decisions about the credentials issued and the
> security properties of the client. It is also triggers a whole list of normative
> language handling the different client types throughout the specification.
> 
> EH
>

---

From: "Richer, Justin P." <[email-masked]>
Date: Wed, 14 Mar 2012 19:47:38 +0000

Even though I also don't like the addition of normative text in such a late revision, I'm with Eran in that I don't think this actually introduces a breaking change, nor did I read it as such when it went through. It's talking about public vs. confidential clients and keeping them separate, and it's really got nothing to do with the response type. After all, you can have a public client use the code flow (like a native app) just fine. But though if it's clear to me, it's definitely to the spec's benefit to make sure that the language is clear, and as Mike points out if a decent subset of familiar developers misread it the same way, then we should fix that.

I think that perhaps the use of normative language here was the major confusing point -- it made something explicitly normative that was implicitly recommended before. If that's the case, would removal of the normative MUST (change to "must" or "really should") in the client type text help the situation?

Barring the relaxation of normative language here, Eran's first text below clarifies that this is in response to the public/confidential client type and *NOT* the response_type, and does so better than Mike's suggested text which I believe continues to conflate the two. 

 -- Justin

---

From: Breno de Medeiros <[email-masked]>
Date: Wed, 14 Mar 2012 13:13:18 -0700

> While there was no MUST or SHALL directive, the text was pretty clear about the need for each client registration to be tied to a single client type.

I disagree with this. The spec supplies two response_types explicitly
to deal with a single registration (single client_id) that can operate
in different security contexts, and provides means for this to
securely do so. The security considerations of the spec was previously
written in a consistent form.

This language is not consistent with that.

As an specific example, our server implementation is compliant with
the previous approach but not with the new one. Moreover, the current
writing of this section leaves unspecified how servers can be made
compliant if they support both token and code flows (if they only
support one flow type, then clearly this is a non-issue).

I am sorry, but with this language this is a different spec with
different compliance profiles and without supplying enough guidance
for creating interoperable server implementations for common
deployment models.

-- 
--Breno

---

From: Barry Leiba <[email-masked]>
Date: Wed, 14 Mar 2012 16:19:38 -0400

> for creating interoperable server implementations for common

As I read this thread, I see two things come out clearly:

1. Eran didn't intend to make the change that some read into this, and

2. enough people interpret this as a change that Eran didn't intend
that it's worth fixing.

Everyone agrees on how it should be -- right?  So let's not worry
about whether the text is or isn't confusing, and instead focus on a
small change to the text that will keep the meaning that's intended
and that takes the confusion away from those who think something
drastic has changed.  That should be easy to do, and quick and
non-controversial to wrap up.

Barry

---

From: Eran Hammer <[email-masked]>
Date: Wed, 14 Mar 2012 13:29:00 -0700

I've proposed two alternative languages and open to more. It would be great if people could just reply stating which they like best.

EH

> Of Barry Leiba
> Sent: Wednesday, March 14, 2012 1:20 PM
> To: OAuth WG
> 2. enough people interpret this as a change that Eran didn't intend that it's
> worth fixing.
> 
> Everyone agrees on how it should be -- right?  So let's not worry about
> whether the text is or isn't confusing, and instead focus on a small change to
> the text that will keep the meaning that's intended and that takes the
> confusion away from those who think something drastic has changed.  That
> should be easy to do, and quick and non-controversial to wrap up.
> 
> Barry

---

From: Barry Leiba <[email-masked]>
Date: Wed, 14 Mar 2012 16:46:21 -0400

Off list.

> It would be great if people could just reply stating which they like best.

כן

Sometimes, one just has to whack people over the head.

b

---

From: Barry Leiba <[email-masked]>
Date: Wed, 14 Mar 2012 16:46:49 -0400

> Off list.

Or not so much off list.  He-he.

b

---

From: Nat Sakimura <[email-masked]>
Date: Thu, 15 Mar 2012 18:03:30 +0900

So, Eran's first proposal:

  server provides other registration options to specify such complex
clients.

kind of meets my concern. There seems to be another issue around the
usefulness of return_type in such case raised by Breno, and if I understand
it correctly, Eran's answer was that these separate components may have the
same client_id so that return_type is a valid parameter to be sent at the
request.

So, to clarify these, perhaps changing the above text slightly to the
following solves the problem?

  A client application consisting of multiple components, each with its
  own client type (e.g. a distributed client with both a confidential
  server-based component and a public browser-based component), MUST
  register each component separately as a different client to ensure
  proper handling by the authorization server, unless the authorization
  server provides other registration options to specify such complex
clients.
  Each component MAY have the same client_id, in which case the server
  judges the client type and the associated security context  based on
  the response_type parameter in the request.

Would it solve your problem, Breno?

Best,

=nat

---

From: John Bradley <[email-masked]>
Date: Thu, 15 Mar 2012 06:38:42 -0400

That seems to cover it.

My problem is that client registration has been treated largely as being out of scope other than some general principals.  We are now adding normative text, but still not specifying mechanisms.

Nat's text allows existing practice with complex clients like Facebook with 'token signed_request'  response_type.   

What exact mechanism one uses to register a confidential vs complex client is still out of scope and a bit of handwaving with a MUST.

John B.
On 2012-03-15, at 5:03 AM, Nat Sakimura wrote:

> kind of meets my concern. There seems to be another issue around the usefulness of return_type in such case raised by Breno, and if I understand it correctly, Eran's answer was that these separate components may have the same client_id so that return_type is a valid parameter to be sent at the request. 
> 
> So, to clarify these, perhaps changing the above text slightly to the following solves the problem? 
>

---

From: Eran Hammer <[email-masked]>
Date: Thu, 15 Mar 2012 07:45:20 -0700

This add-on is unnecessary. It already says the authorization server can handle it any way it wants. The fact that other registration options are possible clearly covers the client identifier reuse case. As for the response type, that's not an issue but more of an optimization for an edge case raised.

EH

From: [email-masked] [mailto:[email-masked]] On Behalf Of Nat Sakimura
Sent: Thursday, March 15, 2012 2:04 AM
To: Breno de Medeiros; OAuth WG
Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23

Best,

=nat

---

From: Breno de Medeiros <[email-masked]>
Date: Thu, 15 Mar 2012 09:56:13 -0700

On Thu, Mar 15, 2012 at 07:45, Eran Hammer <[email-masked]> wrote:

> This add-on is unnecessary. It already says the authorization server can
> handle it any way it wants. The fact that other registration options are
> possible clearly covers the client identifier reuse case. As for the
> response type, that’s not an issue but more of an optimization for an edge
> case raised.
>

It still feels like a horse by committee to me. "unless the
authorization server
provides other registration options to specify such complex clients." seems
a very round about way to say that the core spec already provides for such
arrangements in the most common scenario. It is a bit of a stretch to say
that the server provides "other registration options" by simply following
strategy already laid out in the spec.

In particular, I feel that this wording will be harmful to register
extended behavior, e.g., alternative response_types by leading to fruitless
conversations about spec compliance in the absence of real security risks.

I do not believe the current text is the best representation of the spirit
in which the spec was written (in particular the effort to specify two
flows in detail to deal with precisely this issue) and possibly lead to
harmful future interpretation.

> ****
>
> ** **
>
> EH****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Nat Sakimura
> *Sent:* Thursday, March 15, 2012 2:04 AM
> *To:* Breno de Medeiros; OAuth WG
>
> *Subject:* Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23****
>
> ** **
>
> ** **
>
> So, Eran's first proposal: ****
>
> ** **
>
>   register each component separately as a different client to ensure****
>
> clients. ****
> ** **
> request. ****
> ** **
> following solves the problem? ****
>
> ** **
>
>   register each component separately as a different client to ensure****
>
> clients.  ****
>   Each component MAY have the same client_id, in which case the server ***
> *
>
>   the response_type parameter in the request. ****
>
> ** **
>
> Would it solve your problem, Breno? ****
>
> ** **
>
> Best, ****
>
> ** **
>
> =nat****
>
> ** **
>

-- 
--Breno

---

From: Mike Jones <[email-masked]>
Date: Thu, 15 Mar 2012 17:07:20 +0000

I disagree.  The add-on is necessary exactly because several OAuth experts (Breno, Marius, Nat, John, Nov, and I) all read the new text as a breaking change that prohibited exactly what the new text explicitly allows.  Given you agree that it doesn't change the meaning, there's no harm in adding the text below, and plenty of good for the clarification it provides.

I agree with Nat.  Please add:
  Each component MAY have the same client_id, in which case the server
  judges the client type and the associated security context  based on
  the response_type parameter in the request.

Or if you dislike that, just add:
  Each component MAY have the same client_id.

                                                            Thanks,
                                                            -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer
Sent: Thursday, March 15, 2012 7:45 AM
To: Nat Sakimura; Breno de Medeiros; OAuth WG
Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23

EH

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Nat Sakimura
Sent: Thursday, March 15, 2012 2:04 AM
To: Breno de Medeiros; OAuth WG
Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23

Best,

=nat

---

From: Eran Hammer <[email-masked]>
Date: Thu, 15 Mar 2012 11:32:38 -0700

Here are the facts:

 1.  The authorization server must know the client type in order to enforce many of the requirements in the specification.
 2.  The requirement to provide a client type is not decorated with a MUST or SHALL but that is implied.
 3.  The specification only defines two client types: public and confidential. There is no client type defined for a hybrid client.
 4.  The specification needs to address the very common use case of clients with both public and private components.

I don't want to discuss in the specification how client identifiers are provisioned, nor do I want to discuss the potential binding of response types to client types. But we do need to provide some guidance to clients and authorization servers what to do with clients that do not fit the current type definitions.

It is far too late for us to define a new client type, along with all the security considerations that such type imply. Our entire security consideration section and protocol design are based on have a well defined client type.

Requiring separate registration for each component is the most straight-forward solution. Allowing the authorization server to offer alternatives is the backdoor to enable extensibility.

Within these constraints, I am open to other prose or creative solutions. But the add-ons proposed are all ugly hacks. They clarify specific questions raised which I do not believe represent the core confusion here which is what is the right way to handle hybrid clients.

The best way to move forward is to take a minute and ask the group to share how they handle such cases or how they think they should be handled. Based on that we can come up with a clear solution.

EH

From: Breno de Medeiros <[email-masked]<mailto:[email-masked]>>
Date: Thu, 15 Mar 2012 09:56:13 -0700
To: Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>>
Cc: Nat Sakimura <[email-masked]<mailto:[email-masked]>>, OAuth WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23

On Thu, Mar 15, 2012 at 07:45, Eran Hammer <[email-masked]<mailto:[email-masked]>> wrote:
This add-on is unnecessary. It already says the authorization server can handle it any way it wants. The fact that other registration options are possible clearly covers the client identifier reuse case. As for the response type, that’s not an issue but more of an optimization for an edge case raised.

It still feels like a horse by committee to me. "unless the authorization server provides other registration options to specify such complex clients." seems a very round about way to say that the core spec already provides for such arrangements in the most common scenario. It is a bit of a stretch to say that the server provides "other registration options" by simply following strategy already laid out in the spec.

In particular, I feel that this wording will be harmful to register extended behavior, e.g., alternative response_types by leading to fruitless conversations about spec compliance in the absence of real security risks.

I do not believe the current text is the best representation of the spirit in which the spec was written (in particular the effort to specify two flows in detail to deal with precisely this issue) and possibly lead to harmful future interpretation.

EH

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Nat Sakimura
Sent: Thursday, March 15, 2012 2:04 AM
To: Breno de Medeiros; OAuth WG

Best,

=nat

--
--Breno

---

From: Breno de Medeiros <[email-masked]>
Date: Thu, 15 Mar 2012 11:54:05 -0700

My proposal is to remove any reference to registration (which is a red
herring and has raised all the problems we refer here) and refer to
client authentication instead.

Proposal:

"Clients may be implemented as a distributed set of components that
run in different security contexts. For instance, a single client may
include a webserver component and a script component in a browser. It
is not appropriate for the different components to utilize the same
client authentication mechanisms, since client authentication
credentials that are held securely in one context cannot be deployed
securely in another.

Servers MUST mitigate security threats from client components that
cannot hold client credentials as securely by distinguishing them from
client components that can. Example of suitable measures are:

- Requiring separate registration of components such as web server and
a mobile application.
- Restricting the time validity of tokens issued to clients that hold
no authentication credentials, such as browser script-based
components."

Please don't truncate explanations in the interest of space if the
resulting text is confusing and possibly misleading. Better to say
nothing instead.

On Thu, Mar 15, 2012 at 11:32, Eran Hammer <[email-masked]> wrote:
> Here are the facts:
>
> The authorization server must know the client type in order to enforce many
> of the requirements in the specification.
> The requirement to provide a client type is not decorated with a MUST or
> SHALL but that is implied.
> The specification only defines two client types: public and confidential.
> There is no client type defined for a hybrid client.
> The specification needs to address the very common use case of clients with
> both public and private components.
>
> I don't want to discuss in the specification how client identifiers are
> provisioned, nor do I want to discuss the potential binding of response
> types to client types. But we do need to provide some guidance to clients
> and authorization servers what to do with clients that do not fit the
> current type definitions.
>
> It is far too late for us to define a new client type, along with all the
> security considerations that such type imply. Our entire security
> consideration section and protocol design are based on have a well defined
> client type.
>
> Requiring separate registration for each component is the most
> straight-forward solution. Allowing the authorization server to offer
> alternatives is the backdoor to enable extensibility.
>
> Within these constraints, I am open to other prose or creative solutions.
> But the add-ons proposed are all ugly hacks. They clarify specific questions
> raised which I do not believe represent the core confusion here which is
> what is the right way to handle hybrid clients.
>
> The best way to move forward is to take a minute and ask the group to share
> how they handle such cases or how they think they should be handled. Based
> on that we can come up with a clear solution.
>
> EH
>
> From: Breno de Medeiros <[email-masked]>
> To: Eran Hammer-Lahav <[email-masked]>
> Cc: Nat Sakimura <[email-masked]>, OAuth WG <[email-masked]>
>
> authorization server provides other registration options to specify such
> complex clients." seems a very round about way to say that the core spec
> already provides for such arrangements in the most common scenario. It is a
> bit of a stretch to say that the server provides "other registration
> options" by simply following strategy already laid out in the spec.
>
> In particular, I feel that this wording will be harmful to register extended
> behavior, e.g., alternative response_types by leading to fruitless
> in which the spec was written (in particular the effort to specify two flows
> in detail to deal with precisely this issue) and possibly lead to harmful
> future interpretation.
>
>>
>>
>>
>> EH
>>
>>
>>

-- 
--Breno

---

From: Eran Hammer <[email-masked]>
Date: Thu, 15 Mar 2012 12:13:21 -0700

Which text in -25 are you proposing we remove exactly? I can't judge the
text below without the full context of where and how it is proposed in the
current document.

Also, you are ignoring my detailed analysis of the current facts. We have
two client types and the issue here is what to do with other, undefined
types.

EH

On 3/15/12 11:54 AM, "Breno de Medeiros" <[email-masked]> wrote:

>>> response type, that¹s not an issue but more of an optimization for an
>>>edge
>>> case raised.
>>
>>
>>extended
>>flows
>>>Of
>>> Nat Sakimura

---

From: Breno de Medeiros <[email-masked]>
Date: Thu, 15 Mar 2012 12:30:03 -0700

I am proposing the entire removal of:

proper handling by the authorization server."

In particular the example of a server-side component versus
browser-based components is particularly unhelpful since it violates
the entire principle of why two response_type 'code' and 'token' were
defined, and how OAuth2 is typically implemented. That's when I claim
this normative language is redefining the protocol.

-- 
--Breno

---

From: Eran Hammer <[email-masked]>
Date: Thu, 15 Mar 2012 13:13:21 -0700

Ok. That's much better than my guess that you wanted to drop all the
registration text from the specification…

What I'm looking for is a simple text that answers the question:

"What to do if my client isn't simply public or confidential?"

If we just drop the current text, the answer is implicitly "you can't have
such a client" because there is no way to register a client of any other
type.

So let's try this again, and focus exclusively on answering this question.
My text takes a position which is, "you can't - unless". Your suggestion
is more of a vague discussion of the topic. I'd like to see clear,
normative answer to this question.

EH

On 3/15/12 12:30 PM, "Breno de Medeiros" <[email-masked]> wrote:

>>>>>Behalf

---

From: Breno de Medeiros <[email-masked]>
Date: Thu, 15 Mar 2012 14:12:08 -0700

> normative answer to this question.

The current version is normative but far from clear. In fact, the most
natural interpretation is that it bans normal practice and throws away
the work that was done in defining different flow types to support
normal practice.

1. I don't see the need or desirability to put normative language on
registration practices.
2. The contents of said normative language are harmful.

I suggest two alternatives:

1. Remove the language.
2. Substitute the language by non-normative informative discussion.

You can also do other things, like introduce normative language that
makes sense. But I have not yet seen proposed language that would be
acceptable.

-- 
--Breno

---

From: Eran Hammer <[email-masked]>
Date: Thu, 15 Mar 2012 15:43:33 -0700

I don't know how to better explain myself. Forget about the text you have issue with. Just answer this:

Reading the specification (with that text removed), what happens when a hybrid client wants to register? What client type does it provide? How should the server handle this case?

EH

> Sent: Thursday, March 15, 2012 2:12 PM
> To: Eran Hammer
> Cc: Nat Sakimura; OAuth WG
> > registration text from the specification.
> >
> > If we just drop the current text, the answer is implicitly "you can't
> > have such a client" because there is no way to register a client of
> > any other type.
> >
> > My text takes a position which is, "you can't - unless". Your
> > suggestion is more of a vague discussion of the topic. I'd like to see
> > clear, normative answer to this question.
> 
> The current version is normative but far from clear. In fact, the most natural
> interpretation is that it bans normal practice and throws away the work that
> was done in defining different flow types to support normal practice.
> 
> You can also do other things, like introduce normative language that makes
> sense. But I have not yet seen proposed language that would be acceptable.
> 
> >
> > EH
> >
> >
> >>> Which text in -25 are you proposing we remove exactly? I can't judge
> >>>the  text below without the full context of where and how it is
> >>>proposed in the  current document.
> >>>
> >>> Also, you are ignoring my detailed analysis of the current facts. We
> >>>have  two client types and the issue here is what to do with other,
> >>>undefined  types.
> >>>
> >>> EH
> >>>
> >>>
> >>>>My proposal is to remove any reference to registration (which is a
> >>>>red herring and has raised all the problems we refer here) and refer
> >>>>to client authentication instead.
> >>>>
> >>>>Proposal:
> >>>>
> >>>>run in different security contexts. For instance, a single client
> >>>>may include a webserver component and a script component in a
> >>>>browser. It is not appropriate for the different components to
> >>>>utilize the same client authentication mechanisms, since client
> >>>>authentication credentials that are held securely in one context
> >>>>cannot be deployed securely in another.
> >>>>
> >>>>cannot hold client credentials as securely by distinguishing them
> >>>>from client components that can. Example of suitable measures are:
> >>>>
> >>>>- Requiring separate registration of components such as web server
> >>>>and a mobile application.
> >>>>- Restricting the time validity of tokens issued to clients that
> >>>>hold no authentication credentials, such as browser script-based
> >>>>components."
> >>>>
> >>>>> The authorization server must know the client type in order to
> >>>>>enforce many  of the requirements in the specification.
> >>>>> The requirement to provide a client type is not decorated with a
> >>>>>MUST or  SHALL but that is implied.
> >>>>> The specification needs to address the very common use case of
> >>>>>clients with  both public and private components.
> >>>>>
> >>>>> I don't want to discuss in the specification how client
> >>>>>identifiers are  provisioned, nor do I want to discuss the
> >>>>>potential binding of response  types to client types. But we do
> >>>>>need to provide some guidance to clients  and authorization servers
> >>>>>what to do with clients that do not fit the  current type
> >>>>>definitions.
> >>>>>
> >>>>> It is far too late for us to define a new client type, along with
> >>>>>all the  security considerations that such type imply. Our entire
> >>>>>security  consideration section and protocol design are based on
> >>>>>have a well defined  client type.
> >>>>>
> >>>>> straight-forward solution. Allowing the authorization server to
> >>>>> offer alternatives is the backdoor to enable extensibility.
> >>>>>
> >>>>> But the add-ons proposed are all ugly hacks. They clarify specific
> >>>>>questions  raised which I do not believe represent the core
> >>>>>confusion here which is  what is the right way to handle hybrid
> >>>>>clients.
> >>>>>
> >>>>> The best way to move forward is to take a minute and ask the group
> >>>>>to share  how they handle such cases or how they think they should
> >>>>>be handled.
> >>>>>Based
> >>>>>> This add-on is unnecessary. It already says the authorization
> >>>>>>server can  handle it any way it wants. The fact that other
> >>>>>>registration options are  possible clearly covers the client
> >>>>>>identifier reuse case. As for the  response type, that¹s not an
> >>>>>>issue but more of an optimization for an edge  case raised.
> >>>>>
> >>>>>
> >>>>>authorization server provides other registration options to specify
> >>>>>such  complex clients." seems a very round about way to say that
> >>>>>the core spec  already provides for such arrangements in the most
> >>>>>common scenario. It is a  bit of a stretch to say that the server
> >>>>>provides "other registration  options" by simply following strategy
> >>>>>already laid out in the spec.
> >>>>>
> >>>>> In particular, I feel that this wording will be harmful to
> >>>>>register extended  behavior, e.g., alternative response_types by
> >>>>>leading to fruitless  conversations about spec compliance in the
> >>>>>absence of real security risks.
> >>>>>
> >>>>> I do not believe the current text is the best representation of
> >>>>>the spirit  in which the spec was written (in particular the effort
> >>>>>to specify two flows  in detail to deal with precisely this issue)
> >>>>>and possibly lead to harmful  future interpretation.
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> EH
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>Behalf Of  Nat Sakimura
> >>>>>> kind of meets my concern. There seems to be another issue around
> >>>>>>the  usefulness of return_type in such case raised by Breno, and
> >>>>>>if I understand  it correctly, Eran's answer was that these
> >>>>>>separate components may have the  same client_id so that
> >>>>>>return_type is a valid parameter to be sent at the  request.
> >>>>>>
> >>>>>>
> >>>>>>

---

From: Breno de Medeiros <[email-masked]>
Date: Thu, 15 Mar 2012 15:54:42 -0700

> Reading the specification (with that text removed), what happens when a hybrid client wants to register? What client type does it provide? How should the server handle this case?

In the example case of the webserver + browser-based client
components, I think the server should just allow it. The browser does
not need to expose the client_secret since it requires no
authentication credentials. The webserver should use the client
credentials acquired during registration to authenticate itself when
using the code flow.

It's more interesting when mobile applications and webserver want to
share credentials. The mitigation strategy of limiting lifetime of
tokens may not work in this case. In general the registration server
should not allow the use of a single registration in this case. This
case is different from the above in the sense that installed
applications are typically _also_ using the 'code' flow, but from a
different security context. A server could allow both clients to share
the same registration information, but segregate the set of redirect
URLs and tie the code to each security context and apply different
client authentication requirements to each. Or the server could
require separate client registration for each component.

-- 
--Breno

---

From: Breno <[email-masked]>
Date: Sat, 17 Mar 2012 08:50:26 -0700

To summarize, I am weary of registration normative language that
appears to disallow common practice implemented by servers to securely
support multi-component applications. If these common practices will
be non-compliant (or at least it appears to be so on first reading by
many different people with detailed knowledge of the spec), isn't it
incumbent on this spec to provide guidance on _how_ different
components of an application will interoperate under different
registration? At least for the very common case of a webserver +
browser component, the importance of which is already enshrined in the
spec by the definition of two response_types and flows?

-- 
Breno de Medeiros

---

From: Eran Hammer <[email-masked]>
Date: Sat, 17 Mar 2012 09:17:57 -0700

How about we phrase it the other way:

A clients may be implemented as a distributed set of components, each with a different
client type and security context (e.g. a distributed client with both a confidential
server-based component and a public browser-based component). If the authorization
 server does not provide support for such clients, or does not provide guidance with regard
to their registration, the client SHOULD register each component as a separate client.

This does two thing: put the server's policy first instead of as the exception, and uses SHOULD instead of MUST which seems to be too strong for many people.

Better?

EH

> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Breno
> Sent: Saturday, March 17, 2012 8:50 AM
> To: Eran Hammer
> Cc: OAuth WG
> To summarize, I am weary of registration normative language that appears to
> disallow common practice implemented by servers to securely support multi-
> component applications. If these common practices will be non-compliant (or
> at least it appears to be so on first reading by many different people with
> detailed knowledge of the spec), isn't it incumbent on this spec to provide
> guidance on _how_ different components of an application will interoperate
> under different registration? At least for the very common case of a
> webserver + browser component, the importance of which is already
> enshrined in the spec by the definition of two response_types and flows?
>
> >> Reading the specification (with that text removed), what happens when a
> hybrid client wants to register? What client type does it provide? How should
> the server handle this case?
> >
> >>> > Ok. That's much better than my guess that you wanted to drop all
> >>> > the registration text from the specification.
> >>> >
> >>> > If we just drop the current text, the answer is implicitly "you
> >>> > can't have such a client" because there is no way to register a
> >>> > client of any other type.
> >>> >
> >>> > suggestion is more of a vague discussion of the topic. I'd like to
> >>> > see clear, normative answer to this question.
> >>>
> >>> The current version is normative but far from clear. In fact, the
> >>> most natural interpretation is that it bans normal practice and
> >>> throws away the work that was done in defining different flow types to
> support normal practice.
> >>>
> >>> >>client to ensure proper handling by the authorization server."
> >>> >>
> >>> >>browser-based components is particularly unhelpful since it
> >>> >>violates the entire principle of why two response_type 'code' and
> >>> >>'token' were defined, and how OAuth2 is typically implemented.
> >>> >>That's when I claim this normative language is redefining the protocol.
> >>> >>
> >>> >>
> >>> >>> Which text in -25 are you proposing we remove exactly? I can't
> >>> >>>judge the  text below without the full context of where and how
> >>> >>>it is proposed in the  current document.
> >>> >>>
> >>> >>> Also, you are ignoring my detailed analysis of the current
> >>> >>>facts. We have  two client types and the issue here is what to do
> >>> >>>with other, undefined  types.
> >>> >>>
> >>> >>> EH
> >>> >>>
> >>> >>>
> >>> >>>>My proposal is to remove any reference to registration (which is
> >>> >>>>a red herring and has raised all the problems we refer here) and
> >>> >>>>refer to client authentication instead.
> >>> >>>>
> >>> >>>>Proposal:
> >>> >>>>
> >>> >>>>"Clients may be implemented as a distributed set of components
> >>> >>>>that run in different security contexts. For instance, a single
> >>> >>>>client may include a webserver component and a script component
> >>> >>>>in a browser. It is not appropriate for the different components
> >>> >>>>to utilize the same client authentication mechanisms, since
> >>> >>>>client authentication credentials that are held securely in one
> >>> >>>>context cannot be deployed securely in another.
> >>> >>>>
> >>> >>>>Servers MUST mitigate security threats from client components
> >>> >>>>that cannot hold client credentials as securely by
> >>> >>>>distinguishing them from client components that can. Example of
> suitable measures are:
> >>> >>>>
> >>> >>>>- Requiring separate registration of components such as web
> >>> >>>>server and a mobile application.
> >>> >>>>Please don't truncate explanations in the interest of space if
> >>> >>>>the resulting text is confusing and possibly misleading. Better
> >>> >>>>to say nothing instead.
> >>> >>>>
> >>> >>>>On Thu, Mar 15, 2012 at 11:32, Eran Hammer
> <[email-masked]>
> >>> wrote:
> >>> >>>>> Here are the facts:
> >>> >>>>>
> >>> >>>>> The requirement to provide a client type is not decorated with
> >>> >>>>>a MUST or  SHALL but that is implied.
> >>> >>>>>need to provide some guidance to clients  and authorization
> >>> >>>>>servers what to do with clients that do not fit the  current
> >>> >>>>>type definitions.
> >>> >>>>>
> >>> >>>>> It is far too late for us to define a new client type, along
> >>> >>>>>with all the  security considerations that such type imply. Our
> >>> >>>>>entire security  consideration section and protocol design are
> >>> >>>>>based on have a well defined  client type.
> >>> >>>>>
> >>> >>>>> straight-forward solution. Allowing the authorization server
> >>> >>>>> to offer alternatives is the backdoor to enable extensibility.
> >>> >>>>>
> >>> >>>>> But the add-ons proposed are all ugly hacks. They clarify
> >>> >>>>>specific questions  raised which I do not believe represent the
> >>> >>>>>core confusion here which is  what is the right way to handle
> >>> >>>>>hybrid clients.
> >>> >>>>>
> >>> >>>>> The best way to move forward is to take a minute and ask the
> >>> >>>>>group to share  how they handle such cases or how they think
> >>> >>>>>they should be handled.
> >>> >>>>>Based
> >>> >>>>> On Thu, Mar 15, 2012 at 07:45, Eran Hammer
> >>> >>>>><[email-masked]>
> >>> >>>>>wrote:
> >>> >>>>>>
> >>> >>>>>>identifier reuse case. As for the  response type, that¹s not
> >>> >>>>>>an issue but more of an optimization for an edge  case raised.
> >>> >>>>>
> >>> >>>>>
> >>> >>>>>authorization server provides other registration options to
> >>> >>>>>specify such  complex clients." seems a very round about way to
> >>> >>>>>say that the core spec  already provides for such arrangements
> >>> >>>>>in the most common scenario. It is a  bit of a stretch to say
> >>> >>>>>that the server provides "other registration  options" by
> >>> >>>>>simply following strategy already laid out in the spec.
> >>> >>>>>
> >>> >>>>>register extended  behavior, e.g., alternative response_types
> >>> >>>>>by leading to fruitless  conversations about spec compliance in
> >>> >>>>>the absence of real security risks.
> >>> >>>>>
> >>> >>>>> I do not believe the current text is the best representation
> >>> >>>>>of the spirit  in which the spec was written (in particular the
> >>> >>>>>effort to specify two flows  in detail to deal with precisely
> >>> >>>>>this issue) and possibly lead to harmful  future interpretation.
> >>> >>>>>
> >>> >>>>>>
> >>> >>>>>>
> >>> >>>>>>
> >>> >>>>>> EH
> >>> >>>>>>
> >>> >>>>>>
> >>> >>>>>>
> >>> >>>>>> From: [email-masked] [mailto:oauth-
> [email-masked]]
> >>> >>>>>>On Behalf Of  Nat Sakimura
> >>> >>>>>> kind of meets my concern. There seems to be another issue
> >>> >>>>>>around the  usefulness of return_type in such case raised by
> >>> >>>>>>Breno, and if I understand  it correctly, Eran's answer was
> >>> >>>>>>that these separate components may have the  same client_id
> so
> >>> >>>>>>that return_type is a valid parameter to be sent at the  request.
> >>> >>>>>>
> >>> >>>>>>
> >>> >>>>>>
> >>> >>>>>> So, to clarify these, perhaps changing the above text
> >>> >>>>>> slightly to the following solves the problem?
> >>> >>>>>>
> >>> >>>>>>
> >>> >>>>>>

---

From: Breno <[email-masked]>
Date: Sat, 17 Mar 2012 12:10:24 -0700

That is much clearer. Thank you.

-- 
Breno de Medeiros

---

From: Eran Hammer <[email-masked]>
Date: Sat, 17 Mar 2012 14:43:17 -0700

Mike, Nat,

Does the new text work for you?

EH

> Sent: Saturday, March 17, 2012 12:10 PM
> To: Eran Hammer
> Cc: OAuth WG
> > A clients may be implemented as a distributed set of components, each
> > with a different client type and security context (e.g. a distributed
> > client with both a confidential server-based component and a public
> > browser-based component). If the authorization
> >  server does not provide support for such clients, or does not provide
> > guidance with regard to their registration, the client SHOULD register each
> component as a separate client.
> >
> > This does two thing: put the server's policy first instead of as the exception,
> and uses SHOULD instead of MUST which seems to be too strong for many
> people.
> >
> > Better?
> >
> > EH
> >
> >
> >> appears to disallow common practice implemented by servers to
> >> securely support multi- component applications. If these common
> >> practices will be non-compliant (or at least it appears to be so on
> >> first reading by many different people with detailed knowledge of the
> >> spec), isn't it incumbent on this spec to provide guidance on _how_
> >> different components of an application will interoperate under
> >> different registration? At least for the very common case of a
> >> On Thu, Mar 15, 2012 at 3:54 PM, Breno de Medeiros
> <[email-masked]>
> >> wrote:
> >> >> I don't know how to better explain myself. Forget about the text
> >> >> you
> >> have issue with. Just answer this:
> >> >>
> >> hybrid client wants to register? What client type does it provide?
> >> How should the server handle this case?
> >> >
> >> > components, I think the server should just allow it. The browser
> >> > does not need to expose the client_secret since it requires no
> >> > credentials acquired during registration to authenticate itself
> >> > when using the code flow.
> >> >
> >> > It's more interesting when mobile applications and webserver want
> >> > to share credentials. The mitigation strategy of limiting lifetime
> >> > of tokens may not work in this case. In general the registration
> >> > server should not allow the use of a single registration in this
> >> > case. This case is different from the above in the sense that
> >> > installed applications are typically _also_ using the 'code' flow,
> >> > but from a different security context. A server could allow both
> >> > clients to share the same registration information, but segregate
> >> > the set of redirect URLs and tie the code to each security context
> >> > and apply different client authentication requirements to each. Or
> >> > the server could require separate client registration for each
> component.
> >> >
> >> >>
> >> >> EH
> >> >>
> >> >>> On Thu, Mar 15, 2012 at 13:13, Eran Hammer
> <[email-masked]>
> >> >>> wrote:
> >> >>> > Ok. That's much better than my guess that you wanted to drop
> >> >>> > all the registration text from the specification.
> >> >>> >
> >> >>> > suggestion is more of a vague discussion of the topic. I'd like
> >> >>> > to see clear, normative answer to this question.
> >> >>>
> >> >>> 1. I don't see the need or desirability to put normative language
> >> >>> on registration practices.
> >> >>> You can also do other things, like introduce normative language
> >> >>> that makes sense. But I have not yet seen proposed language that
> >> >>> would be
> >> acceptable.
> >> >>>
> >> >>> >
> >> >>> > EH
> >> >>> >
> >> >>> >
> server."
> >> >>> >>violates the entire principle of why two response_type 'code'
> >> >>> >>and 'token' were defined, and how OAuth2 is typically
> implemented.
> >> >>> >>On Thu, Mar 15, 2012 at 12:13, Eran Hammer
> >> >>> >><[email-masked]>
> >> >>> wrote:
> >> >>> >>> Which text in -25 are you proposing we remove exactly? I
> >> >>> >>>can't judge the  text below without the full context of where
> >> >>> >>>and how it is proposed in the  current document.
> >> >>> >>>
> >> >>> >>>facts. We have  two client types and the issue here is what to
> >> >>> >>>do with other, undefined  types.
> >> >>> >>>
> >> >>> >>> EH
> >> >>> >>>
> >> >>> >>>
> >> >>> >>> On 3/15/12 11:54 AM, "Breno de Medeiros"
> <[email-masked]>
> >> >>> wrote:
> >> >>> >>>
> >> >>> >>>>My proposal is to remove any reference to registration (which
> >> >>> >>>>is a red herring and has raised all the problems we refer
> >> >>> >>>>here) and refer to client authentication instead.
> >> >>> >>>>
> >> >>> >>>>Proposal:
> >> >>> >>>>
> >> >>> >>>>"Clients may be implemented as a distributed set of
> >> >>> >>>>components that run in different security contexts. For
> >> >>> >>>>instance, a single client may include a webserver component
> >> >>> >>>>and a script component in a browser. It is not appropriate
> >> >>> >>>>for the different components to utilize the same client
> >> >>> >>>>authentication mechanisms, since client authentication
> >> >>> >>>>credentials that are held securely in one context cannot be
> deployed securely in another.
> >> >>> >>>>
> >> >>> >>>>- Restricting the time validity of tokens issued to clients
> >> >>> >>>>that hold no authentication credentials, such as browser
> >> >>> >>>>script-based components."
> >> >>> >>>>
> >> >>> >>>>Please don't truncate explanations in the interest of space
> >> >>> >>>>if the resulting text is confusing and possibly misleading.
> >> >>> >>>>Better to say nothing instead.
> >> >>> >>>>
> >> >>> >>>>> The authorization server must know the client type in order
> >> >>> >>>>>to enforce many  of the requirements in the specification.
> >> >>> >>>>> The requirement to provide a client type is not decorated
> >> >>> >>>>>with a MUST or  SHALL but that is implied.
> >> >>> >>>>> The specification needs to address the very common use case
> >> >>> >>>>>of clients with  both public and private components.
> >> >>> >>>>>
> >> >>> >>>>>potential binding of response  types to client types. But we
> >> >>> >>>>>do need to provide some guidance to clients  and
> >> >>> >>>>>authorization servers what to do with clients that do not
> >> >>> >>>>>fit the  current type definitions.
> >> >>> >>>>>
> >> >>> >>>>> It is far too late for us to define a new client type,
> >> >>> >>>>>along with all the  security considerations that such type
> >> >>> >>>>>imply. Our entire security  consideration section and
> >> >>> >>>>>protocol design are based on have a well defined  client type.
> >> >>> >>>>>
> >> >>> >>>>> Requiring separate registration for each component is the
> >> >>> >>>>> most straight-forward solution. Allowing the authorization
> >> >>> >>>>> server to offer alternatives is the backdoor to enable
> extensibility.
> >> >>> >>>>>
> >> >>> >>>>>specific questions  raised which I do not believe represent
> >> >>> >>>>>the core confusion here which is  what is the right way to
> >> >>> >>>>>handle hybrid clients.
> >> >>> >>>>>
> >> >>> >>>>> The best way to move forward is to take a minute and ask
> >> >>> >>>>>the group to share  how they handle such cases or how they
> >> >>> >>>>>think they should be handled.
> >> >>> >>>>>Based
> >> >>> >>>>> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0
> rev.
> >> >>> >>>>> 23
> >> >>> >>>>>
> >> >>> >>>>>
> >> >>> >>>>>
> >> >>> >>>>>> This add-on is unnecessary. It already says the
> >> >>> >>>>>>authorization server can  handle it any way it wants. The
> >> >>> >>>>>>fact that other registration options are  possible clearly
> >> >>> >>>>>>covers the client identifier reuse case. As for the
> >> >>> >>>>>>response type, that¹s not an issue but more of an
> optimization for an edge  case raised.
> >> >>> >>>>>
> >> >>> >>>>>
> >> >>> >>>>>specify such  complex clients." seems a very round about way
> >> >>> >>>>>to say that the core spec  already provides for such
> >> >>> >>>>>arrangements in the most common scenario. It is a  bit of a
> >> >>> >>>>>stretch to say that the server provides "other registration
> >> >>> >>>>>register extended  behavior, e.g., alternative
> >> >>> >>>>>response_types by leading to fruitless  conversations about
> >> >>> >>>>>spec compliance in the absence of real security risks.
> >> >>> >>>>>
> >> >>> >>>>> I do not believe the current text is the best
> >> >>> >>>>>representation of the spirit  in which the spec was written
> >> >>> >>>>>(in particular the effort to specify two flows  in detail to
> >> >>> >>>>>deal with precisely this issue) and possibly lead to
> >> >>> >>>>>> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0
> rev.
> >> >>> >>>>>> 23
> >> >>> >>>>>>
> >> >>> >>>>>>
> >> >>> >>>>>>
> >> >>> >>>>>>
> >> >>> >>>>>>
> >> >>> >>>>>>around the  usefulness of return_type in such case raised
> >> >>> >>>>>>by Breno, and if I understand  it correctly, Eran's answer
> >> >>> >>>>>>was that these separate components may have the  same
> >> >>> >>>>>>client_id
> >> so

---

From: Mike Jones <[email-masked]>
Date: Sat, 17 Mar 2012 23:28:13 +0000

Much better.  Thanks for working with Breno on the new wording.

				-- Mike

-----Original Message-----
From: Eran Hammer [mailto:[email-masked]] 
Sent: Saturday, March 17, 2012 2:43 PM
To: Mike Jones; 'Nat Sakimura ([email-masked])'
Cc: OAuth WG
Subject: RE: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23

Mike, Nat,

EH

> > A clients may be implemented as a distributed set of components, 
> > each with a different client type and security context (e.g. a 
> > distributed client with both a confidential server-based component 
> > and a public browser-based component). If the authorization  server 
> > does not provide support for such clients, or does not provide 
> >> first reading by many different people with detailed knowledge of 
> >> the spec), isn't it incumbent on this spec to provide guidance on 
> >> _how_ different components of an application will interoperate 
> >> under different registration? At least for the very common case of 
> >> a webserver + browser component, the importance of which is already
> >> > to share credentials. The mitigation strategy of limiting 
> >> > lifetime of tokens may not work in this case. In general the 
> >> > registration server should not allow the use of a single 
> >> > registration in this case. This case is different from the above 
> >> > in the sense that installed applications are typically _also_ 
> >> > using the 'code' flow, but from a different security context. A 
> >> > server could allow both clients to share the same registration 
> >> > information, but segregate the set of redirect URLs and tie the 
> >> > code to each security context and apply different client 
> >> > authentication requirements to each. Or the server could require 
> >> > separate client registration for each
> component.
> >> >
> >> >>
> >> >> EH
> >> >>
> >> >>> > If we just drop the current text, the answer is implicitly 
> >> >>> > "you can't have such a client" because there is no way to 
> >> >>> > register a client of any other type.
> >> >>> >
> >> >>> > So let's try this again, and focus exclusively on answering 
> >> >>> > this
> question.
> >> >>> > suggestion is more of a vague discussion of the topic. I'd 
> >> >>> > like to see clear, normative answer to this question.
> >> >>>
> >> >>> The current version is normative but far from clear. In fact, 
> >> >>> the most natural interpretation is that it bans normal practice 
> >> >>> and throws away the work that was done in defining different 
> >> >>> flow types to
> >> support normal practice.
> >> >>>
> >> >>> 1. I don't see the need or desirability to put normative 
> >> >>> language on registration practices.
> >> >>> that makes sense. But I have not yet seen proposed language 
> >> >>> that would be
> >> acceptable.
> >> >>>
> >> >>> >
> >> >>> > EH
> >> >>> >
> >> >>> >
> >> >>> >>with its own client type (e.g. a distributed client with both 
> >> >>> >>a confidential server-based component and a public 
> >> >>> >>browser-based component), MUST register each component 
> >> >>> >>separately as a different client to ensure proper handling by 
> >> >>> >>the authorization
> server."
> >> >>> >>
> >> >>> >>>can't judge the  text below without the full context of 
> >> >>> >>>where and how it is proposed in the  current document.
> >> >>> >>>
> >> >>> >>>facts. We have  two client types and the issue here is what 
> >> >>> >>>to do with other, undefined  types.
> >> >>> >>>
> >> >>> >>> EH
> >> >>> >>>
> >> >>> >>>
> >> >>> >>>>My proposal is to remove any reference to registration 
> >> >>> >>>>(which is a red herring and has raised all the problems we 
> >> >>> >>>>refer
> >> >>> >>>>Servers MUST mitigate security threats from client 
> >> >>> >>>>components that cannot hold client credentials as securely 
> >> >>> >>>>by distinguishing them from client components that can. 
> >> >>> >>>>Example of
> >> suitable measures are:
> >> >>> >>>>
> >> >>> >>>>> The authorization server must know the client type in 
> >> >>> >>>>>order to enforce many  of the requirements in the specification.
> >> >>> >>>>> The specification needs to address the very common use 
> >> >>> >>>>>case of clients with  both public and private components.
> >> >>> >>>>>
> >> >>> >>>>>potential binding of response  types to client types. But 
> >> >>> >>>>>we do need to provide some guidance to clients  and 
> >> >>> >>>>> most straight-forward solution. Allowing the 
> >> >>> >>>>> authorization server to offer alternatives is the 
> >> >>> >>>>> backdoor to enable
> extensibility.
> >> >>> >>>>>
> >> >>> >>>>>specific questions  raised which I do not believe 
> >> >>> >>>>>represent the core confusion here which is  what is the 
> >> >>> >>>>>right way to handle hybrid clients.
> >> >>> >>>>>
> >> >>> >>>>>>fact that other registration options are  possible 
> >> >>> >>>>>>clearly covers the client identifier reuse case. As for 
> >> >>> >>>>>>the response type, that¹s not an issue but more of an
> >> >>> >>>>> It still feels like a horse by committee to me. "unless 
> >> >>> >>>>>the authorization server provides other registration 
> >> >>> >>>>>options to specify such  complex clients." seems a very 
> >> >>> >>>>>round about way to say that the core spec  already 
> >> >>> >>>>>provides for such arrangements in the most common 
> >> >>> >>>>>scenario. It is a  bit of a stretch to say that the server 
> >> >>> >>>>>provides "other registration options" by simply following 
> >> >>> >>>>> In particular, I feel that this wording will be harmful 
> >> >>> >>>>>to register extended  behavior, e.g., alternative 
> >> >>> >>>>>response_types by leading to fruitless  conversations 
> >> >>> >>>>>about spec compliance in the absence of real security risks.
> >> >>> >>>>>
> >> >>> >>>>>representation of the spirit  in which the spec was 
> >> >>> >>>>>written (in particular the effort to specify two flows  in 
> >> >>> >>>>>detail to deal with precisely this issue) and possibly 
> >> >>> >>>>>lead to
> >> >>> >>>>>> kind of meets my concern. There seems to be another 
> >> >>> >>>>>>issue around the  usefulness of return_type in such case 
> >> >>> >>>>>>raised by Breno, and if I understand  it correctly, 
> >> >>> >>>>>>Eran's answer was that these separate components may have 
> >> >>> >>>>>>the  same client_id
> >> so

---

From: Nat Sakimura <[email-masked]>
Date: Sun, 18 Mar 2012 08:31:17 +0900

Thanks Eran.

This is much better.

=nat

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

---

From: John Bradley <[email-masked]>
Date: Sun, 18 Mar 2012 01:09:23 -0400

OK with me. 

John B 

Sent from my iPad