Subject: [OAUTH-WG] Call for Adoption

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 19 Jan 2016 12:39:34 +0100

Hi all,

we have submitted our new charter to the IESG (see
http://www.ietf.org/mail-archive/web/oauth/current/msg15379.html) and
since some IESG members like to see an updated list of milestones as
well. For this reason, based on a suggestion from Barry, we are also
starting a call for adoption concurrently with the review of the charter
text by the IESG.

We will post separate mails on the individual documents. Your feedback
is important! Please take the time to look at the documents and provide
your feedback.

Ciao
Hannes & Derek

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 20 Jan 2016 03:05:07 +0000

Thanks Hannes.

I did not find https://tools.ietf.org/html/draft-sakimura-oauth-meta-05, which
was discussed in Yokohama, and was largely in agreement if my recollection
is correct. Why is it not in the call for adoption?

2016年1月19日(火) 20:39 Hannes Tschofenig <[email-masked]>:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 20 Jan 2016 03:30:01 +0000

Just to give more context, at IETF 94, I have done a presentation on
discovery.

According to the minutes,

    (f) Discovery (Nat)

             Nat explains his document as an example of the work that
has to be done
             in the area of discovery, which is a topic that has been identified
             as necessary for interoperability since many years but so far there
             was not time to work on it. Mike, John and Nat are working on a new
             document that describes additional discovery-relevant components.

             Poll: 19 for / zero against / 4 persons need more information.

The document discussed there was
https://tools.ietf.org/html/draft-sakimura-oauth-meta-05. This is a simple
(only 1-page!) but a very powerful document that nudges towards HATEOAS
which is at the core of RESTful-ness. It also mitigates the Mix-up attack
without introducing the concept of issuer which is not in RFC6749. It is
also good for selecting different endpoints depending on the user
authentication and authorization results and more privacy sensitive than
pre-announced Discovery document. It also allows you to find to which
protected resource endpoint you can use the access token against.

In the last sentence of the minutes, it talks about "a new document that
describes additional discovery-relevant components". This is
https://tools.ietf.org/html/draft-jones-oauth-discovery-00.  It went for
the call for adoption. However, it is only a half of the story. I believe
https://tools.ietf.org/html/draft-sakimura-oauth-meta-05 that was discussed
at IETF 94 and had support there should be adopted as well.

Nat Sakimura

---

From: Justin Richer <[email-masked]>
Date: Wed, 20 Jan 2016 08:53:33 -0500

+1

Inline discovery and pre-configured discovery (ie, .well-known) should 
at the very least be compatible and developed together. It's the 
pre-configured discovery document that's at the root of the mix-up 
attack in the first place.

  -- Justin

On 1/19/2016 10:30 PM, Nat Sakimura wrote:
>               Nat explains his document as an example of the work that has to be done
> https://tools.ietf.org/html/draft-sakimura-oauth-meta-05. This is a 
> simple (only 1-page!) but a very powerful document that nudges towards 
> HATEOAS which is at the core of RESTful-ness. It also mitigates the 
> Mix-up attack without introducing the concept of issuer which is not 
> in RFC6749. It is also good for selecting different endpoints 
> depending on the user authentication and authorization results and 
> more privacy sensitive than pre-announced Discovery document. It also 
> allows you to find to which protected resource endpoint you can use 
> the access token against.
>
> In the last sentence of the minutes, it talks about "a new document 
> that describes additional discovery-relevant components". This is 
> https://tools.ietf.org/html/draft-jones-oauth-discovery-00.  It went 
> for the call for adoption. However, it is only a half of the story. I 
> believe https://tools.ietf.org/html/draft-sakimura-oauth-meta-05 that 
> was discussed at IETF 94 and had support there should be adopted as well.
>
> Nat Sakimura
>
>
>
>
> 2016年1月20日(水) 12:05 Nat Sakimura <[email-masked] 
> <mailto:[email-masked]>>:
>
>     Thanks Hannes.
>
>     I did not find
>     https://tools.ietf.org/html/draft-sakimura-oauth-meta-05, which
>     was discussed in Yokohama, and was largely in agreement if my
>     recollection is correct. Why is it not in the call for adoption?
>
>
>
>     2016年1月19日(火) 20:39 Hannes Tschofenig
>     <[email-masked] <mailto:[email-masked]>>:
>
>         Hi all,
>
>         [email-masked] <mailto:[email-masked]>

---

From: William Denniss <[email-masked]>
Date: Thu, 21 Jan 2016 14:37:14 +0800

+1 to adopt this, and I agree with Justin's comments.

On Wed, Jan 20, 2016 at 9:53 PM, Justin Richer <[email-masked]> wrote:

> +1
>
> Inline discovery and pre-configured discovery (ie, .well-known) should at
> the very least be compatible and developed together. It's the
> pre-configured discovery document that's at the root of the mix-up attack
> in the first place.
>
>  -- Justin
>
>
> HATEOAS which is at the core of RESTful-ness. It also mitigates the Mix-up
> attack without introducing the concept of issuer which is not in RFC6749.
> It is also good for selecting different endpoints depending on the user
> <https://tools.ietf.org/html/draft-sakimura-oauth-meta-05>
> https://tools.ietf.org/html/draft-sakimura-oauth-meta-05 that was
> discussed at IETF 94 and had support there should be adopted as well.
>
> Nat Sakimura
>
>
>
>
> 2016年1月20日(水) 12:05 Nat Sakimura < <[email-masked]>[email-masked]
> >:
>
>> Thanks Hannes.
>>
>> 2016年1月19日(火) 20:39 Hannes Tschofenig < <[email-masked]>
>> [email-masked]>:
>>
>>> Hi all,
>>>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
>

---

From: Mike Jones <[email-masked]>
Date: Thu, 21 Jan 2016 07:02:19 +0000

Not to be negative, but I disagree with adopting draft-sakimura-oauth-meta.  We should define and promote one mitigation approach to the mix-up attacks.  Having two would confuse implementers and cause compatibility problems – reducing overall security.

The approach defined in draft-jones-oauth-mix-up-mitigation was created in collaboration with the security researchers who identified the problems in the first place, was vigorously discussed in the security meeting Hannes and Torsten held in Darmstadt, and has been since refined based on substantial input from the working group.  And at least three implementers have already stated that they’ve implemented it.  I’m not saying that it’s, but if there are things missing or things that need to be improved in our approach, we should do it there, rather introducing a competing approach.

Also, standard OAuth deployments register the client and then use the information gathered at registration time for subsequent protocol interactions.  They do not need all the configuration information for the authorization server to be retransmitted at runtime.  The oauth-meta draft goes too far in that direction, at least as I see it.  Returning things two ways creates its own problems, as discussed in the Duplicate Information Attacks security considerations section (7.2) of the mix-up-mitigation draft.

I’ll note that the mix-up-mitigation approach is compatible with existing practice in both static and dynamic metadata discovery.  Replying to Justin’s comment that “It's the pre-configured discovery document that's at the root of the mix-up attack in the first place” – this is not the case.  The attacks can be performed without either discovery or dynamic registration.

I would be interested in hearing a technical discussion on whether there are aspects of the oauth-meta approach that mitigate aspects of the attacks that the mix-up-mitigation approach does not.  That could help inform whether there are additional things we should add to or change in the mix-up draft.

                                                          -- Mike

From: OAuth [mailto:[email-masked]] On Behalf Of William Denniss
Sent: Wednesday, January 20, 2016 10:37 PM
To: Justin Richer <[email-masked]>
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Call for Adoption

On Wed, Jan 20, 2016 at 9:53 PM, Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:
+1

Inline discovery and pre-configured discovery (ie, .well-known) should at the very least be compatible and developed together. It's the pre-configured discovery document that's at the root of the mix-up attack in the first place.

 -- Justin

On 1/19/2016 10:30 PM, Nat Sakimura wrote:
Just to give more context, at IETF 94, I have done a presentation on discovery.

    (f) Discovery (Nat)

The document discussed there was https://tools.ietf.org/html/draft-sakimura-oauth-meta-05. This is a simple (only 1-page!) but a very powerful document that nudges towards HATEOAS which is at the core of RESTful-ness. It also mitigates the Mix-up attack without introducing the concept of issuer which is not in RFC6749. It is also good for selecting different endpoints depending on the user authentication and authorization results and more privacy sensitive than pre-announced Discovery document. It also allows you to find to which protected resource endpoint you can use the access token against.

In the last sentence of the minutes, it talks about "a new document that describes additional discovery-relevant components". This is https://tools.ietf.org/html/draft-jones-oauth-discovery-00.  It went for the call for adoption. However, it is only a half of the story. I believe https://tools.ietf.org/html/draft-sakimura-oauth-meta-05 that was discussed at IETF 94 and had support there should be adopted as well.

Nat Sakimura

2016年1月20日(水) 12:05 Nat Sakimura <[email-masked]<mailto:[email-masked]>>:
Thanks Hannes.

I did not find https://tools.ietf.org/html/draft-sakimura-oauth-meta-05, which was discussed in Yokohama, and was largely in agreement if my recollection is correct. Why is it not in the call for adoption?

2016年1月19日(火) 20:39 Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>:
Hi all,

Ciao
Hannes & Derek

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

OAuth mailing list

[email-masked]<mailto:[email-masked]>

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Nat Sakimura <[email-masked]>
Date: Thu, 21 Jan 2016 07:16:40 +0000

Hi Mike.

Conversely, I would like to ask why this approach does not work for Mix-up
attack. As Nov stated, we in fact have discussed the approach in quite a
length back in Yokohama. I really would like to know why it does not work.

Besides, for oauth-meta approach, mix-up attack is only one of the thing it
solves.

Nat Sakimura

2016年1月21日(木) 16:02 Mike Jones <[email-masked]>:

> Not to be negative, but I disagree with adopting
> draft-sakimura-oauth-meta.  We should define and promote one mitigation
> approach to the mix-up attacks.  Having two would confuse implementers and
> cause compatibility problems – reducing overall security.
>
>
>
> The approach defined in draft-jones-oauth-mix-up-mitigation was created in
> collaboration with the security researchers who identified the problems in
> the first place, was vigorously discussed in the security meeting Hannes
> and Torsten held in Darmstadt, and has been since refined based on
> substantial input from the working group.  And at least three implementers
> have already stated that they’ve implemented it.  I’m not saying that it’s,
> but if there are things missing or things that need to be improved in our
> approach, we should do it there, rather introducing a competing approach.
>
>
>
> Also, standard OAuth deployments register the client and then use the
> information gathered at registration time for subsequent protocol
> interactions.  They do not need all the configuration information for the
> authorization server to be retransmitted at runtime.  The oauth-meta draft
> goes too far in that direction, at least as I see it.  Returning things two
> ways creates its own problems, as discussed in the Duplicate Information
> Attacks security considerations section (7.2) of the mix-up-mitigation
> draft.
>
>
>
> I’ll note that the mix-up-mitigation approach is compatible with existing
> practice in both static and dynamic metadata discovery.  Replying to
> Justin’s comment that “It's the pre-configured discovery document that's
> at the root of the mix-up attack in the first place” – this is not the
> case.  The attacks can be performed without either discovery or dynamic
> registration.
>
>
>
> I would be interested in hearing a technical discussion on whether there
> are aspects of the oauth-meta approach that mitigate aspects of the attacks
> that the mix-up-mitigation approach does not.  That could help inform
> whether there are additional things we should add to or change in the
> mix-up draft.
>
>
>
>                                                           -- Mike
>
>
>
> *From:* OAuth [mailto:[email-masked]] *On Behalf Of *William
> Denniss
> *Sent:* Wednesday, January 20, 2016 10:37 PM
> *To:* Justin Richer <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [OAUTH-WG] Call for Adoption
>
>
>

---

From: Mike Jones <[email-masked]>
Date: Thu, 21 Jan 2016 07:55:03 +0000

My memory of the discussions of the oauth-meta draft in Yokohama were that many people felt that it was unnecessarily dynamically duplicating a lot of information that the client already had.  Most of us that were aware of the attacks then were in favor of a more targeted, minimal approach.  You were listened to in Yokohama, but that didn’t necessarily mean that people agreed with the approach.  Participants were already aware of the oauth-meta proposal in Darmstadt but no one spoke up in favor of it that I can recall.  Rather, I think people were thinking that “less is more”.

There have also been discussions in the last day about how dynamically returning a resource URL, which oauth-meta does, is both unnecessary (since the client initiated the resource authorization already knowing what resource it wants to access) and often problematic, since many authorization servers can authorize access to multiple resources.  If anything, the client should be telling the authorization server what resource it wants to access – not the other way around.

I’m not saying that there aren’t some good ideas in the oauth-meta draft – I’m sure there are, just as there are in the approach designed by the participants in Darmstadt.  While I volunteered to write the first draft of the mix-up-mitigation approach, it really reflects something a lot of people have already bought into – as evidenced in the passion in the high-volume “Mix-Up About The Mix-Up Mitigation” thread, and not just my personal project.

If you think there are things missing or wrong in the mix-up-mitigation draft, please say what they are.  That will help us quickly converge on a solution that will work for everyone.

                                                          Sincerely,
                                                          -- Mike

From: Nat Sakimura [mailto:[email-masked]]
Sent: Wednesday, January 20, 2016 11:17 PM
To: Mike Jones <[email-masked]>; William Denniss <[email-masked]>; Justin Richer <[email-masked]>
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Call for Adoption

Hi Mike.

Conversely, I would like to ask why this approach does not work for Mix-up attack. As Nov stated, we in fact have discussed the approach in quite a length back in Yokohama. I really would like to know why it does not work.

Besides, for oauth-meta approach, mix-up attack is only one of the thing it solves.

Nat Sakimura

2016年1月21日(木) 16:02 Mike Jones <[email-masked]<mailto:[email-masked]>>:
Not to be negative, but I disagree with adopting draft-sakimura-oauth-meta.  We should define and promote one mitigation approach to the mix-up attacks.  Having two would confuse implementers and cause compatibility problems – reducing overall security.

                                                          -- Mike

From: OAuth [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of William Denniss
Sent: Wednesday, January 20, 2016 10:37 PM
To: Justin Richer <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Call for Adoption

 -- Justin

    (f) Discovery (Nat)

Nat Sakimura

Ciao
Hannes & Derek

OAuth mailing list

---

From: Justin Richer <[email-masked]>
Date: Thu, 21 Jan 2016 07:18:07 -0500

Convergence is exactly what I’m arguing for, though. These things ought to work together.

 — Justin

> On Jan 21, 2016, at 2:55 AM, Mike Jones <[email-masked]> wrote:
> 
>   <>
> 2016年1月21日(木) 16:02 Mike Jones <[email-masked] <mailto:[email-masked]>>:
>   <>
> From: OAuth [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of William Denniss
> To: Justin Richer <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>
> On Wed, Jan 20, 2016 at 9:53 PM, Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
> +1
> 
> The document discussed there was https://tools.ietf.org/html/draft-sakimura-oauth-meta-05 <https://tools.ietf.org/html/draft-sakimura-oauth-meta-05>. This is a simple (only 1-page!) but a very powerful document that nudges towards HATEOAS which is at the core of RESTful-ness. It also mitigates the Mix-up attack without introducing the concept of issuer which is not in RFC6749. It is also good for selecting different endpoints depending on the user authentication and authorization results and more privacy sensitive than pre-announced Discovery document. It also allows you to find to which protected resource endpoint you can use the access token against. 
>  
> In the last sentence of the minutes, it talks about "a new document that describes additional discovery-relevant components". This is https://tools.ietf.org/html/draft-jones-oauth-discovery-00 <https://tools.ietf.org/html/draft-jones-oauth-discovery-00>.  It went for the call for adoption. However, it is only a half of the story. I believe https://tools.ietf.org/html/draft-sakimura-oauth-meta-05 <https://tools.ietf.org/html/draft-sakimura-oauth-meta-05> that was discussed at IETF 94 and had support there should be adopted as well. 
>  
> Nat Sakimura
>  
>  
>  
>  
> 2016年1月20日(水) 12:05 Nat Sakimura <[email-masked] <mailto:[email-masked]>>:
> Thanks Hannes. 
>  
> I did not find https://tools.ietf.org/html/draft-sakimura-oauth-meta-05 <https://tools.ietf.org/html/draft-sakimura-oauth-meta-05>, which was discussed in Yokohama, and was largely in agreement if my recollection is correct. Why is it not in the call for adoption? 
>  
>  
>  
> 2016年1月19日(火) 20:39 Hannes Tschofenig <[email-masked] <mailto:[email-masked]>>:
> Hi all,
> 
> http://www.ietf.org/mail-archive/web/oauth/current/msg15379.html <http://www.ietf.org/mail-archive/web/oauth/current/msg15379.html>) and
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>  
> 
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>  
> 
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>  
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

---

From: Nat Sakimura <[email-masked]>
Date: Thu, 21 Jan 2016 14:23:38 +0000

Mike,

You just criticize my draft. That's ok, but I would really like to get some
response to my questions stated in
https://www.ietf.org/mail-archive/web/oauth/current/msg15483.html . To me,
it just does not seem to work, and the combination of the oauth-meta and
PKCE seems to be much more elegan, nicer, and much simpler to implement. If
you just give up the dynamic response at the authorization endpoint, then
you even do not have to touch the code but just change a config file.

Please convince me by answering to my questions.

For the record of Yokohama, I do not recall much about duplication in OAuth
session. The poll in the room was 19 for / zero against / 4 persons need
more information. Indeed, it is not duplicating much. And if you move to a
new model without pre-configured discovery, it is not duplicating any but
the resource endpoint URI, which is optional and is for the cases where the
client did not know the concrete resource endpoint to start with.

I understand your usecases always start from a concrete endpoint location.
Mine do not. In a four party model, it is likely not. The user just want to
have the service to fetch his data from some resource endpoint. He just
hits the service. He does not hit the resource endpoint directly. For
example, in the case of a consumer using a personal finance platform
(PFP)to manage his pension fund, he hits the PFP and not the Pension fund.
Assuming that the pension fund has delegated the authorization control to
the authorization server, then, the authorization server should return both
the access token and the endpoint of the pension fund so that the PFP can
pull the data using them. A similar model holds for personal health service
and health care providers.

Best,

Nat

2016年1月21日(木) 21:18 Justin Richer <[email-masked]>:

> My memory of the discussions of the oauth-meta draft in Yokohama were that
> many people felt that it was unnecessarily dynamically duplicating a lot of
> information that the client already had.  Most of us that were aware of the
> attacks then were in favor of a more targeted, minimal approach.  You were
> listened to in Yokohama, but that didn’t necessarily mean that people
> agreed with the approach.  Participants were already aware of the
> oauth-meta proposal in Darmstadt but no one spoke up in favor of it that I
> can recall.  Rather, I think people were thinking that “less is more”.
>
>
>
> There have also been discussions in the last day about how dynamically
> returning a resource URL, which oauth-meta does, is both unnecessary (since
> the client initiated the resource authorization already knowing what
> resource it wants to access) and often problematic, since many
> authorization servers can authorize access to multiple resources.  If
> anything, the client should be telling the authorization server what
> resource it wants to access – not the other way around.
>
>
>
> I’m not saying that there aren’t some good ideas in the oauth-meta draft –
> I’m sure there are, just as there are in the approach designed by the
> participants in Darmstadt.  While I volunteered to write the first draft of
> the mix-up-mitigation approach, it really reflects something a lot of
> people have already bought into – as evidenced in the passion in the
> high-volume “Mix-Up About The Mix-Up Mitigation” thread, and not just my
> personal project.
>
>
>
> If you think there are things missing or wrong in the mix-up-mitigation
> draft, please say what they are.  That will help us quickly converge on a
> solution that will work for everyone.
>
>
>
>                                                           Sincerely,
>
>                                                           -- Mike
>
>
>
> *From:* Nat Sakimura [mailto:[email-masked] <[email-masked]>]
> *Sent:* Wednesday, January 20, 2016 11:17 PM
> *To:* Mike Jones <[email-masked]>; William Denniss <
> [email-masked]>; Justin Richer <[email-masked]>
> *Cc:* [email-masked]

---

From: Mike Jones <[email-masked]>
Date: Fri, 22 Jan 2016 01:34:40 +0000

Nat, I’m confused by this statement in the message you reference “Unfortunately, this does not match the value of OAuth issuer defined in Section 2 of draft-jones-oauth-mix-up-mitigation-01 nor the 'iss' returned as specified in 3.1. As such, validation as specified in bullet 1 of Section 4 fails in Google's case -- OR it means that the document is internally inconsistent.”.  The issuer definition in draft-jones-oauth-discovery is 100% compatible with the one in OpenID Connect Discovery, by design.  In the Google example, both the OpenID issuer and the OAuth issuer values would be the string “https://accounts.google.com”.  What is the inconsistency that you perceive?

The discussion of the duplication problem happened in the private meetings in Yokohama.

I will admit, in Yokohama, I didn’t speak up in the public meetings to point out that a simpler alternative to oauth-meta was already being discussed there in private, because then I would have had to talk about the security issues, which we’d decided not to publicly do at that point.  So I stayed silent during the poll, out of politeness.  Perhaps I should have found a way to say something then anyway, but that’s water under the bridge now.

Finally, for what it’s worth, the HATEOAS stuff reminds me far too much of Web Services Description Language (WSDL) – part of the complexity baggage that helped sink Web Services.  The use of “link rel” to define an interaction vocabulary and publish endpoints for that vocabulary seems pretty baroque and reminiscent of “microformats” – another cute “Webby” innovation that never caught on.  The industry has pretty much voted with its feet and is using JSON for publishing discovery data structures – not “link rel”.  I am against us reverting to the “link rel” proposal from 2008 that never caught on when JSON is simpler and does a better job.

                                                                -- Mike

From: Nat Sakimura [mailto:[email-masked]]
Sent: Thursday, January 21, 2016 6:24 AM
To: Justin Richer <[email-masked]>; Mike Jones <[email-masked]>
Cc: William Denniss <[email-masked]>; <[email-masked]> <[email-masked]>
Subject: Re: [OAUTH-WG] Call for Adoption

Mike,

You just criticize my draft. That's ok, but I would really like to get some response to my questions stated in https://www.ietf.org/mail-archive/web/oauth/current/msg15483.html . To me, it just does not seem to work, and the combination of the oauth-meta and PKCE seems to be much more elegan, nicer, and much simpler to implement. If you just give up the dynamic response at the authorization endpoint, then you even do not have to touch the code but just change a config file.

For the record of Yokohama, I do not recall much about duplication in OAuth session. The poll in the room was 19 for / zero against / 4 persons need more information. Indeed, it is not duplicating much. And if you move to a new model without pre-configured discovery, it is not duplicating any but the resource endpoint URI, which is optional and is for the cases where the client did not know the concrete resource endpoint to start with.

I understand your usecases always start from a concrete endpoint location. Mine do not. In a four party model, it is likely not. The user just want to have the service to fetch his data from some resource endpoint. He just hits the service. He does not hit the resource endpoint directly. For example, in the case of a consumer using a personal finance platform (PFP)to manage his pension fund, he hits the PFP and not the Pension fund. Assuming that the pension fund has delegated the authorization control to the authorization server, then, the authorization server should return both the access token and the endpoint of the pension fund so that the PFP can pull the data using them. A similar model holds for personal health service and health care providers.

Best,

Nat

2016年1月21日(木) 21:18 Justin Richer <[email-masked]<mailto:[email-masked]>>:
Convergence is exactly what I’m arguing for, though. These things ought to work together.

 — Justin

On Jan 21, 2016, at 2:55 AM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:

                                                          Sincerely,
                                                          -- Mike

To: Mike Jones <[email-masked]<mailto:[email-masked]>>; William Denniss <[email-masked]<mailto:[email-masked]>>; Justin Richer <[email-masked]<mailto:[email-masked]>>

Hi Mike.

Nat Sakimura

                                                          -- Mike

 -- Justin

    (f) Discovery (Nat)

Nat Sakimura

Ciao
Hannes & Derek

OAuth mailing list

---

From: Nat Sakimura <[email-masked]>
Date: Fri, 22 Jan 2016 02:07:56 +0000

Re: iss. I discussed this a bit with Nov in more details. It probably is a
sloppy language of the specs that is making it difficult to read what you
wanted to achieve.

In mix-up-mitigation draft, OAuth issuer is "the URL of the authorization
server's configuration information location". In OAuth discovery draft,
there is something called "OAuth 2.0 Configuration Information Location
URL", which is equal to "OpenID Connect Issuer".

When I wrote the statement, I thought you were pointing to the URL that you
can actually pull the configuration information by "the URL of the
authorizaiton server's configuration information location" since otherwise
you would have used the term "OAuth 2.0 Configuration Information Location
URL". But after all, you probably meant these two are the same. Then I
would strongly recommend to fix the language.

Now, even If that is the case, the relationship like

   - iss + .well-know/openid-configuration = Connect OP config endoint
   - OAuth config endpoint - .well-known/openid-configuration = OAuth iss

is very confusing.

You also claim that your approach is simpler, but to me, your approach seem
to be overly complex. It requires discovery and the check for the value of
the discovered config information to work as the mitigation. (Right. Draft
-01 does not have it, so it does not solve the mix-up issue.) With
oauth-meta, you do not need it.

Finally, your point that HATEOAS reminds you of WSDL, it is not. If you
want to have something similar to WSDL in REST API area, it is Swagger.
(Actually, it is gaining a lot of momentum recently, but that's beside the
fact ;-). And the point here is not the format but the fact that we need to
have a way to associate metadata to the data. The root cause of this mix-up
attack is that the metadata and data is not associated properly. We have a
standard way of associating the data and metadata with link-rel such as
RFC5988 so why not use it? Link-rel-href pattern is used a lot now. Most
modern web pages actually have it. Using a proper way to associate metadata
with data will save you from a lot of other attacks in the future. Instead
of doing patch works, we should solve it architecturally.

Nat

2016年1月22日(金) 10:34 Mike Jones <[email-masked]>:

> Nat, I’m confused by this statement in the message you reference “Unfortunately,
> this does not match the value of OAuth issuer defined in Section 2
> of draft-jones-oauth-mix-up-mitigation-01 nor the 'iss' returned as
> specified in 3.1. As such, validation as specified in bullet 1 of Section 4
> fails in Google's case -- OR it means that the document is internally
> inconsistent.”.  The issuer definition in draft-jones-oauth-discovery is
> 100% compatible with the one in OpenID Connect Discovery, by design.  In
> the Google example, both the OpenID issuer and the OAuth issuer values
> would be the string “https://accounts.google.com”.  What is the
> inconsistency that you perceive?
>
>
>
> I will admit, in Yokohama, I didn’t speak up in the public meetings to
> point out that a simpler alternative to oauth-meta was already being
> discussed there in private, because then I would have had to talk about the
> security issues, which we’d decided not to publicly do at that point.  So I
> stayed silent during the poll, out of politeness.  Perhaps I should have
> found a way to say something then anyway, but that’s water under the bridge
> now.
>
>
>
> Finally, for what it’s worth, the HATEOAS stuff reminds me far too much of
> Web Services Description Language (WSDL) – part of the complexity baggage
> that helped sink Web Services.  The use of “link rel” to define an
> interaction vocabulary and publish endpoints for that vocabulary seems
> pretty baroque and reminiscent of “microformats” – another cute “Webby”
> innovation that never caught on.  The industry has pretty much voted with
> its feet and is using JSON for publishing discovery data structures – not
> “link rel”.  I am against us reverting to the “link rel” proposal from 2008
> that never caught on when JSON is simpler and does a better job.
>
>
>
>                                                                 -- Mike
>
>
>
> *From:* Nat Sakimura [mailto:[email-masked]]
> *Sent:* Thursday, January 21, 2016 6:24 AM
> *To:* Justin Richer <[email-masked]>; Mike Jones <
> [email-masked]>
> *Cc:* William Denniss <[email-masked]>; <[email-masked]> <
> [email-masked]>
>
>
> You just criticize my draft. That's ok, but I would really like to get
> some response to my questions stated in
> https://www.ietf.org/mail-archive/web/oauth/current/msg15483.html . To
> me, it just does not seem to work, and the combination of the oauth-meta
> and PKCE seems to be much more elegan, nicer, and much simpler to
> implement. If you just give up the dynamic response at the authorization
> endpoint, then you even do not have to touch the code but just change a
> config file.
>
>
>
> For the record of Yokohama, I do not recall much about duplication in
> OAuth session. The poll in the room was 19 for / zero against / 4 persons
> need more information. Indeed, it is not duplicating much. And if you move
> to a new model without pre-configured discovery, it is not duplicating any
> but the resource endpoint URI, which is optional and is for the cases where
> the client did not know the concrete resource endpoint to start with.
>
>
>

---

From: William Denniss <[email-masked]>
Date: Fri, 22 Jan 2016 10:11:12 +0800

These params could also be part of the OAuth2 JSON response payload.
Perhaps we should evaluate the concept of incremental discovery and how
it's delivered separately?

Also, discovery does not solve the question of authorization-grant specific
RS endpoint metadata.

---

From: Nat Sakimura <[email-masked]>
Date: Fri, 22 Jan 2016 02:25:31 +0000

Right. OAuth-meta is not only for this particular attack. It actually
predates the attack by three years. It just happens to mitigate the attack
because it is addressing the root issue of decoupled data and meta-data
problem.

Re: returning as part of JSON payload, my earlier draft actually contained
a way to return the metadata within JSON (see
https://tools.ietf.org/html/draft-sakimura-oauth-meta-04). RFC5988 works as
long as we are using HTTPS, but once we get to other protocols, it does
not. So we need a way to represent it in native JSON. Swagger is using JSON
Schema way of it. I slightly prefer HAL way of it as you can leverage on
the JSON parser directly, making the code shorter, but I am fine either
way. I removed all those staff from OAuth-meta because that's not oauth
specific, but if people wants it, I can always bring it back.

Also, +1 for your point on "discovery does not solve the question of
authorization-grant specific RS endpoint metadata."

When I gave the idea back in 2012 in the work group meeting, a lot of
people said YES, but we needed complete other stuff and this thing has been
sitting there for 3 years now. IMHO, it should be adopted as a WG item now.
It will save a lot of headache down the road.

Nat

2016年1月22日(金) 11:11 William Denniss <[email-masked]>:

> Also, discovery does not solve the question of authorization-grant
> specific RS endpoint metadata.
>
>> Finally, for what it’s worth, the HATEOAS stuff reminds me far too much
>> of Web Services Description Language (WSDL) – part of the complexity
>> baggage that helped sink Web Services.  The use of “link rel” to define an
>> OAuth session. The poll in the room was 19 for / zero against / 4
>> persons need more information. Indeed, it is not duplicating much. And if
>> you move to a new model without pre-configured discovery, it is not
>> duplicating any but the resource endpoint URI, which is optional and is for
>> the cases where the client did not know the concrete resource endpoint to
>> start with.
>>
>>
>>
>> I understand your usecases always start from a concrete endpoint
>> location. Mine do not. In a four party model, it is likely not. The user
>> just want to have the service to fetch his data from some resource
>> endpoint. He just hits the service. He does not hit the resource endpoint
>> directly. For example, in the case of a consumer using a personal finance
>> platform (PFP)to manage his pension fund, he hits the PFP and not the
>> Pension fund. Assuming that the pension fund has delegated the
>> authorization control to the authorization server, then, the authorization
>> server should return both the access token and the endpoint of the pension
>> fund so that the PFP can pull the data using them. A similar model holds
>> for personal health service and health care providers.
>>
>>
>>
>> Best,
>>
>>
>>
>> Nat
>>
>>
>>
>>
>>
>> My memory of the discussions of the oauth-meta draft in Yokohama were
>> that many people felt that it was unnecessarily dynamically duplicating a
>> lot of information that the client already had.  Most of us that were aware
>> of the attacks then were in favor of a more targeted, minimal approach.
>> You were listened to in Yokohama, but that didn’t necessarily mean that
>> people agreed with the approach.  Participants were already aware of the
>> I’m not saying that there aren’t some good ideas in the oauth-meta draft
>> – I’m sure there are, just as there are in the approach designed by the
>> Conversely, I would like to ask why this approach does not work for
>> Mix-up attack. As Nov stated, we in fact have discussed the approach in
>> quite a length back in Yokohama. I really would like to know why it does
>> not work.
>>
>>
>>
>> The approach defined in draft-jones-oauth-mix-up-mitigation was created
>> in collaboration with the security researchers who identified the problems
>> in the first place, was vigorously discussed in the security meeting Hannes

---

From: Brian Campbell <[email-masked]>
Date: Fri, 22 Jan 2016 16:26:09 -0700

I agree that the language describing OAuth issuer could and should be
improved. The text now reads like it is the exact and full URL where the
metadata/discovery document is located. Perhaps something more like "the
URL from which the authorization server's configuration information
location can be derived" and explain that adding the .well-known bits to
the issuer is where the configuration information can actually be found.

On Thu, Jan 21, 2016 at 7:07 PM, Nat Sakimura <[email-masked]> wrote:

> When I wrote the statement, I thought you were pointing to the URL that
> you can actually pull the configuration information by "the URL of the
> You also claim that your approach is simpler, but to me, your approach
> seem to be overly complex. It requires discovery and the check for the
> value of the discovered config information to work as the mitigation.
> (Right. Draft -01 does not have it, so it does not solve the mix-up issue.)
> With oauth-meta, you do not need it.
>

---

From: Mike Jones <[email-masked]>
Date: Fri, 22 Jan 2016 23:32:39 +0000

I like the “from which the authorization server's configuration information location can be derived” language.  Thanks.  I’ll plan to incorporate that the next time the draft is revised.

                                                                -- Mike

From: Brian Campbell [mailto:[email-masked]]
Sent: Friday, January 22, 2016 3:26 PM
To: Nat Sakimura <[email-masked]>
Cc: Mike Jones <[email-masked]>; Justin Richer <[email-masked]>; <[email-masked]> <[email-masked]>
Subject: Re: [OAUTH-WG] Call for Adoption

I agree that the language describing OAuth issuer could and should be improved. The text now reads like it is the exact and full URL where the metadata/discovery document is located. Perhaps something more like "the URL from which the authorization server's configuration information location can be derived" and explain that adding the .well-known bits to the issuer is where the configuration information can actually be found.

On Thu, Jan 21, 2016 at 7:07 PM, Nat Sakimura <[email-masked]<mailto:[email-masked]>> wrote:
Re: iss. I discussed this a bit with Nov in more details. It probably is a sloppy language of the specs that is making it difficult to read what you wanted to achieve.

In mix-up-mitigation draft, OAuth issuer is "the URL of the authorization server's configuration information location". In OAuth discovery draft, there is something called "OAuth 2.0 Configuration Information Location URL", which is equal to "OpenID Connect Issuer".

When I wrote the statement, I thought you were pointing to the URL that you can actually pull the configuration information by "the URL of the authorizaiton server's configuration information location" since otherwise you would have used the term "OAuth 2.0 Configuration Information Location URL". But after all, you probably meant these two are the same. Then I would strongly recommend to fix the language.

Now, even If that is the case, the relationship like
·         iss + .well-know/openid-configuration = Connect OP config endoint
·         OAuth config endpoint - .well-known/openid-configuration = OAuth iss
is very confusing.

You also claim that your approach is simpler, but to me, your approach seem to be overly complex. It requires discovery and the check for the value of the discovered config information to work as the mitigation. (Right. Draft -01 does not have it, so it does not solve the mix-up issue.) With oauth-meta, you do not need it.

Finally, your point that HATEOAS reminds you of WSDL, it is not. If you want to have something similar to WSDL in REST API area, it is Swagger. (Actually, it is gaining a lot of momentum recently, but that's beside the fact ;-). And the point here is not the format but the fact that we need to have a way to associate metadata to the data. The root cause of this mix-up attack is that the metadata and data is not associated properly. We have a standard way of associating the data and metadata with link-rel such as RFC5988 so why not use it? Link-rel-href pattern is used a lot now. Most modern web pages actually have it. Using a proper way to associate metadata with data will save you from a lot of other attacks in the future. Instead of doing patch works, we should solve it architecturally.

Nat

2016年1月22日(金) 10:34 Mike Jones <[email-masked]<mailto:[email-masked]>>:
Nat, I’m confused by this statement in the message you reference “Unfortunately, this does not match the value of OAuth issuer defined in Section 2 of draft-jones-oauth-mix-up-mitigation-01 nor the 'iss' returned as specified in 3.1. As such, validation as specified in bullet 1 of Section 4 fails in Google's case -- OR it means that the document is internally inconsistent.”.  The issuer definition in draft-jones-oauth-discovery is 100% compatible with the one in OpenID Connect Discovery, by design.  In the Google example, both the OpenID issuer and the OAuth issuer values would be the string “https://accounts.google.com”.  What is the inconsistency that you perceive?

                                                                -- Mike

From: Nat Sakimura [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, January 21, 2016 6:24 AM
To: Justin Richer <[email-masked]<mailto:[email-masked]>>; Mike Jones <[email-masked]<mailto:[email-masked]>>
Cc: William Denniss <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>

Mike,

Best,

Nat

 — Justin

                                                          Sincerely,
                                                          -- Mike

Hi Mike.

Nat Sakimura

                                                          -- Mike

 -- Justin

    (f) Discovery (Nat)

Nat Sakimura

Ciao
Hannes & Derek

OAuth mailing list

---

From: Nat Sakimura <[email-masked]>
Date: Sat, 23 Jan 2016 01:29:08 +0000

I wrote a blog on why the current mix-up draft approach does not solve the
issue.

http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-rfc6749/

Hopefully, the point I am making is clearer by this.

Best,

Nat

2016年1月23日(土) 8:32 Mike Jones <[email-masked]>:

> I like the “from which the authorization server's configuration
> information location can be derived” language.  Thanks.  I’ll plan to
> incorporate that the next time the draft is revised.
>
>
>
>                                                                 -- Mike
>
>
>
> *From:* Brian Campbell [mailto:[email-masked]]
> *Sent:* Friday, January 22, 2016 3:26 PM
> *To:* Nat Sakimura <[email-masked]>
> *Cc:* Mike Jones <[email-masked]>; Justin Richer <
> [email-masked]>; <[email-masked]> <[email-masked]>
>
>

---

From: Brian Campbell <[email-masked]>
Date: Tue, 26 Jan 2016 06:37:55 -0700

I'm not sure what's described in the blog post is actually a variant of an
attack that anyone is really concerned about? A client developer would have
to change a production system to use an unfamiliar value for the token
endpoint based solely on a an email without even looking at service
documentation or metadata.

On Fri, Jan 22, 2016 at 6:29 PM, Nat Sakimura <[email-masked]> wrote:

>> Re: iss. I discussed this a bit with Nov in more details. It probably is
>> a sloppy language of the specs that is making it difficult to read what you
>> wanted to achieve.
>>
>>
>>

---

From: George Fletcher <[email-masked]>
Date: Tue, 26 Jan 2016 10:21:19 -0500

While it's a different way of getting the endpoints mixed up, I don't 
think that makes it invalid. If we are going to address the attack 
vector I believe we should solve it for "all" cases not just the ones 
that seem most likely.

Thanks,
George

On 1/26/16 8:37 AM, Brian Campbell wrote:
> I'm not sure what's described in the blog post is actually a variant 
> of an attack that anyone is really concerned about? A client developer 
> would have to change a production system to use an unfamiliar value 
> for the token endpoint based solely on a an email without even looking 
> at service documentation or metadata.
>
>
> On Fri, Jan 22, 2016 at 6:29 PM, Nat Sakimura <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     I wrote a blog on why the current mix-up draft approach does not
>     solve the issue.
>
>     2016年1月23日(土) 8:32 Mike Jones <[email-masked]
>     <mailto:[email-masked]>>:
>
>         I like the “from which the authorization server's
>         configuration information location can be derived” language. 
>         Thanks.  I’ll plan to incorporate that the next time the draft
>         is revised.
>
>         -- Mike
>
>         *From:*Brian Campbell [mailto:[email-masked]
>         <mailto:[email-masked]>]
>         *To:* Nat Sakimura <[email-masked]
>         <mailto:[email-masked]>>
>         *Cc:* Mike Jones <[email-masked]
>         <mailto:[email-masked]>>; Justin Richer
>         <[email-masked] <mailto:[email-masked]>>; <[email-masked]
>         <mailto:[email-masked]>> <[email-masked] <mailto:[email-masked]>>
>
>
>         I agree that the language describing OAuth issuer could and
>         should be improved. The text now reads like it is the exact
>         and full URL where the metadata/discovery document is located.
>         Perhaps something more like "the URL from which the
>         authorization server's configuration information location can
>         be derived" and explain that adding the .well-known bits to
>         On Thu, Jan 21, 2016 at 7:07 PM, Nat Sakimura
>         <[email-masked] <mailto:[email-masked]>> wrote:
>
>             Re: iss. I discussed this a bit with Nov in more details.
>             It probably is a sloppy language of the specs that is
>             making it difficult to read what you wanted to achieve.
>
>             In mix-up-mitigation draft, OAuth issuer is "the URL of
>             the authorization server's configuration information
>             location". In OAuth discovery draft, there is something
>             called "OAuth 2.0 Configuration Information Location URL",
>             which is equal to "OpenID Connect Issuer".
>
>             When I wrote the statement, I thought you were pointing to
>             the URL that you can actually pull the configuration
>             information by "the URL of the authorizaiton server's
>             configuration information location" since otherwise you
>             would have used the term "OAuth 2.0 Configuration
>             Information Location URL". But after all, you probably
>             meant these two are the same. Then I would strongly
>             recommend to fix the language.
>
>             ·iss + .well-know/openid-configuration = Connect OP config
>             endoint
>
>             ·OAuth config endpoint - .well-known/openid-configuration
>             = OAuth iss
>
>             is very confusing.
>
>             You also claim that your approach is simpler, but to me,
>             your approach seem to be overly complex. It requires
>             discovery and the check for the value of the discovered
>             config information to work as the mitigation. (Right.
>             Draft -01 does not have it, so it does not solve the
>             mix-up issue.) With oauth-meta, you do not need it.
>
>             Finally, your point that HATEOAS reminds you of WSDL, it
>             is not. If you want to have something similar to WSDL in
>             REST API area, it is Swagger. (Actually, it is gaining a
>             lot of momentum recently, but that's beside the fact ;-).
>             And the point here is not the format but the fact that we
>             need to have a way to associate metadata to the data. The
>             root cause of this mix-up attack is that the metadata and
>             data is not associated properly. We have a standard way of
>             associating the data and metadata with link-rel such as
>             RFC5988 so why not use it? Link-rel-href pattern is used a
>             lot now. Most modern web pages actually have it. Using a
>             proper way to associate metadata with data will save you
>             from a lot of other attacks in the future. Instead of
>             doing patch works, we should solve it architecturally.
>
>             Nat
>
>             2016年1月22日(金) 10:34 Mike Jones
>             <[email-masked]
>             <mailto:[email-masked]>>:
>
>                 Nat, I’m confused by this statement in the message you
>                 reference “Unfortunately, this does not match the
>                 value of OAuth issuer defined in Section 2
>                 of draft-jones-oauth-mix-up-mitigation-01 nor the
>                 'iss' returned as specified in 3.1. As such,
>                 validation as specified in bullet 1 of Section 4 fails
>                 in Google's case -- OR it means that the document is
>                 internally inconsistent.”. The issuer definition in
>                 draft-jones-oauth-discovery is 100% compatible with
>                 the one in OpenID Connect Discovery, by design.  In
>                 the Google example, both the OpenID issuer and the
>                 OAuth issuer values would be the string
>                 “https://accounts.google.com”. What is the
>                 I will admit, in Yokohama, I didn’t speak up in the
>                 public meetings to point out that a simpler
>                 alternative to oauth-meta was already being discussed
>                 there in private, because then I would have had to
>                 talk about the security issues, which we’d decided not
>                 to publicly do at that point.  So I stayed silent
>                 during the poll, out of politeness.  Perhaps I should
>                 have found a way to say something then anyway, but
>                 that’s water under the bridge now.
>
>                 Finally, for what it’s worth, the HATEOAS stuff
>                 reminds me far too much of Web Services Description
>                 Language (WSDL) – part of the complexity baggage that
>                 helped sink Web Services.  The use of “link rel” to
>                 define an interaction vocabulary and publish endpoints
>                 for that vocabulary seems pretty baroque and
>                 reminiscent of “microformats” – another cute “Webby”
>                 innovation that never caught on.  The industry has
>                 pretty much voted with its feet and is using JSON for
>                 publishing discovery data structures – not “link
>                 rel”.  I am against us reverting to the “link rel”
>                 proposal from 2008 that never caught on when JSON is
>                 simpler and does a better job.
>
>                 -- Mike
>
>                 *From:*Nat Sakimura [mailto:[email-masked]
>                 <mailto:[email-masked]>]
>                 *To:* Justin Richer <[email-masked]
>                 <mailto:[email-masked]>>; Mike Jones
>                 <[email-masked]
>                 <mailto:[email-masked]>>
>                 *Cc:* William Denniss <[email-masked]
>                 <mailto:[email-masked]>>; <[email-masked]
>                 <mailto:[email-masked]>> <[email-masked]
>                 <mailto:[email-masked]>>
>
>
>                 You just criticize my draft. That's ok, but I would
>                 really like to get some response to my questions
>                 stated in
>                 https://www.ietf.org/mail-archive/web/oauth/current/msg15483.html .
>                 To me, it just does not seem to work, and the
>                 combination of the oauth-meta and PKCE seems to be
>                 much more elegan, nicer, and much simpler to
>                 implement. If you just give up the dynamic response at
>                 the authorization endpoint, then you even do not have
>                 to touch the code but just change a config file.
>
>                 For the record of Yokohama, I do not recall much about
>                 duplication in OAuth session. The poll in the room was
>                 19 for / zero against / 4 persons need more
>                 information. Indeed, it is not duplicating much. And
>                 if you move to a new model without pre-configured
>                 discovery, it is not duplicating any but the resource
>                 endpoint URI, which is optional and is for the cases
>                 where the client did not know the concrete resource
>                 endpoint to start with.
>
>                 I understand your usecases always start from a
>                 concrete endpoint location. Mine do not. In a four
>                 party model, it is likely not. The user just want to
>                 have the service to fetch his data from some resource
>                 endpoint. He just hits the service. He does not hit
>                 the resource endpoint directly. For example, in the
>                 case of a consumer using a personal finance platform
>                 (PFP)to manage his pension fund, he hits the PFP and
>                 not the Pension fund. Assuming that the pension fund
>                 has delegated the authorization control to the
>                 authorization server, then, the authorization server
>                 should return both the access token and the endpoint
>                 of the pension fund so that the PFP can pull the data
>                 using them. A similar model holds for personal health
>                 service and health care providers.
>
>                 Best,
>
>                 Nat
>
>                     Convergence is exactly what I’m arguing for,
>                     though. These things ought to work together.
>
>                      — Justin
>
>                         On Jan 21, 2016, at 2:55 AM, Mike Jones
>                         <[email-masked]
>                         <mailto:[email-masked]>> wrote:
>
>                         My memory of the discussions of the oauth-meta
>                         draft in Yokohama were that many people felt
>                         that it was unnecessarily dynamically
>                         duplicating a lot of information that the
>                         client already had.  Most of us that were
>                         aware of the attacks then were in favor of a
>                         more targeted, minimal approach.  You were
>                         listened to in Yokohama, but that didn’t
>                         necessarily mean that people agreed with the
>                         approach. Participants were already aware of
>                         the oauth-meta proposal in Darmstadt but no
>                         one spoke up in favor of it that I can recall.
>                         Rather, I think people were thinking that
>                         “less is more”.
>
>                         There have also been discussions in the last
>                         day about how dynamically returning a resource
>                         URL, which oauth-meta does, is both
>                         unnecessary (since the client initiated the
>                         resource authorization already knowing what
>                         resource it wants to access) and often
>                         problematic, since many authorization servers
>                         can authorize access to multiple resources. 
>                         If anything, the client should be telling the
>                         authorization server what resource it wants to
>                         access – not the other way around.
>
>                         I’m not saying that there aren’t some good
>                         ideas in the oauth-meta draft – I’m sure there
>                         are, just as there are in the approach
>                         designed by the participants in Darmstadt.
>                         While I volunteered to write the first draft
>                         of the mix-up-mitigation approach, it really
>                         reflects something a lot of people have
>                         already bought into – as evidenced in the
>                         passion in the high-volume “Mix-Up About The
>                         Mix-Up Mitigation” thread, and not just my
>                         personal project.
>
>                         If you think there are things missing or wrong
>                         in the mix-up-mitigation draft, please say
>                         what they are.  That will help us quickly
>                         converge on a solution that will work for
>                         everyone.
>
>                         Sincerely,
>
>                         -- Mike
>
>                         *From:*Nat Sakimura [mailto:[email-masked]]
>                         *To:* Mike Jones <[email-masked]
>                         <mailto:[email-masked]>>; William
>                         Denniss <[email-masked]
>                         <mailto:[email-masked]>>; Justin Richer
>                         <[email-masked] <mailto:[email-masked]>>
>                         *Cc:* [email-masked] <mailto:[email-masked]>
>                         Conversely, I would like to ask why this
>                         approach does not work for Mix-up attack. As
>                         Nov stated, we in fact have discussed the
>                         approach in quite a length back in Yokohama. I
>                         really would like to know why it does not work.
>
>                         Besides, for oauth-meta approach, mix-up
>                         attack is only one of the thing it solves.
>
>                         Nat Sakimura
>
>                         2016年1月21日(木) 16:02 Mike Jones
>                         <[email-masked]
>                         <mailto:[email-masked]>>:
>
>                             Not to be negative, but I disagree with
>                             adopting draft-sakimura-oauth-meta. We
>                             should define and promote one mitigation
>                             approach to the mix-up attacks. Having two
>                             would confuse implementers and cause
>                             compatibility problems – reducing overall
>                             security.
>
>                             The approach defined in
>                             draft-jones-oauth-mix-up-mitigation was
>                             created in collaboration with the security
>                             researchers who identified the problems in
>                             the first place, was vigorously discussed
>                             in the security meeting Hannes and Torsten
>                             held in Darmstadt, and has been since
>                             refined based on substantial input from
>                             the working group.  And at least three
>                             implementers have already stated that
>                             they’ve implemented it.  I’m not saying
>                             that it’s, but if there are things missing
>                             or things that need to be improved in our
>                             Also, standard OAuth deployments register
>                             the client and then use the information
>                             gathered at registration time for
>                             subsequent protocol interactions. They do
>                             not need all the configuration information
>                             for the authorization server to be
>                             retransmitted at runtime. The oauth-meta
>                             draft goes too far in that direction, at
>                             least as I see it.  Returning things two
>                             Attacks security considerations section
>                             (7.2) of the mix-up-mitigation draft.
>
>                             practice in both static and dynamic
>                             metadata discovery. Replying to Justin’s
>                             comment that “It's the pre-configured
>                             discovery document that's at the root of
>                             the mix-up attack in the first place” –
>                             this is not the case.  The attacks can be
>                             performed without either discovery or
>                             dynamic registration.
>
>                             I would be interested in hearing a
>                             technical discussion on whether there are
>                             aspects of the oauth-meta approach that
>                             mitigate aspects of the attacks that the
>                             mix-up-mitigation approach does not.  That
>                             could help inform whether there are
>                             additional things we should add to or
>                             change in the mix-up draft.
>
>                             -- Mike
>
>                             *From:*OAuth
>                             [mailto:[email-masked]
>                             <mailto:[email-masked]>] *On
>                             Behalf Of *William Denniss
>                             *To:* Justin Richer <[email-masked]
>                             <mailto:[email-masked]>>
>                             *Cc:* [email-masked] <mailto:[email-masked]>
>                             On Wed, Jan 20, 2016 at 9:53 PM, Justin
>                             Richer <[email-masked]
>                             <mailto:[email-masked]>> wrote:
>
>                                 +1
>
>                                                  Nat explains his
>                                     document as an example of the work
>                                     that has to be done
>
>                                                  in the area of
>                                     discovery, which is a topic that
>                                     has been identified
>
>                                                  as necessary for
>                                     interoperability since many years
>                                     but so far there
>
>                                                  was not time to work
>                                     on it. Mike, John and Nat are
>                                     working on a new
>
>                                                  document that
>                                     describes additional
>                                     discovery-relevant components.
>
>                                                  Poll: 19 for / zero
>                                     against / 4 persons need more
>                                     information.
>
>                                     https://tools.ietf.org/html/draft-sakimura-oauth-meta-05.
>                                     This is a simple (only 1-page!)
>                                     but a very powerful document that
>                                     nudges towards HATEOAS which is at
>                                     the core of RESTful-ness. It also
>                                     mitigates the Mix-up attack
>                                     without introducing the concept of
>                                     issuer which is not in RFC6749. It
>                                     is also good for selecting
>                                     different endpoints depending on
>                                     the user authentication and
>                                     authorization results and more
>                                     privacy sensitive than
>                                     pre-announced Discovery document.
>                                     It also allows you to find to
>                                     which protected resource endpoint
>                                     you can use the access token against.
>
>                                     In the last sentence of the
>                                     minutes, it talks about "a new
>                                     document that describes additional
>                                     discovery-relevant components".
>                                     This is
>                                     https://tools.ietf.org/html/draft-jones-oauth-discovery-00.
>                                     It went for the call for adoption.
>                                     However, it is only a half of the
>                                     story. I believe
>                                     https://tools.ietf.org/html/draft-sakimura-oauth-meta-05 that
>                                     was discussed at IETF 94 and had
>                                     support there should be adopted as
>                                     well.
>
>                                     Nat Sakimura
>
>                                     2016年1月20日(水) 12:05 Nat
>                                         recollection is correct. Why
>                                         is it not in the call for
>                                         adoption?
>
>                                             since some IESG members
>                                             like to see an updated
>                                             list of milestones as
>                                             well. For this reason,
>                                             based on a suggestion from
>                                             Barry, we are also
>                                             starting a call for
>                                             adoption concurrently with
>                                             the review of the charter
>                                             text by the IESG.
>
>                                             We will post separate
>                                             mails on the individual
>                                             documents. Your feedback
>                                             is important! Please take
>                                             the time to look at the
>                                             documents and provide
>                                             your feedback.
>
>                                             Ciao
>                                             Hannes & Derek
>
>                                             <mailto:[email-masked]>

---

From: Brian Campbell <[email-masked]>
Date: Tue, 26 Jan 2016 11:58:30 -0700

I'm staying that it's sufficiently unlikely that it shouldn't be part of
the threat model and that a discovery lookup on iss isn't necessary.

On Tue, Jan 26, 2016 at 8:21 AM, George Fletcher <[email-masked]> wrote:

> think that makes it invalid. If we are going to address the attack vector I
> believe we should solve it for "all" cases not just the ones that seem most
> likely.
>
> Thanks,
> George
>
>> I wrote a blog on why the current mix-up draft approach does not solve
>> the issue.
>>
>>
>> 2016年1月23日(土) 8:32 Mike Jones < <[email-masked]>
>> [email-masked]>:
>>
>>> *From:* Brian Campbell [mailto: <[email-masked]>
>>> [email-masked]]
>>> *To:* Nat Sakimura < <[email-masked]>[email-masked]>
>>> *Cc:* Mike Jones < <[email-masked]>
>>> [email-masked]>; Justin Richer <[email-masked]>; <
>>> [email-masked]> <[email-masked]>
>>>
>>>
>>> On Thu, Jan 21, 2016 at 7:07 PM, Nat Sakimura < <[email-masked]>
>>> [email-masked]> wrote:
>>>
>>> In mix-up-mitigation draft, OAuth issuer is "the URL of the
>>> authorization server's configuration information location". In OAuth
>>> discovery draft, there is something called "OAuth 2.0 Configuration
>>> Information Location URL", which is equal to "OpenID Connect Issuer".
>>>
>>> 2016年1月22日(金) 10:34 Mike Jones < <[email-masked]>
>>> [email-masked]>:
>>>
>>> inconsistent.”.  The issuer definition in draft-jones-oauth-discovery
>>> is 100% compatible with the one in OpenID Connect Discovery, by design.  In
>>> would be the string “ <https://accounts.google.com>
>>> https://accounts.google.com”.  What is the inconsistency that you
>>> perceive?
>>>
>>>
>>>
>>> *From:* Nat Sakimura [mailto: <[email-masked]>[email-masked]]
>>> *To:* Justin Richer < <[email-masked]>[email-masked]>; Mike Jones <
>>> <[email-masked]>[email-masked]>
>>> *Cc:* William Denniss < <[email-masked]>[email-masked]>; <
>>> <[email-masked]>[email-masked]> < <[email-masked]>[email-masked]>
>>>
>>>
>>> <https://www.ietf.org/mail-archive/web/oauth/current/msg15483.html>
>>> 2016年1月21日(木) 21:18 Justin Richer < <[email-masked]>[email-masked]>:
>>>
>>> On Jan 21, 2016, at 2:55 AM, Mike Jones < <[email-masked]>
>>> [email-masked]> wrote:
>>>
>>>
>>>
>>> *From:* Nat Sakimura [ <[email-masked]>mailto:[email-masked]
>>> <[email-masked]>]
>>> *To:* Mike Jones < <[email-masked]>
>>> [email-masked]>; William Denniss < <[email-masked]>
>>> [email-masked]>; Justin Richer < <[email-masked]>[email-masked]>
>>> *Cc:* <[email-masked]>[email-masked]
>>> 2016年1月21日(木) 16:02 Mike Jones < <[email-masked]>
>>> [email-masked]>:
>>>
>>> I’ll note that the mix-up-mitigation approach is compatible with
>>> existing practice in both static and dynamic metadata discovery.  Replying
>>> to Justin’s comment that “It's the pre-configured discovery document
>>> that's at the root of the mix-up attack in the first place” – this is
>>> not the case.  The attacks can be performed without either discovery or
>>> dynamic registration.
>>>
>>>
>>>
>>> *From:* OAuth [mailto: <[email-masked]>[email-masked]] *On
>>> *To:* Justin Richer < <[email-masked]>[email-masked]>
>>> *Cc:* <[email-masked]>[email-masked]
>>> On Wed, Jan 20, 2016 at 9:53 PM, Justin Richer < <[email-masked]>
>>> [email-masked]> wrote:
>>>
>>> +1
>>>
>>> <https://tools.ietf.org/html/draft-jones-oauth-discovery-00>
>>> believe  <https://tools.ietf.org/html/draft-sakimura-oauth-meta-05>
>>> 2016年1月20日(水) 12:05 Nat Sakimura < <[email-masked]>
>>> [email-masked]>:
>>>
>>> Thanks Hannes.
>>>
>>>
>>>
>>> I did not find
>>> https://tools.ietf.org/html/draft-sakimura-oauth-meta-05, which was
>>> discussed in Yokohama, and was largely in agreement if my recollection is
>>> correct. Why is it not in the call for adoption?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> <http://www.ietf.org/mail-archive/web/oauth/current/msg15379.html>
>>> <[email-masked]>[email-masked]
>>> <https://www.ietf.org/mailman/listinfo/oauth>
>>> <[email-masked]>[email-masked]
>>> <https://www.ietf.org/mailman/listinfo/oauth>
>>> <[email-masked]>[email-masked]
>>> <https://www.ietf.org/mailman/listinfo/oauth>

---

From: George Fletcher <[email-masked]>
Date: Tue, 26 Jan 2016 14:07:20 -0500

So I'm fine with not requiring discovery in the simple case of an RS 
supporting a single AS. However, once the RS moves to supporting 
multiple authorization servers then I believe that discovery based on 
the 'iss' string is required. The discovery results can be cached so a 
discovery lookup per transaction is not required.

Thanks,
George

On 1/26/16 1:58 PM, Brian Campbell wrote:
> I'm staying that it's sufficiently unlikely that it shouldn't be part 
> of the threat model and that a discovery lookup on iss isn't necessary.
>
>
>
> On Tue, Jan 26, 2016 at 8:21 AM, George Fletcher <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     While it's a different way of getting the endpoints mixed up, I
>     don't think that makes it invalid. If we are going to address the
>     attack vector I believe we should solve it for "all" cases not
>     just the ones that seem most likely.
>
>     Thanks,
>     George
>
>>     I'm not sure what's described in the blog post is actually a
>>     variant of an attack that anyone is really concerned about? A
>>     client developer would have to change a production system to use
>>     an unfamiliar value for the token endpoint based solely on a an
>>     email without even looking at service documentation or metadata.
>>
>>
>>         I wrote a blog on why the current mix-up draft approach does
>>         not solve the issue.
>>
>>             configuration information location can be derived”
>>             language.  Thanks.  I’ll plan to incorporate that the
>>             next time the draft is revised.
>>
>>             -- Mike
>>
>>             <[email-masked] <mailto:[email-masked]>>;
>>             <[email-masked] <mailto:[email-masked]>> <[email-masked]
>>             <mailto:[email-masked]>>
>>
>>
>>             I agree that the language describing OAuth issuer could
>>             and should be improved. The text now reads like it is the
>>             exact and full URL where the metadata/discovery document
>>             is located. Perhaps something more like "the URL from
>>             which the authorization server's configuration
>>             information location can be derived" and explain that
>>             adding the .well-known bits to the issuer is where the
>>             configuration information can actually be found.
>>
>>                 Re: iss. I discussed this a bit with Nov in more
>>                 details. It probably is a sloppy language of the
>>                 specs that is making it difficult to read what you
>>                 wanted to achieve.
>>
>>                 In mix-up-mitigation draft, OAuth issuer is "the URL
>>                 of the authorization server's configuration
>>                 information location". In OAuth discovery draft,
>>                 there is something called "OAuth 2.0 Configuration
>>                 When I wrote the statement, I thought you were
>>                 pointing to the URL that you can actually pull the
>>                 configuration information by "the URL of the
>>                 authorizaiton server's configuration information
>>                 location" since otherwise you would have used the
>>                 term "OAuth 2.0 Configuration Information Location
>>                 URL". But after all, you probably meant these two are
>>                 the same. Then I would strongly recommend to fix the
>>                 language.
>>
>>                 ·iss + .well-know/openid-configuration = Connect OP
>>                 config endoint
>>
>>                 ·OAuth config endpoint -
>>                 .well-known/openid-configuration = OAuth iss
>>
>>                 is very confusing.
>>
>>                 You also claim that your approach is simpler, but to
>>                 me, your approach seem to be overly complex. It
>>                 requires discovery and the check for the value of the
>>                 discovered config information to work as the
>>                 mitigation. (Right. Draft -01 does not have it, so it
>>                 does not solve the mix-up issue.) With oauth-meta,
>>                 you do not need it.
>>
>>                 Finally, your point that HATEOAS reminds you of WSDL,
>>                 it is not. If you want to have something similar to
>>                 WSDL in REST API area, it is Swagger. (Actually, it
>>                 is gaining a lot of momentum recently, but that's
>>                 beside the fact ;-). And the point here is not the
>>                 format but the fact that we need to have a way to
>>                 associate metadata to the data. The root cause of
>>                 this mix-up attack is that the metadata and data is
>>                 not associated properly. We have a standard way of
>>                 associating the data and metadata with link-rel such
>>                 as RFC5988 so why not use it? Link-rel-href pattern
>>                 is used a lot now. Most modern web pages actually
>>                 have it. Using a proper way to associate metadata
>>                 with data will save you from a lot of other attacks
>>                 in the future. Instead of doing patch works, we
>>                 should solve it architecturally.
>>
>>                 Nat
>>
>>                     Nat, I’m confused by this statement in the
>>                     message you reference “Unfortunately, this does
>>                     not match the value of OAuth issuer defined in
>>                     Section 2
>>                     validation as specified in bullet 1 of Section 4
>>                     fails in Google's case -- OR it means that the
>>                     document is internally inconsistent.”. The issuer
>>                     definition in draft-jones-oauth-discovery is 100%
>>                     compatible with the one in OpenID Connect
>>                     Discovery, by design.  In the Google example,
>>                     both the OpenID issuer and the OAuth issuer
>>                     values would be the string
>>                     The discussion of the duplication problem
>>                     happened in the private meetings in Yokohama.
>>
>>                     I will admit, in Yokohama, I didn’t speak up in
>>                     the public meetings to point out that a simpler
>>                     alternative to oauth-meta was already being
>>                     discussed there in private, because then I would
>>                     have had to talk about the security issues, which
>>                     we’d decided not to publicly do at that point. So
>>                     I stayed silent during the poll, out of
>>                     politeness. Perhaps I should have found a way to
>>                     say something then anyway, but that’s water under
>>                     the bridge now.
>>
>>                     reminds me far too much of Web Services
>>                     Description Language (WSDL) – part of the
>>                     complexity baggage that helped sink Web
>>                     Services.  The use of “link rel” to define an
>>                     interaction vocabulary and publish endpoints for
>>                     that vocabulary seems pretty baroque and
>>                     reminiscent of “microformats” – another cute
>>                     “Webby” innovation that never caught on.  The
>>                     industry has pretty much voted with its feet and
>>                     is using JSON for publishing discovery data
>>                     structures – not “link rel”.  I am against us
>>                     reverting to the “link rel” proposal from 2008
>>                     You just criticize my draft. That's ok, but I
>>                     would really like to get some response to my
>>                     questions stated in
>>                     combination of the oauth-meta and PKCE seems to
>>                     be much more elegan, nicer, and much simpler to
>>                     implement. If you just give up the dynamic
>>                     response at the authorization endpoint, then you
>>                     even do not have to touch the code but just
>>                     change a config file.
>>
>>                     For the record of Yokohama, I do not recall much
>>                     about duplication in OAuth session. The poll in
>>                     the room was 19 for / zero against / 4 persons
>>                     need more information. Indeed, it is not
>>                     duplicating much. And if you move to a new model
>>                     without pre-configured discovery, it is not
>>                     duplicating any but the resource endpoint URI,
>>                     which is optional and is for the cases where the
>>                     concrete endpoint location. Mine do not. In a
>>                     four party model, it is likely not. The user just
>>                     want to have the service to fetch his data from
>>                     some resource endpoint. He just hits the service.
>>                     He does not hit the resource endpoint directly.
>>                     For example, in the case of a consumer using a
>>                     personal finance platform (PFP)to manage his
>>                     pension fund, he hits the PFP and not the Pension
>>                     fund. Assuming that the pension fund has
>>                     delegated the authorization control to the
>>                     authorization server, then, the authorization
>>                     server should return both the access token and
>>                     the endpoint of the pension fund so that the PFP
>>                     can pull the data using them. A similar model
>>                     holds for personal health service and health care
>>                     providers.
>>
>>                     Best,
>>
>>                     Nat
>>
>>                     2016年1月21日(木) 21:18 Justin Richer
>>                     <[email-masked] <mailto:[email-masked]>>:
>>
>>                             many people felt that it was
>>                             unnecessarily dynamically duplicating a
>>                             of the attacks then were in favor of a
>>                             more targeted, minimal approach.  You
>>                             were listened to in Yokohama, but that
>>                             didn’t necessarily mean that people
>>                             agreed with the approach. Participants
>>                             were already aware of the oauth-meta
>>                             proposal in Darmstadt but no one spoke up
>>                             in favor of it that I can recall. Rather,
>>                             I think people were thinking that “less
>>                             is more”.
>>
>>                             There have also been discussions in the
>>                             last day about how dynamically returning
>>                             a resource URL, which oauth-meta does, is
>>                             both unnecessary (since the client
>>                             initiated the resource authorization
>>                             already knowing what resource it wants to
>>                             access) and often problematic, since many
>>                             anything, the client should be telling
>>                             the authorization server what resource it
>>                             wants to access – not the other way around.
>>
>>                             I’m not saying that there aren’t some
>>                             good ideas in the oauth-meta draft – I’m
>>                             sure there are, just as there are in the
>>                             approach designed by the participants in
>>                             Darmstadt. While I volunteered to write
>>                             the first draft of the mix-up-mitigation
>>                             approach, it really reflects something a
>>                             lot of people have already bought into –
>>                             as evidenced in the passion in the
>>                             If you think there are things missing or
>>                             wrong in the mix-up-mitigation draft,
>>                             please say what they are.  That will help
>>                             us quickly converge on a solution that
>>                             will work for everyone.
>>
>>                             Sincerely,
>>
>>                             -- Mike
>>
>>                             *From:*Nat Sakimura
>>                             <mailto:[email-masked]>>;
>>                             William Denniss <[email-masked]
>>                             <mailto:[email-masked]>>; Justin
>>                             Richer <[email-masked]
>>                             approach does not work for Mix-up
>>                             attack. As Nov stated, we in fact have
>>                             discussed the approach in quite a length
>>                             back in Yokohama. I really would like to
>>                             know why it does not work.
>>
>>                                 approach to the mix-up attacks.
>>                                 Having two would confuse implementers
>>                                 and cause compatibility problems –
>>                                 reducing overall security.
>>
>>                                 The approach defined in
>>                                 draft-jones-oauth-mix-up-mitigation
>>                                 was created in collaboration with the
>>                                 security researchers who identified
>>                                 the problems in the first place, was
>>                                 vigorously discussed in the security
>>                                 meeting Hannes and Torsten held in
>>                                 Darmstadt, and has been since refined
>>                                 based on substantial input from the
>>                                 working group.  And at least three
>>                                 they’ve implemented it.  I’m not
>>                                 saying that it’s, but if there are
>>                                 things missing or things that need to
>>                                 be improved in our approach, we
>>                                 should do it there, rather
>>                                 introducing a competing approach.
>>
>>                                 authorization server to be
>>                                 retransmitted at runtime. The
>>                                 oauth-meta draft goes too far in that
>>                                 direction, at least as I see it. 
>>                                 Returning things two ways creates its
>>                                 own problems, as discussed in the
>>                                 Duplicate Information Attacks
>>                                 security considerations section (7.2)
>>                                 of the mix-up-mitigation draft.
>>
>>                                 metadata discovery. Replying to
>>                                 Justin’s comment that “It's the
>>                                 attack in the first place” – this is
>>                                 technical discussion on whether there
>>                                 are aspects of the oauth-meta
>>                                 approach that mitigate aspects of the
>>                                 attacks that the mix-up-mitigation
>>                                 approach does not.  That could help
>>                                 inform whether there are additional
>>                                 things we should add to or change in
>>                                 the mix-up draft.
>>
>>                                 -- Mike
>>
>>                                 *From:*OAuth
>>                                 <mailto:[email-masked]>
>>                                 On Wed, Jan 20, 2016 at 9:53 PM,
>>                                 Justin Richer <[email-masked]
>>                                     Inline discovery and
>>                                     pre-configured discovery (ie,
>>                                     .well-known) should at the very
>>                                     least be compatible and developed
>>                                     together. It's the pre-configured
>>                                     discovery document that's at the
>>                                     root of the mix-up attack in the
>>                                     first place.
>>
>>                                      -- Justin
>>
>>                                         Just to give more context, at
>>                                         IETF 94, I have done a
>>                                         presentation on discovery.
>>
>>                                         document as an example of the
>>                                         work that has to be done
>>
>>                                                      in the area of
>>                                         discovery, which is a topic
>>                                         that has been identified
>>
>>                                                      as necessary for
>>                                         interoperability since many
>>                                         years but so far there
>>
>>                                                      was not time to
>>                                         work on it. Mike, John and
>>                                         Nat are working on a new
>>
>>                                                      document that
>>                                         describes additional
>>                                                      Poll: 19 for /
>>                                         zero against / 4 persons need
>>                                         more information.
>>
>>                                         <https://tools.ietf.org/html/draft-sakimura-oauth-meta-05>https://tools.ietf.org/html/draft-sakimura-oauth-meta-05.
>>                                         This is a simple (only
>>                                         1-page!) but a very powerful
>>                                         document that nudges towards
>>                                         HATEOAS which is at the core
>>                                         of RESTful-ness. It also
>>                                         without introducing the
>>                                         concept of issuer which is
>>                                         not in RFC6749. It is also
>>                                         good for selecting different
>>                                         endpoints depending on the
>>                                         user authentication and
>>                                         authorization results and
>>                                         more privacy sensitive than
>>                                         pre-announced Discovery
>>                                         document. It also allows you
>>                                         to find to which protected
>>                                         resource endpoint you can use
>>                                         minutes, it talks about "a
>>                                         new document that describes
>>                                         additional discovery-relevant
>>                                         components". This is
>>                                         It went for the call for
>>                                         adoption. However, it is only
>>                                         a half of the story. I
>>                                         believe
>>                                         was discussed at IETF 94 and
>>                                         had support there should be
>>                                         adopted as well.
>>
>>                                         Nat Sakimura
>>
>>                                         2016年1月20日(水) 12:05 Nat
>>                                             was discussed in
>>                                             Yokohama, and was largely
>>                                             in agreement if my
>>                                             recollection is correct.
>>                                             Why is it not in the call
>>                                             for adoption?
>>
>>                                             2016年1月19日(火) 20:39
>>                                             Hannes Tschofenig
>>                                                 we have submitted our
>>                                                 new charter to the
>>                                                 IESG (see
>>                                                 since some IESG
>>                                                 members like to see
>>                                                 an updated list of
>>                                                 milestones as
>>                                                 well. For this
>>                                                 reason, based on a
>>                                                 suggestion from
>>                                                 adoption concurrently
>>                                                 with the review of
>>                                                 the charter
>>                                                 mails on the
>>                                                 individual documents.
>>                                                 Your feedback
>>                                                 is important! Please
>>                                                 take the time to look
>>                                                 at the documents and
>>                                                 provide

-- 
Chief Architect
Identity Services Engineering     Work: [email-masked]
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography

---

From: Brian Campbell <[email-masked]>
Date: Tue, 26 Jan 2016 12:43:30 -0700

I understand what you're saying but disagree with the premise.

On Tue, Jan 26, 2016 at 12:07 PM, George Fletcher <[email-masked]> wrote:

> supporting a single AS. However, once the RS moves to supporting multiple
> authorization servers then I believe that discovery based on the 'iss'
> string is required. The discovery results can be cached so a discovery
> lookup per transaction is not required.
>
> Thanks,
> George
>
>> I'm not sure what's described in the blog post is actually a variant of
>> an attack that anyone is really concerned about? A client developer would
>> have to change a production system to use an unfamiliar value for the token
>> On Fri, Jan 22, 2016 at 6:29 PM, Nat Sakimura < <[email-masked]>
>>>> [email-masked]>; Justin Richer < <[email-masked]>
>>>> Re: iss. I discussed this a bit with Nov in more details. It probably
>>>> is a sloppy language of the specs that is making it difficult to read what
>>>> you wanted to achieve.
>>>>
>>>>
>>>>
>>>> I’m not saying that there aren’t some good ideas in the oauth-meta
>>>> draft – I’m sure there are, just as there are in the approach designed by
>>>> the participants in Darmstadt.  While I volunteered to write the first
>>>> draft of the mix-up-mitigation approach, it really reflects something a lot
>>>> of people have already bought into – as evidenced in the passion in the
>>>> I would be interested in hearing a technical discussion on whether
>>>> there are aspects of the oauth-meta approach that mitigate aspects of the
>>>> attacks that the mix-up-mitigation approach does not.  That could help
>>>> inform whether there are additional things we should add to or change in
>>>> the mix-up draft.
>>>>
>>>>
>>>>
>>>>                                                           -- Mike
>>>>
>>>>
>>>>

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 27 Jan 2016 01:31:23 +0000

So, is there a lot of cases that the authority section of the Good AS's
Authorization Endpoint and the Token Endpoints are different?
If not, then requiring that they are the same seems to virtually remove the
attack surface for the mix-up related attacks. It does not introduce new
parameter nor discovery. If it can be done, it probably is not worth adding
a new wire protocol element to mitigate the mix-up variants.

2016年1月27日(水) 4:44 Brian Campbell <[email-masked]>:

>>>>> When I wrote the statement, I thought you were pointing to the URL
>>>>> that you can actually pull the configuration information by "the URL of the
>>>>> Finally, your point that HATEOAS reminds you of WSDL, it is not. If
>>>>> you want to have something similar to WSDL in REST API area, it is Swagger.
>>>>> Finally, for what it’s worth, the HATEOAS stuff reminds me far too
>>>>> much of Web Services Description Language (WSDL) – part of the complexity
>>>>> To me, it just does not seem to work, and the combination of the oauth-meta
>>>>> On Jan 21, 2016, at 2:55 AM, Mike Jones <
>>>>> <[email-masked]>[email-masked]> wrote:
>>>>>
>>>>>
>>>>>
>>>>> If you think there are things missing or wrong in the
>>>>> mix-up-mitigation draft, please say what they are.  That will help us
>>>>> quickly converge on a solution that will work for everyone.
>>>>>
>>>>>
>>>>>
>>>>>                                                           Sincerely,
>>>>>
>>>>>                                                           -- Mike
>>>>>
>>>>>
>>>>>
>>>>> [email-masked]>; Justin Richer < <[email-masked]>[email-masked]
>>>>> >
>>>>> The approach defined in draft-jones-oauth-mix-up-mitigation was
>>>>> created in collaboration with the security researchers who identified the
>>>>> problems in the first place, was vigorously discussed in the security
>>>>> meeting Hannes and Torsten held in Darmstadt, and has been since refined
>>>>> based on substantial input from the working group.  And at least three
>>>>> implementers have already stated that they’ve implemented it.  I’m not
>>>>> saying that it’s, but if there are things missing or things that need to be
>>>>> improved in our approach, we should do it there, rather introducing a
>>>>> competing approach.
>>>>>
>>>>>
>>>>>
>>>>> *From:* OAuth [mailto: <[email-masked]>[email-masked]]
>>>>> *On Behalf Of *William Denniss

---

From: Hans Zandbelt <[email-masked]>
Date: Wed, 27 Jan 2016 08:01:16 +0000

I don't see how that can deal with the specific form of the attack where 
the Client would have sent the authorization request to the legitimate 
authorization endpoint of a compromised AS and believes it gets the 
response from that, where in fact it was redirected away to the good AS.

IOW, I don't think this is so much about mixing up endpoints where to 
send stuff to, but mixing up the entity/endpoint from which the Client 
believes the response was received. That may just be terminology though.

Bottom line as far as I see is that a wire protocol element in the 
response is needed to tell the Client who issued it, regardless of how 
the Client deals with configuration of the AS information.

Hans.

On 1/27/16 1:31 AM, Nat Sakimura wrote:
> If not, then requiring that they are the same seems to virtually remove
> the attack surface for the mix-up related attacks. It does not introduce
> new parameter nor discovery. If it can be done, it probably is not worth
> adding a new wire protocol element to mitigate the mix-up variants.
>
>
>
> 2016年1月27日(水) 4:44 Brian Campbell <[email-masked]
> <mailto:[email-masked]>>:
>
>     On Tue, Jan 26, 2016 at 12:07 PM, George Fletcher <[email-masked]
>         So I'm fine with not requiring discovery in the simple case of
>         an RS supporting a single AS. However, once the RS moves to
>         supporting multiple authorization servers then I believe that
>         discovery based on the 'iss' string is required. The discovery
>         results can be cached so a discovery lookup per transaction is
>         not required.
>
>         Thanks,
>         George
>
>>         I'm staying that it's sufficiently unlikely that it shouldn't
>>         be part of the threat model and that a discovery lookup on iss
>>         isn't necessary.
>>
>>
>>         On Tue, Jan 26, 2016 at 8:21 AM, George Fletcher
>>         <[email-masked] <mailto:[email-masked]>> wrote:
>
>>             While it's a different way of getting the endpoints mixed
>>             up, I don't think that makes it invalid. If we are going
>>             to address the attack vector I believe we should solve it
>>             for "all" cases not just the ones that seem most likely.
>>
>>             Thanks,
>>             George
>>
>>>             I'm not sure what's described in the blog post is
>>>             actually a variant of an attack that anyone is really
>>>             concerned about? A client developer would have to change
>>>             a production system to use an unfamiliar value for the
>>>             token endpoint based solely on a an email without even
>>>             looking at service documentation or metadata.
>>>
>>>             On Fri, Jan 22, 2016 at 6:29 PM, Nat Sakimura
>>>             <<mailto:[email-masked]>[email-masked]
>>>                 I wrote a blog on why the current mix-up draft
>>>                 approach does not solve the issue.
>>>
>>>                     configuration information location can be
>>>                     derived” language.  Thanks.  I’ll plan to
>>>                     *From:*Brian Campbell
>>>                     [mailto:<mailto:[email-masked]>[email-masked]
>>>                     *To:* Nat Sakimura
>>>                     <<mailto:[email-masked]>[email-masked]
>>>                     *Cc:* Mike Jones
>>>                     <<mailto:[email-masked]>[email-masked]
>>>                     <mailto:[email-masked]>>; Justin
>>>                     Richer <<mailto:[email-masked]>[email-masked]
>>>                     <mailto:[email-masked]>>; <[email-masked]
>>>                     I agree that the language describing OAuth issuer
>>>                     could and should be improved. The text now reads
>>>                     like it is the exact and full URL where the
>>>                     metadata/discovery document is located. Perhaps
>>>                     something more like "the URL from which the
>>>                     authorization server's configuration information
>>>                     location can be derived" and explain that adding
>>>                     the .well-known bits to the issuer is where the
>>>                     <<mailto:[email-masked]>[email-masked]
>>>                         Re: iss. I discussed this a bit with Nov in
>>>                         more details. It probably is a sloppy
>>>                         language of the specs that is making it
>>>                         difficult to read what you wanted to achieve.
>>>
>>>                         In mix-up-mitigation draft, OAuth issuer is
>>>                         "the URL of the authorization server's
>>>                         configuration information location". In OAuth
>>>                         discovery draft, there is something called
>>>                         "OAuth 2.0 Configuration Information Location
>>>                         When I wrote the statement, I thought you
>>>                         were pointing to the URL that you can
>>>                         actually pull the configuration information
>>>                         by "the URL of the authorizaiton server's
>>>                         configuration information location" since
>>>                         otherwise you would have used the term "OAuth
>>>                         2.0 Configuration Information Location URL".
>>>                         But after all, you probably meant these two
>>>                         are the same. Then I would strongly recommend
>>>                         to fix the language.
>>>
>>>                         ·iss + .well-know/openid-configuration =
>>>                         Connect OP config endoint
>>>
>>>                         ·OAuth config endpoint -
>>>                         You also claim that your approach is simpler,
>>>                         but to me, your approach seem to be overly
>>>                         complex. It requires discovery and the check
>>>                         for the value of the discovered config
>>>                         information to work as the mitigation.
>>>                         (Right. Draft -01 does not have it, so it
>>>                         does not solve the mix-up issue.) With
>>>                         Finally, your point that HATEOAS reminds you
>>>                         of WSDL, it is not. If you want to have
>>>                         something similar to WSDL in REST API area,
>>>                         it is Swagger. (Actually, it is gaining a lot
>>>                         of momentum recently, but that's beside the
>>>                         fact ;-). And the point here is not the
>>>                         format but the fact that we need to have a
>>>                         way to associate metadata to the data. The
>>>                         root cause of this mix-up attack is that the
>>>                         metadata and data is not associated properly.
>>>                         We have a standard way of associating the
>>>                         data and metadata with link-rel such as
>>>                         RFC5988 so why not use it? Link-rel-href
>>>                         pattern is used a lot now. Most modern web
>>>                         pages actually have it. Using a proper way to
>>>                         associate metadata with data will save you
>>>                         from a lot of other attacks in the future.
>>>                         Instead of doing patch works, we should solve
>>>                         it architecturally.
>>>
>>>                         Nat
>>>
>>>                         <<mailto:[email-masked]>[email-masked]
>>>                             Nat, I’m confused by this statement in
>>>                             the message you reference “Unfortunately,
>>>                             of draft-jones-oauth-mix-up-mitigation-01
>>>                             nor the 'iss' returned as specified in
>>>                             3.1. As such, validation as specified in
>>>                             bullet 1 of Section 4 fails in Google's
>>>                             case -- OR it means that the document is
>>>                             internally inconsistent.”. The issuer
>>>                             definition in draft-jones-oauth-discovery
>>>                             is 100% compatible with the one in OpenID
>>>                             Connect Discovery, by design.  In the
>>>                             Google example, both the OpenID issuer
>>>                             and the OAuth issuer values would be the
>>>                             string
>>>                             “<https://accounts.google.com>https://accounts.google.com”.
>>>                             What is the inconsistency that you perceive?
>>>
>>>                             I will admit, in Yokohama, I didn’t speak
>>>                             up in the public meetings to point out
>>>                             that a simpler alternative to oauth-meta
>>>                             was already being discussed there in
>>>                             private, because then I would have had to
>>>                             talk about the security issues, which
>>>                             we’d decided not to publicly do at that
>>>                             point. So I stayed silent during the
>>>                             poll, out of politeness. Perhaps I should
>>>                             have found a way to say something then
>>>                             anyway, but that’s water under the bridge
>>>                             now.
>>>
>>>                             Finally, for what it’s worth, the HATEOAS
>>>                             stuff reminds me far too much of Web
>>>                             Services Description Language (WSDL) –
>>>                             part of the complexity baggage that
>>>                             helped sink Web Services.  The use of
>>>                             “link rel” to define an interaction
>>>                             vocabulary and publish endpoints for that
>>>                             vocabulary seems pretty baroque and
>>>                             reminiscent of “microformats” – another
>>>                             cute “Webby” innovation that never caught
>>>                             on.  The industry has pretty much voted
>>>                             with its feet and is using JSON for
>>>                             publishing discovery data structures –
>>>                             not “link rel”.  I am against us
>>>                             reverting to the “link rel” proposal from
>>>                             2008 that never caught on when JSON is
>>>                             *From:*Nat Sakimura
>>>                             [mailto:<mailto:[email-masked]>[email-masked]
>>>                             *To:* Justin Richer
>>>                             <<mailto:[email-masked]>[email-masked]
>>>                             <<mailto:[email-masked]>[email-masked]
>>>                             *Cc:* William Denniss
>>>                             <<mailto:[email-masked]>[email-masked]
>>>                             <mailto:[email-masked]>>;
>>>                             <<mailto:[email-masked]>[email-masked]
>>>                             <mailto:[email-masked]>>
>>>                             <<mailto:[email-masked]>[email-masked]
>>>                             <mailto:[email-masked]>>
>>>
>>>
>>>                             <https://www.ietf.org/mail-archive/web/oauth/current/msg15483.html>https://www.ietf.org/mail-archive/web/oauth/current/msg15483.html .
>>>                             To me, it just does not seem to work, and
>>>                             the combination of the oauth-meta and
>>>                             PKCE seems to be much more elegan, nicer,
>>>                             and much simpler to implement. If you
>>>                             just give up the dynamic response at the
>>>                             authorization endpoint, then you even do
>>>                             not have to touch the code but just
>>>                             change a config file.
>>>
>>>                             session. The poll in the room was 19 for
>>>                             / zero against / 4 persons need more
>>>                             information. Indeed, it is not
>>>                             duplicating much. And if you move to a
>>>                             I understand your usecases always start
>>>                             from a concrete endpoint location. Mine
>>>                             do not. In a four party model, it is
>>>                             likely not. The user just want to have
>>>                             the service to fetch his data from some
>>>                             resource endpoint. He just hits the
>>>                             service. He does not hit the resource
>>>                             endpoint directly. For example, in the
>>>                             case of a consumer using a personal
>>>                             finance platform (PFP)to manage his
>>>                             pension fund, he hits the PFP and not the
>>>                             Pension fund. Assuming that the pension
>>>                             fund has delegated the authorization
>>>                             control to the authorization server,
>>>                             then, the authorization server should
>>>                             return both the access token and the
>>>                             endpoint of the pension fund so that the
>>>                             PFP can pull the data using them. A
>>>                             similar model holds for personal health
>>>                             <<mailto:[email-masked]>[email-masked]
>>>                             <mailto:[email-masked]>>:
>>>
>>>                                 Convergence is exactly what I’m
>>>                                 arguing for, though. These things
>>>                                 ought to work together.
>>>
>>>                                  — Justin
>>>
>>>                                     <<mailto:[email-masked]>[email-masked]
>>>                                     My memory of the discussions of
>>>                                     the oauth-meta draft in Yokohama
>>>                                     were that many people felt that
>>>                                     it was unnecessarily dynamically
>>>                                     duplicating a lot of information
>>>                                     that the client already had.
>>>                                     Most of us that were aware of the
>>>                                     attacks then were in favor of a
>>>                                     more targeted, minimal approach.
>>>                                     You were listened to in Yokohama,
>>>                                     but that didn’t necessarily mean
>>>                                     that people agreed with the
>>>                                     approach. Participants were
>>>                                     already aware of the oauth-meta
>>>                                     proposal in Darmstadt but no one
>>>                                     spoke up in favor of it that I
>>>                                     can recall. Rather, I think
>>>                                     people were thinking that “less
>>>                                     is more”.
>>>
>>>                                     There have also been discussions
>>>                                     in the last day about how
>>>                                     dynamically returning a resource
>>>                                     URL, which oauth-meta does, is
>>>                                     both unnecessary (since the
>>>                                     client initiated the resource
>>>                                     authorization already knowing
>>>                                     what resource it wants to access)
>>>                                     and often problematic, since many
>>>                                     authorization servers can
>>>                                     authorize access to multiple
>>>                                     resources.  If anything, the
>>>                                     client should be telling the
>>>                                     authorization server what
>>>                                     draft – I’m sure there are, just
>>>                                     as there are in the approach
>>>                                     designed by the participants in
>>>                                     Darmstadt. While I volunteered to
>>>                                     write the first draft of the
>>>                                     mix-up-mitigation approach, it
>>>                                     really reflects something a lot
>>>                                     of people have already bought
>>>                                     into – as evidenced in the
>>>                                     passion in the high-volume
>>>                                     “Mix-Up About The Mix-Up
>>>                                     Mitigation” thread, and not just
>>>                                     my personal project.
>>>
>>>                                     mix-up-mitigation draft, please
>>>                                     say what they are.  That will
>>>                                     help us quickly converge on a
>>>                                     *From:*Nat Sakimura
>>>                                     [<mailto:[email-masked]>mailto:[email-masked]]
>>>
>>>                                     *To:* Mike Jones
>>>                                     <<mailto:[email-masked]>[email-masked]
>>>                                     William Denniss
>>>                                     <<mailto:[email-masked]>[email-masked]
>>>                                     <<mailto:[email-masked]>[email-masked]
>>>                                     *Cc:*
>>>                                     <mailto:[email-masked]>[email-masked]
>>>                                     <mailto:[email-masked]>
>>>                                     Conversely, I would like to ask
>>>                                     why this approach does not work
>>>                                     for Mix-up attack. As Nov stated,
>>>                                     we in fact have discussed the
>>>                                     approach in quite a length back
>>>                                     in Yokohama. I really would like
>>>                                     to know why it does not work.
>>>
>>>                                     Besides, for oauth-meta approach,
>>>                                     mix-up attack is only one of the
>>>                                     thing it solves.
>>>
>>>                                     Nat Sakimura
>>>
>>>                                     2016年1月21日(木) 16:02 Mike
>>>                                     Jones
>>>                                     <<mailto:[email-masked]>[email-masked]
>>>                                         draft-sakimura-oauth-meta. We
>>>                                         should define and promote one
>>>                                         mitigation approach to the
>>>                                         mix-up attacks. Having two
>>>                                         would confuse implementers
>>>                                         and cause compatibility
>>>                                         problems – reducing overall
>>>                                         security.
>>>
>>>                                         The approach defined in
>>>                                         was created in collaboration
>>>                                         with the security researchers
>>>                                         who identified the problems
>>>                                         in the first place, was
>>>                                         vigorously discussed in the
>>>                                         security meeting Hannes and
>>>                                         Torsten held in Darmstadt,
>>>                                         and has been since refined
>>>                                         based on substantial input
>>>                                         from the working group.  And
>>>                                         at least three implementers
>>>                                         have already stated that
>>>                                         they’ve implemented it.  I’m
>>>                                         not saying that it’s, but if
>>>                                         there are things missing or
>>>                                         things that need to be
>>>                                         improved in our approach, we
>>>                                         Also, standard OAuth
>>>                                         deployments register the
>>>                                         client and then use the
>>>                                         information gathered at
>>>                                         registration time for
>>>                                         subsequent protocol
>>>                                         interactions. They do not
>>>                                         need all the configuration
>>>                                         information for the
>>>                                         oauth-meta draft goes too far
>>>                                         in that direction, at least
>>>                                         as I see it.  Returning
>>>                                         things two ways creates its
>>>                                         own problems, as discussed in
>>>                                         the Duplicate Information
>>>                                         Attacks security
>>>                                         considerations section (7.2)
>>>                                         I’ll note that the
>>>                                         mix-up-mitigation approach is
>>>                                         compatible with existing
>>>                                         practice in both static and
>>>                                         dynamic metadata discovery.
>>>                                         Replying to Justin’s comment
>>>                                         that “It's the pre-configured
>>>                                         discovery document that's at
>>>                                         the root of the mix-up attack
>>>                                         in the first place” – this is
>>>                                         not the case.  The attacks
>>>                                         can be performed without
>>>                                         either discovery or dynamic
>>>                                         registration.
>>>
>>>                                         I would be interested in
>>>                                         hearing a technical
>>>                                         discussion on whether there
>>>                                         approach that mitigate
>>>                                         aspects of the attacks that
>>>                                         the mix-up-mitigation
>>>                                         approach does not.  That
>>>                                         could help inform whether
>>>                                         there are additional things
>>>                                         we should add to or change in
>>>                                         the mix-up draft.
>>>
>>>                                         -- Mike
>>>
>>>                                         *From:*OAuth
>>>                                         [mailto:<mailto:[email-masked]>[email-masked]
>>>                                         <mailto:[email-masked]>]
>>>                                         *To:* Justin Richer
>>>                                         <<mailto:[email-masked]>[email-masked]
>>>                                         *Cc:*
>>>                                         <mailto:[email-masked]>[email-masked]
>>>                                         <mailto:[email-masked]>
>>>                                         On Wed, Jan 20, 2016 at 9:53
>>>                                         PM, Justin Richer
>>>                                         <<mailto:[email-masked]>[email-masked]
>>>                                             pre-configured discovery
>>>                                             (ie, .well-known) should
>>>                                             at the very least be
>>>                                             compatible and developed
>>>                                             together. It's the
>>>                                             pre-configured discovery
>>>                                             document that's at the
>>>                                             root of the mix-up attack
>>>                                             in the first place.
>>>
>>>                                              -- Justin
>>>
>>>                                             On 1/19/2016 10:30 PM,
>>>                                             Nat Sakimura wrote:
>>>
>>>                                                 Just to give more
>>>                                                 context, at IETF 94,
>>>                                                 I have done a
>>>                                                 presentation on
>>>                                                 discovery.
>>>
>>>                                                 According to the
>>>                                                 minutes,
>>>
>>>                                                     (f) Discovery (Nat)
>
>>>                                                              Nat
>>>                                                 explains his document
>>>                                                 as an example of the
>>>                                                 work that has to be done
>>>
>>>                                                              in the
>>>                                                 area of discovery,
>>>                                                 which is a topic that
>>>                                                 has been identified
>>>
>>>                                                              as
>>>                                                 necessary for
>>>                                                 interoperability
>>>                                                 since many years but
>>>                                                 so far there
>>>
>>>                                                              was not
>>>                                                 time to work on it.
>>>                                                 Mike, John and Nat
>>>                                                 are working on a new
>>>
>>>                                                              document
>>>                                                 that describes
>>>                                                 additional
>>>                                                 discovery-relevant
>>>                                                 components.
>>>
>>>                                                              Poll: 19
>>>                                                 for / zero against /
>>>                                                 4 persons need more
>>>                                                 information.
>>>
>>>                                                 The document
>>>                                                 discussed there was
>>>                                                 <https://tools.ietf.org/html/draft-sakimura-oauth-meta-05><https://tools.ietf.org/html/draft-sakimura-oauth-meta-05>https://tools.ietf.org/html/draft-sakimura-oauth-meta-05.
>>>                                                 This is a simple
>>>                                                 (only 1-page!) but a
>>>                                                 very powerful
>>>                                                 document that nudges
>>>                                                 towards HATEOAS which
>>>                                                 is at the core of
>>>                                                 RESTful-ness. It also
>>>                                                 mitigates the Mix-up
>>>                                                 attack without
>>>                                                 introducing the
>>>                                                 concept of issuer
>>>                                                 which is not in
>>>                                                 RFC6749. It is also
>>>                                                 good for selecting
>>>                                                 different endpoints
>>>                                                 depending on the user
>>>                                                 authentication and
>>>                                                 authorization results
>>>                                                 and more privacy
>>>                                                 sensitive than
>>>                                                 pre-announced
>>>                                                 Discovery document.
>>>                                                 It also allows you to
>>>                                                 find to which
>>>                                                 protected resource
>>>                                                 endpoint you can use
>>>                                                 the access token
>>>                                                 against.
>>>
>>>                                                 In the last sentence
>>>                                                 of the minutes, it
>>>                                                 talks about "a new
>>>                                                 document that
>>>                                                 describes additional
>>>                                                 discovery-relevant
>>>                                                 components". This is
>>>                                                 <https://tools.ietf.org/html/draft-jones-oauth-discovery-00>https://tools.ietf.org/html/draft-jones-oauth-discovery-00.
>>>                                                 It went for the call
>>>                                                 for adoption.
>>>                                                 However, it is only a
>>>                                                 half of the story. I
>>>                                                 believe
>>>                                                 <https://tools.ietf.org/html/draft-sakimura-oauth-meta-05>https://tools.ietf.org/html/draft-sakimura-oauth-meta-05 that
>>>                                                 was discussed at IETF
>>>                                                 94 and had support
>>>                                                 there should be
>>>                                                 adopted as well.
>>>
>>>                                                 Nat Sakimura
>>>
>
>

-- 
Hans Zandbelt              | Sr. Technical Architect
[email-masked] | Ping Identity

---

From: [email-masked]
Date: Wed, 27 Jan 2016 19:31:04 +0900

Hi Hans,

Sorry, I mixed up the IdP mix-up attack and the code phishing attack.

Mandating the Authorization and Token Endpoint being in the same
authority would solve the later without changing the wire protocol.

For AS mix-up attack, mandating the client to change the redirection 
endpoint
per AS would solve the problem without change the wire protocol.

If these are not possible, then we would have to look at changing the
wire protocol. The solution that solves the both cases must
provide the token endpoint URI authoritatively, which means
you have to mandate some variation of discovery mandatory.

Nat

At 2016-01-27 17:01  Hans Zandbelt wrote:
> I don't see how that can deal with the specific form of the attack
> where the Client would have sent the authorization request to the
> legitimate authorization endpoint of a compromised AS and believes it
> gets the response from that, where in fact it was redirected away to
> the good AS.
>

---

From: John Bradley <[email-masked]>
Date: Wed, 27 Jan 2016 10:30:23 -0300

It think requiring a common authority segment for the authorization endpoint and the token endpoint might work in common cases, but there are legitimate cases where the URI of the Authorization endpoint might be a alias in the case of multi tenants, all using a common token endpoint.    

The larger problem would be the RS, it is not uncommon to have the AS and RS in different domains,  so with bearer tokens unless you make the same authority restriction for RS then you are not really stoping the attacker.   They can get the AT by impersonating the RS.

I think trying to enforce a common origin policy over OAuth would be a bad direction to go.

I understand that it seems like a easy fix on the surface, and it works for most of the things people are using OAuth for today, but would be quite limiting over the long term.

John B.
> On Jan 27, 2016, at 7:31 AM, [email-masked] wrote:
> 
> Hi Hans,
> 
> For AS mix-up attack, mandating the client to change the redirection endpoint

---

From: George Fletcher <[email-masked]>
Date: Wed, 27 Jan 2016 10:30:05 -0500

I agree that in many cases the RS and AS are in different domains and I 
think that OAuth2 explicitly was designed to support that.

I don't see how "sending a token to a bad RS" is a variant of the mix-up 
attack.

To me, it's the clients responsibility to send the token to an 
appropriate endpoint. In most cases, the RS endpoints are well known and 
not discovered (unless we are talking about endpoints like the userinfo 
endpoint).

While it's possible to use webfinger to do dynamic RS endpoint 
discovery, I haven't seen any real use of that mechanism. What are the 
use cases where the client will be confused to send the token to the 
wrong RS apart from endpoints obtained via discovery? Also, the client 
can always use the refresh_token mechanism to downscope tokens to a 
single scope such that exposure is limited (which is the intent of 
authorization protection in OAuth2).

If we are trying to solve a use case where tokens are bound to the RS 
they are sent to, then we need something other than standard OAuth2. I 
don't think we should be trying to solve that problem with these 
security mitigations.

Thanks,
George

---

From: Brian Campbell <[email-masked]>
Date: Wed, 27 Jan 2016 10:02:40 -0700

There's at least one smallish deployment that has a different authority for
the Authorization Endpoint and the Token Endpoint.

from https://accounts.google.com/.well-known/openid-configuration :

{
 "issuer": "https://accounts.google.com",
 "authorization_endpoint": "https://accounts.google.com/o/oauth2/v2/auth",
 "token_endpoint": "https://www.googleapis.com/oauth2/v4/token",
 "userinfo_endpoint": "https://www.googleapis.com/oauth2/v3/userinfo",
 "revocation_endpoint": "https://accounts.google.com/o/oauth2/revoke",
 "jwks_uri": "https://www.googleapis.com/oauth2/v3/certs",
 ...
}

On Wed, Jan 27, 2016 at 6:30 AM, John Bradley <[email-masked]> wrote:

> It think requiring a common authority segment for the authorization
> endpoint and the token endpoint might work in common cases, but there are
> legitimate cases where the URI of the Authorization endpoint might be a
> alias in the case of multi tenants, all using a common token endpoint.
>
> The larger problem would be the RS, it is not uncommon to have the AS and
> RS in different domains,  so with bearer tokens unless you make the same
> authority restriction for RS then you are not really stoping the attacker.
>  They can get the AT by impersonating the RS.
>
> I understand that it seems like a easy fix on the surface, and it works
> for most of the things people are using OAuth for today, but would be quite
> limiting over the long term.
>
> John B.

---

From: Antonio Sanso <[email-masked]>
Date: Wed, 27 Jan 2016 17:09:43 +0000

hi John,

if you remember I even proposed something along those lines in Darmstadt and it was deemed (with reason) as not enough good protection since the attacker can use a proxy….

regards

antonio

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 27 Jan 2016 18:15:30 +0000

yeah.

But for Google, Microsoft, etc., every RP can whitelist, cannot they? ;-)

Otherwise, for a code phishing attack, you need to implement discovery of
some sort. My thinking before reading your email was:

if( authority(authz_ep)==authority(token_ep) ) {
   get_token(token_ep, code, client_credential);
} else {
    get_token(token_ep_from_discovery(), code, client_credential);
}

where token_ep_from_discovery() either returns the value of the
toke_endpoint member from .well-known/openid-configuration OR the value of
turi parameter in the query.

2016年1月28日(木) 2:03 Brian Campbell <[email-masked]>:

> There's at least one smallish deployment that has a different authority
> for the Authorization Endpoint and the Token Endpoint.
>

---

From: Justin Richer <[email-masked]>
Date: Wed, 27 Jan 2016 15:45:26 -0500

Unless I’m missing something, requiring the authority section to match discounts attackers being able to deploy executable code on a path. This kind of hole was exploited in a number of Facebook hacks. Yes I’m aware that those were dealing with redirect URIs but we’re talking about the same kind of sub-component URI matching here, and I can only see it getting us into trouble.

 — Justin

> On Jan 27, 2016, at 1:15 PM, Nat Sakimura <[email-masked]> wrote:
> 
> yeah. 
> 
> Otherwise, for a code phishing attack, you need to implement discovery of some sort. My thinking before reading your email was: 
> 
> where token_ep_from_discovery() either returns the value of the toke_endpoint member from .well-known/openid-configuration OR the value of turi parameter in the query. 
> 
> 2016年1月28日(木) 2:03 Brian Campbell <[email-masked] <mailto:[email-masked]>>:
> There's at least one smallish deployment that has a different authority for the Authorization Endpoint and the Token Endpoint.
> 
> from https://accounts.google.com/.well-known/openid-configuration <https://accounts.google.com/.well-known/openid-configuration> :
> 
> {
>  "issuer": "https://accounts.google.com <https://accounts.google.com/>",
>  "authorization_endpoint": "https://accounts.google.com/o/oauth2/v2/auth <https://accounts.google.com/o/oauth2/v2/auth>",
>  "token_endpoint": "https://www.googleapis.com/oauth2/v4/token <https://www.googleapis.com/oauth2/v4/token>",
>  "userinfo_endpoint": "https://www.googleapis.com/oauth2/v3/userinfo <https://www.googleapis.com/oauth2/v3/userinfo>",
>  "revocation_endpoint": "https://accounts.google.com/o/oauth2/revoke <https://accounts.google.com/o/oauth2/revoke>",
>  "jwks_uri": "https://www.googleapis.com/oauth2/v3/certs <https://www.googleapis.com/oauth2/v3/certs>",
>  ...
> }
> 
> 
> On Wed, Jan 27, 2016 at 6:30 AM, John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
> > On Jan 27, 2016, at 7:31 AM, [email-masked] <mailto:[email-masked]> wrote:
> >
> > Hi Hans,
> >

---

From: Nat Sakimura <[email-masked]>
Date: Thu, 28 Jan 2016 00:19:41 +0000

You mean the string comparison on authority section would allow execution
of some code? Or are you suggesting that not checking the path portion
would allow the attacker to plant something on the other paths on the host?

Yes, the later is possible especially when there are user generated content
on the same host, and if we are worried on it, we would have to do the
discovery.

Nat

2016年1月28日(木) 5:45 Justin Richer <[email-masked]>:

> Unless I’m missing something, requiring the authority section to match
> discounts attackers being able to deploy executable code on a path. This
> kind of hole was exploited in a number of Facebook hacks. Yes I’m aware
> that those were dealing with redirect URIs but we’re talking about the same
> kind of sub-component URI matching here, and I can only see it getting us
> into trouble.
>
>  — Justin
>
>
>>> The larger problem would be the RS, it is not uncommon to have the AS
>>> and RS in different domains,  so with bearer tokens unless you make the
>>> same authority restriction for RS then you are not really stoping the
>>> attacker.   They can get the AT by impersonating the RS.
>>>

---

From: Justin Richer <[email-masked]>
Date: Wed, 27 Jan 2016 21:02:18 -0500

Definitely the latter. I don’t think the requirement actually helps secure things in practice and artificially limits things otherwise.

 — Justin

> On Jan 27, 2016, at 7:19 PM, Nat Sakimura <[email-masked]> wrote:
> 
> You mean the string comparison on authority section would allow execution of some code? Or are you suggesting that not checking the path portion would allow the attacker to plant something on the other paths on the host? 
> 
> Yes, the later is possible especially when there are user generated content on the same host, and if we are worried on it, we would have to do the discovery. 
> 
> Nat 
> 
> 2016年1月28日(木) 5:45 Justin Richer <[email-masked] <mailto:[email-masked]>>:
>> On Jan 27, 2016, at 1:15 PM, Nat Sakimura <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> yeah. 
>>

---

From: John Bradley <[email-masked]>
Date: Wed, 27 Jan 2016 23:06:26 -0300

I agree, common origin mapping for OAuth would be a horrible road to go down.    Pattern matching redirect URI has been a thorn in Facebook’s side that has never worked.  

At best it would be security theatre, and cripple many legitimate use cases.

John B.

> On Jan 27, 2016, at 11:02 PM, Justin Richer <[email-masked]> wrote:
> 
>> On Jan 27, 2016, at 7:19 PM, Nat Sakimura <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: "Nat Sakimura" <[email-masked]>
Date: Thu, 28 Jan 2016 13:34:47 +0900

OK. I’m sold. 

There is no way out without some kind of discovery in the multi-AS case. 

Do I have to worry for the cases that the client is storing the client secret with the issuer authority (e.g.,  <https://example.com/> https://example.com/) as the key and sends the client secret to the bad issuer  <https://example.com/foo/> https://example.com/foo/ ? Hope not. 

--

PLEASE READ :This e-mail is confidential and intended for the

named recipient only. If you are not an intended recipient,

please notify the sender  and delete this e-mail.

From: OAuth [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Thursday, January 28, 2016 11:06 AM
To: Justin Richer
Cc: <[email-masked]>
Subject: Re: [OAUTH-WG] Call for Adoption

John B.

On Jan 27, 2016, at 11:02 PM, Justin Richer <[email-masked] <mailto:[email-masked]> > wrote:

 — Justin

On Jan 27, 2016, at 7:19 PM, Nat Sakimura <[email-masked] <mailto:[email-masked]> > wrote:

Nat 

2016年1月28日(木) 5:45 Justin Richer <[email-masked] <mailto:[email-masked]> >:

 — Justin

On Jan 27, 2016, at 1:15 PM, Nat Sakimura <[email-masked] <mailto:[email-masked]> > wrote:

yeah. 

} else {

} 

2016年1月28日(木) 2:03 Brian Campbell <[email-masked] <mailto:[email-masked]> >:

{
 "issuer": "https://accounts.google.com <https://accounts.google.com/> ",

On Wed, Jan 27, 2016 at 6:30 AM, John Bradley <[email-masked] <mailto:[email-masked]> > wrote:

John B.