Re: [OAUTH-WG] Call for Adoption

[Hans Zandbelt <[e-mail]>]

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:
> 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 <[e-mail]
> <mailto:[e-mail]>>:
>
>     I understand what you're saying but disagree with the premise.
>
>     On Tue, Jan 26, 2016 at 12:07 PM, George Fletcher <[e-mail]
>     <mailto:[e-mail]>> wrote:
>
>         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
>>         <[e-mail] <mailto:[e-mail]>> 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
>>
>>             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
>>>             <<mailto:[e-mail]>[e-mail]
>>>             <mailto:[e-mail]>> wrote:
>
>>>                 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
>>>                 <[e-mail]
>>>                 <mailto:[e-mail]>>:
>
>>>                     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:<mailto:[e-mail]>[e-mail]
>>>                     <mailto:[e-mail]>]
>>>                     *Sent:* Friday, January 22, 2016 3:26 PM
>>>                     *To:* Nat Sakimura
>>>                     <<mailto:[e-mail]>[e-mail]
>>>                     <mailto:[e-mail]>>
>>>                     *Cc:* Mike Jones
>>>                     <<mailto:[e-mail]>[e-mail]
>>>                     <mailto:[e-mail]>>; Justin
>>>                     Richer <<mailto:[e-mail]>[e-mail]
>>>                     <mailto:[e-mail]>>; <[e-mail]
>>>                     <mailto:[e-mail]>> <[e-mail]
>>>                     <mailto:[e-mail]>>
>>>
>>>
>>>                     *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
>>>                     <<mailto:[e-mail]>[e-mail]
>>>                     <mailto:[e-mail]>> 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
>>>                         <<mailto:[e-mail]>[e-mail]
>>>                         <mailto:[e-mail]>>:
>>>
>>>                             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>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:<mailto:[e-mail]>[e-mail]
>>>                             <mailto:[e-mail]>]
>>>                             *Sent:* Thursday, January 21, 2016 6:24 AM
>>>                             *To:* Justin Richer
>>>                             <<mailto:[e-mail]>[e-mail]
>>>                             <mailto:[e-mail]>>; Mike Jones
>>>                             <<mailto:[e-mail]>[e-mail]
>>>                             <mailto:[e-mail]>>
>>>                             *Cc:* William Denniss
>>>                             <<mailto:[e-mail]>[e-mail]
>>>                             <mailto:[e-mail]>>;
>>>                             <<mailto:[e-mail]>[e-mail]
>>>                             <mailto:[e-mail]>>
>>>                             <<mailto:[e-mail]>[e-mail]
>>>                             <mailto:[e-mail]>>
>>>
>>>
>>>                             *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>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
>>>                             <<mailto:[e-mail]>[e-mail]
>>>                             <mailto:[e-mail]>>:
>>>
>>>                                 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
>>>                                     <<mailto:[e-mail]>[e-mail]
>>>                                     <mailto:[e-mail]>>
>>>                                     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:[e-mail]>mailto:[e-mail]]
>>>
>>>                                     *Sent:* Wednesday, January 20,
>>>                                     2016 11:17 PM
>>>                                     *To:* Mike Jones
>>>                                     <<mailto:[e-mail]>[e-mail]
>>>                                     <mailto:[e-mail]>>;
>>>                                     William Denniss
>>>                                     <<mailto:[e-mail]>[e-mail]
>>>                                     <mailto:[e-mail]>>;
>>>                                     Justin Richer
>>>                                     <<mailto:[e-mail]>[e-mail]
>>>                                     <mailto:[e-mail]>>
>>>                                     *Cc:*
>>>                                     <mailto:[e-mail]>[e-mail]
>>>                                     <mailto:[e-mail]>
>>>                                     *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
>>>                                     <<mailto:[e-mail]>[e-mail]
>>>                                     <mailto:[e-mail]>>:
>>>
>>>                                         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:<mailto:[e-mail]>[e-mail]
>>>                                         <mailto:[e-mail]>]
>>>                                         *On Behalf Of *William Denniss
>>>                                         *Sent:* Wednesday, January
>>>                                         20, 2016 10:37 PM
>>>                                         *To:* Justin Richer
>>>                                         <<mailto:[e-mail]>[e-mail]
>>>                                         <mailto:[e-mail]>>
>>>                                         *Cc:*
>>>                                         <mailto:[e-mail]>[e-mail]
>>>                                         <mailto:[e-mail]>
>>>                                         *Subject:* Re: [OAUTH-WG]
>>>                                         Call for Adoption
>>>
>>>                                         +1 to adopt this, and I agree
>>>                                         with Justin's comments.
>>>
>>>                                         On Wed, Jan 20, 2016 at 9:53
>>>                                         PM, Justin Richer
>>>                                         <<mailto:[e-mail]>[e-mail]
>>>                                         <mailto:[e-mail]>> 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.
>>>
>>>                                                 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
>>>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
Hans Zandbelt              | Sr. Technical Architect
[e-mail] | Ping Identity