Skip to main content

OAuth 2.0 Authorization Server Metadata
draft-ietf-oauth-discovery-10

Revision differences

Document history

Date Rev. By Action
2018-06-27
10 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2018-06-13
10 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2018-06-07
10 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2018-04-02
10 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2018-03-30
10 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2018-03-27
10 (System) IANA Action state changed to Waiting on Authors from In Progress
2018-03-21
10 (System) RFC Editor state changed to EDIT
2018-03-21
10 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2018-03-21
10 (System) Announcement was received by RFC Editor
2018-03-21
10 (System) IANA Action state changed to In Progress
2018-03-21
10 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2018-03-21
10 Cindy Morgan IESG has approved the document
2018-03-21
10 Cindy Morgan Closed "Approve" ballot
2018-03-21
10 Cindy Morgan Ballot writeup was changed
2018-03-21
10 Cindy Morgan Ballot approval text was generated
2018-03-21
10 Eric Rescorla IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2018-03-05
10 Alexey Melnikov [Ballot comment]
Thank you for addressing my DISCUSS.
2018-03-05
10 Alexey Melnikov [Ballot Position Update] Position for Alexey Melnikov has been changed to No Objection from Discuss
2018-03-04
10 Michael Jones New version available: draft-ietf-oauth-discovery-10.txt
2018-03-04
10 (System) New version approved
2018-03-04
10 (System) Request for posting confirmation emailed to previous authors: Nat Sakimura , John Bradley , Michael Jones
2018-03-04
10 Michael Jones Uploaded new revision
2018-03-01
09 Adam Roach [Ballot comment]
Thank you for addressing my DISCUSS.
2018-03-01
09 Adam Roach [Ballot Position Update] Position for Adam Roach has been changed to No Objection from Discuss
2018-02-28
09 Alexey Melnikov
[Ballot discuss]
Thank you for the well written IANA Considerations section. I have one comment on it which should be easy to resolve:

The document …
[Ballot discuss]
Thank you for the well written IANA Considerations section. I have one comment on it which should be easy to resolve:

The document doesn't seem to say anything about allowed characters in Metadata names. When the document talks about "case-insensitive matching", it is not clear how to implement the matching, because it is not clear whether or not Metadata names are ASCII only. If they are not, then you need to better define what "case insensitive" means.

You've made a change in section 7.1, which looks good. However there is still the following text in 7.1.1:

  Metadata Name:
      The name requested (e.g., "issuer").  This name is case-sensitive.
      Names may not match other registered names in a case-insensitive

I suggest replacing "in a case-insensitive manner" with something like "if when applying Unicode toLowerCase() to both, they compare equal".

Or maybe keep "case-insensitive" and just add a sentence explaining what it is. I think you should use toLowerCase(), as it is already recommended in other IETF specs, like RFC 8265.

      manner unless the Designated Experts state that there is a
      compelling reason to allow an exception.
2018-02-28
09 Alexey Melnikov [Ballot comment]
I am agreeing with Adam's DISCUSS. I believe it was addressed in the latest version.
2018-02-28
09 Alexey Melnikov Ballot comment and discuss text updated for Alexey Melnikov
2018-02-27
09 (System) Sub state has been changed to AD Followup from Revised ID Needed
2018-02-27
09 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2018-02-27
09 Michael Jones New version available: draft-ietf-oauth-discovery-09.txt
2018-02-27
09 (System) New version approved
2018-02-27
09 (System) Request for posting confirmation emailed to previous authors: Nat Sakimura , John Bradley , Michael Jones
2018-02-27
09 Michael Jones Uploaded new revision
2018-01-25
08 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2018-01-24
08 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2018-01-24
08 Warren Kumari [Ballot comment]
I support Alexey's DISCUSS (and sure hope it is ASCII, otherwise "It's a trap!")
2018-01-24
08 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2018-01-24
08 Terry Manderson [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson
2018-01-24
08 Alissa Cooper
[Ballot comment]
I support Adam's DISCUSS.

And as the Gen-ART reviewer pointed out, I find it a bit troubling that the shepherd write-up answers to …
[Ballot comment]
I support Adam's DISCUSS.

And as the Gen-ART reviewer pointed out, I find it a bit troubling that the shepherd write-up answers to the questions about IANA registrations are completely wrong.
2018-01-24
08 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2018-01-24
08 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2018-01-24
08 Alexey Melnikov
[Ballot discuss]
Thank you for the well written IANA Considerations section. I have one comment on it which should be easy to resolve:

The document …
[Ballot discuss]
Thank you for the well written IANA Considerations section. I have one comment on it which should be easy to resolve:

The document doesn't seem to say anything about allowed characters in Metadata names. When the document talks about "case-insensitive matching", it is not clear how to implement the matching, because it is not clear whether or not Metadata names are ASCII only. If they are not, then you need to better define what "case insensitive" means.
2018-01-24
08 Alexey Melnikov [Ballot comment]
I am agreeing with Adam's DISCUSS.
2018-01-24
08 Alexey Melnikov [Ballot Position Update] New position, Discuss, has been recorded for Alexey Melnikov
2018-01-23
08 Adam Roach
[Ballot discuss]
Thanks to everyone who worked on this specification. I think it's well-written, clear, and useful. I fully endorse publication, and intend to ballot …
[Ballot discuss]
Thanks to everyone who worked on this specification. I think it's well-written, clear, and useful. I fully endorse publication, and intend to ballot "yes" once we come to an agreement on the issue I describe below.

The problem I'm running into is the URL synthesis rules described in section 3.1 for multi-tenancy engage in exactly the kind of behavior that RFC 5785 was designed to head off: it creates URLs all over the path space of the authority, rather than coralling all synthesized URLs to live under only one top-level directory. One of the key aspects of the principles of the web architecture is URI opacity , which generally precludes clients from synthesizing URLs. RFC 5785 was intended as a very limited carve-out to the principle of URI opacity, and was carefully limited to a single top-level path element. This specification oversteps that carve-out by exploding the location that "Well-Known" synthesized URLs can appear: it literally increases it from one location (the root) to infinite locations (at the end of any arbitrary path).

Fortunately, this defect is trivial to fix. Rather than placing .well-known path components *after* the path identified by an issuer identifier, you place them *before* it, which amends this document's usage to be within the spirit intended by RFC 5785. For example, the example in section 3.1:

    GET /issuer1/.well-known/oauth-authorization-server HTTP/1.1
    Host: example.com

Would instead become:

    GET /.well-known/oauth-authorization-server/issuer1 HTTP/1.1
    Host: example.com

_______
UPDATE

Author's response: https://www.ietf.org/mail-archive/web/oauth/current/msg17747.html
My response: https://www.ietf.org/mail-archive/web/oauth/current/msg17748.html
2018-01-23
08 Adam Roach Ballot discuss text updated for Adam Roach
2018-01-23
08 Ben Campbell [Ballot comment]
-1.1: There are lower case versions of 2119 keywords. Please consider using the boilerplate from 8174.
2018-01-23
08 Ben Campbell [Ballot Position Update] New position, Yes, has been recorded for Ben Campbell
2018-01-23
08 Alia Atlas [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas
2018-01-23
08 Kathleen Moriarty [Ballot Position Update] New position, Yes, has been recorded for Kathleen Moriarty
2018-01-23
08 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2018-01-23
08 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2018-01-22
08 Adam Roach
[Ballot discuss]
Thanks to everyone who worked on this specification. I think it's well-written, clear, and useful. I fully endorse publication, and intend to ballot …
[Ballot discuss]
Thanks to everyone who worked on this specification. I think it's well-written, clear, and useful. I fully endorse publication, and intend to ballot "yes" once we come to an agreement on the issue I describe below.

The problem I'm running into is the URL synthesis rules described in section 3.1 for multi-tenancy engage in exactly the kind of behavior that RFC 5785 was designed to head off: it creates URLs all over the path space of the authority, rather than coralling all synthesized URLs to live under only one top-level directory. One of the key aspects of the principles of the web architecture is URI opacity , which generally precludes clients from synthesizing URLs. RFC 5785 was intended as a very limited carve-out to the principle of URI opacity, and was carefully limited to a single top-level path element. This specification oversteps that carve-out by exploding the location that "Well-Known" synthesized URLs can appear: it literally increases it from one location (the root) to infinite locations (at the end of any arbitrary path).

Fortunately, this defect is trivial to fix. Rather than placing .well-known path components *after* the path identified by an issuer identifier, you place them *before* it, which amends this document's usage to be within the spirit intended by RFC 5785. For example, the example in section 3.1:

    GET /issuer1/.well-known/oauth-authorization-server HTTP/1.1
    Host: example.com

Would instead become:

    GET /.well-known/oauth-authorization-server/issuer1 HTTP/1.1
    Host: example.com
2018-01-22
08 Adam Roach
[Ballot comment]
Section 1.1: [this is an editorial suggestion that I leave to the editors' discretion] This document makes use of uncapitalized "must", "should", and …
[Ballot comment]
Section 1.1: [this is an editorial suggestion that I leave to the editors' discretion] This document makes use of uncapitalized "must", "should", and "may" in places. Please consider using the RFC 8174 boilerplate instead of the RFC 2119 boilerplate.

Section 7.2: [this is an important procedural comment that really should be resolved prior to publication] The addition of restrictions to registries established by RFC 6749 would seem to require that this document formally include "Updates: RFC6749" in its metadata, as well as a mention of such an update in its Abstract and Introduction sections.
2018-01-22
08 Adam Roach [Ballot Position Update] New position, Discuss, has been recorded for Adam Roach
2018-01-22
08 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2018-01-19
08 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2018-01-18
08 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2018-01-18
08 Eric Rescorla Ballot has been issued
2018-01-18
08 Eric Rescorla [Ballot Position Update] New position, Yes, has been recorded for Eric Rescorla
2018-01-18
08 Eric Rescorla Created "Approve" ballot
2017-12-28
08 Brian Carpenter Request for Telechat review by GENART Completed: Ready. Reviewer: Brian Carpenter. Sent review to list.
2017-12-28
08 Jean Mahoney Request for Telechat review by GENART is assigned to Brian Carpenter
2017-12-28
08 Jean Mahoney Request for Telechat review by GENART is assigned to Brian Carpenter
2017-12-27
08 Eric Rescorla Placed on agenda for telechat - 2018-01-25
2017-12-27
08 Eric Rescorla IESG state changed to IESG Evaluation from Waiting for Writeup
2017-11-15
08 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2017-11-15
08 Michael Jones New version available: draft-ietf-oauth-discovery-08.txt
2017-11-15
08 (System) New version approved
2017-11-15
08 (System) Request for posting confirmation emailed to previous authors: Nat Sakimura , John Bradley , Michael Jones
2017-11-15
08 Michael Jones Uploaded new revision
2017-10-27
07 Sabrina Tanamal IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2017-10-26
07 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Donald Eastlake.
2017-10-23
07 Gunter Van de Velde Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Shwetha Bhandari.
2017-10-09
07 (System) IESG state changed to Waiting for Writeup from In Last Call
2017-10-03
07 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2017-10-03
07 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-oauth-discovery-07. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-oauth-discovery-07. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there are three actions which we must complete.

A new registry is to be created called the OAuth Authorization Server Metadata registry. The new registry will be located on the OAuth Parameters registry page located at

http://www.iana.org/assignments/oauth-parameters/

The new registry is to be managed via Specification Required as defined in [ RFC 8126 ]. There are initial registrations in the new registry as follows:

Metadata Name: "issuer"
Metadata Description: Authorization server's issuer identifier URL
Change Controller: IESG
Specification Document(s): Section 2 of [ RFC-to-be ]

Metadata Name: "authorization_endpoint"
Metadata Description: URL of the authorization server's authorization endpoint
Change Controller: IESG
Specification Document(s): Section 2 of [ RFC-to-be ]

Metadata Name: "token_endpoint"
Metadata Description: URL of the authorization server's token endpoint
Change Controller: IESG
Specification Document(s): Section 2 of [ RFC-to-be ]

Metadata Name: "jwks_uri"
Metadata Description: URL of the authorization server's JWK Set document
Change Controller: IESG
Specification Document(s): Section 2 of [ RFC-to-be ]

Metadata Name: "registration_endpoint"
Metadata Description: URL of the authorization server's OAuth 2.0 Dynamic Client Registration Endpoint
Change Controller: IESG
Specification Document(s): Section 2 of [ RFC-to-be ]

Metadata Name: "scopes_supported"
Metadata Description: JSON array containing a list of the OAuth 2.0 "scope" values that this authorization server supports
Change Controller: IESG
Specification Document(s): Section 2 of [ RFC-to-be ]

Metadata Name: "response_types_supported"
Metadata Description: JSON array containing a list of the OAuth 2.0 "response_type" values that this authorization server supports
Change Controller: IESG
Specification Document(s): Section 2 of [ RFC-to-be ]

Metadata Name: "response_modes_supported"
Metadata Description: JSON array containing a list of the OAuth 2.0 "response_mode" values that this authorization server supports
Change Controller: IESG
Specification Document(s): Section 2 of [ RFC-to-be ]

Metadata Name: "grant_types_supported"
Metadata Description: JSON array containing a list of the OAuth 2.0 grant type values that this authorization server supports
Change Controller: IESG
Specification Document(s): Section 2 of [ RFC-to-be ]

Metadata Name: "token_endpoint_auth_methods_supported"
Metadata Description: JSON array containing a list of client authentication methods supported by this token endpoint
Change Controller: IESG
Specification Document(s): Section 2 of [ RFC-to-be ]

Metadata Name: "token_endpoint_auth_signing_alg_values_supported"
Metadata Description: JSON array containing a list of the JWS signing algorithms supported by the token endpoint for the signature on the JWT used to authenticate the client at the token endpoint
Change Controller: IESG
Specification Document(s): Section 2 of [ RFC-to-be ]

Metadata Name: "service_documentation"
Metadata Description: URL of a page containing human-readable information that developers might want or need to know when using the authorization server
Change Controller: IESG
Specification Document(s): Section 2 of [ RFC-to-be ]

Metadata Name: "ui_locales_supported"
Metadata Description: Languages and scripts supported for the user interface, represented as a JSON array of BCP47 language tag values
Change Controller: IESG
Specification Document(s): Section 2 of [ RFC-to-be ]

Metadata Name: "op_policy_uri"
Metadata Description: URL that the authorization server provides to the person registering the client to read about the authorization server's requirements on how the client can use the data provided by the authorization server
Change Controller: IESG
Specification Document(s): Section 2 of [ RFC-to-be ]

Metadata Name: "op_tos_uri"
Metadata Description: URL that the authorization server provides to the person registering the client to read about the authorization server's terms of service
Change Controller: IESG
Specification Document(s): Section 2 of [ RFC-to-be ]

Metadata Name: "revocation_endpoint"
Metadata Description: URL of the authorization server's OAuth 2.0 revocation endpoint
Change Controller: IESG
Specification Document(s): Section 2 of [ RFC-to-be ]

Metadata Name: "revocation_endpoint_auth_methods_supported"
Metadata Description: JSON array containing a list of client authentication methods supported by this revocation endpoint
Change Controller: IESG
Specification Document(s): Section 2 of [ RFC-to-be ]

Metadata Name:
"revocation_endpoint_auth_signing_alg_values_supported"
Metadata Description: JSON array containing a list of the JWS signing algorithms supported by the revocation endpoint for the signature on the JWT used to authenticate the client at the revocation endpoint
Change Controller: IESG
Specification Document(s): Section 2 of [ RFC-to-be ]

Metadata Name: "introspection_endpoint"
Metadata Description: URL of the authorization server's OAuth 2.0 introspection endpoint
Change Controller: IESG
Specification Document(s): Section 2 of [ RFC-to-be ]

Metadata Name: "introspection_endpoint_auth_methods_supported"
Metadata Description: JSON array containing a list of client authentication methods supported by this introspection endpoint
Change Controller: IESG
Specification Document(s): Section 2 of [ RFC-to-be ]

Metadata Name: "introspection_endpoint_auth_signing_alg_values_supported"
Metadata Description: JSON array containing a list of the JWS signing algorithms supported by the introspection endpoint for the signature on the JWT used to authenticate the client at the introspection endpoint
Change Controller: IESG
Specification Document(s): Section 2 of [ RFC-to-be ]

Metadata Name: "code_challenge_methods_supported"
Metadata Description: PKCE code challenge methods supported by this authorization server
Change Controller: IESG
Specification Document(s): Section 2 of [ RFC-to-be ]

Second, in both the OAuth Access Token Types registry and the OAuth Token Endpoint Authentication Methods registries located the OAuth Parameters registry page located at

http://www.iana.org/assignments/oauth-parameters/

a link to [ RFC-to-be ] will be added to the reference for each registry.

Third, in the Well-Known URIs registry located at:

https://www.iana.org/assignments/well-known-uris/

a new URI is to be added as follows:

URI suffix: "oauth-authorization-server"
Change controller: IESG
Reference: Section 3 of [ RFC-to-be ]
Related information:

Because this registry requires Expert Review [RFC8126] for registration, we've contacted the IESG-designated expert in a separate ticket to request approval. Expert review should be completed before your document can be approved for publication as an RFC.

The IANA Services Operator understands that these three actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.


Thank you,

Sabrina Tanamal
IANA Services Specialist
2017-10-01
07 Brian Carpenter Request for Last Call review by GENART Completed: Ready. Reviewer: Brian Carpenter. Sent review to list.
2017-09-28
07 Jean Mahoney Request for Last Call review by GENART is assigned to Brian Carpenter
2017-09-28
07 Jean Mahoney Request for Last Call review by GENART is assigned to Brian Carpenter
2017-09-28
07 Tero Kivinen Request for Last Call review by SECDIR is assigned to Donald Eastlake
2017-09-28
07 Tero Kivinen Request for Last Call review by SECDIR is assigned to Donald Eastlake
2017-09-26
07 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Shwetha Bhandari
2017-09-26
07 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Shwetha Bhandari
2017-09-25
07 Cindy Morgan IANA Review state changed to IANA - Review Needed
2017-09-25
07 Cindy Morgan
The following Last Call announcement was sent out (ends 2017-10-09):

From: The IESG
To: IETF-Announce
CC: ekr@rtfm.com, oauth@ietf.org, draft-ietf-oauth-discovery@ietf.org, Hannes Tschofenig , …
The following Last Call announcement was sent out (ends 2017-10-09):

From: The IESG
To: IETF-Announce
CC: ekr@rtfm.com, oauth@ietf.org, draft-ietf-oauth-discovery@ietf.org, Hannes Tschofenig , Hannes.Tschofenig@gmx.net, oauth-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (OAuth 2.0 Authorization Server Metadata) to Proposed Standard


The IESG has received a request from the Web Authorization Protocol WG
(oauth) to consider the following document: - 'OAuth 2.0 Authorization Server
Metadata'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-10-09. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This specification defines a metadata format that an OAuth 2.0 client
  can use to obtain the information needed to interact with an OAuth
  2.0 authorization server, including its endpoint locations and
  authorization server capabilities.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-oauth-discovery/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-oauth-discovery/ballot/


No IPR declarations have been submitted directly on this I-D.




2017-09-25
07 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2017-09-25
07 Cindy Morgan Last call announcement was generated
2017-09-23
07 Eric Rescorla Last call was requested
2017-09-23
07 Eric Rescorla Last call announcement was generated
2017-09-23
07 Eric Rescorla IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2017-09-23
07 Eric Rescorla Ballot writeup was changed
2017-09-23
07 Eric Rescorla Ballot approval text was generated
2017-09-07
07 (System) Sub state has been changed to AD Followup from Revised ID Needed
2017-09-07
07 Michael Jones New version available: draft-ietf-oauth-discovery-07.txt
2017-09-07
07 (System) New version approved
2017-09-07
07 (System) Request for posting confirmation emailed to previous authors: Nat Sakimura , Michael Jones , John Bradley
2017-09-07
07 Michael Jones Uploaded new revision
2017-09-03
06 Eric Rescorla IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2017-06-17
06 Eric Rescorla IESG state changed to AD Evaluation from Publication Requested
2017-04-10
06 Hannes Tschofenig
Shepherd Write-Up for "OAuth 2.0 Authorization Server Metadata"


(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  …
Shepherd Write-Up for "OAuth 2.0 Authorization Server Metadata"


(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

This specification is targeting a 'Proposed Standard'. The
type of RFC is indicated and contains protocols elements.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This specification defines a metadata format that an OAuth 2.0 client
  can use to obtain the information needed to interact with an OAuth
  2.0 authorization server, including its endpoint locations and
  authorization server capabilities.

Working Group Summary

  Work on a discovery mechanism for OAuth was planned since a long
  time but it took till late 2015 before a document was submitted
  to the group, which re-used work done in the OpenID Foundation.
  When the WGLC was started in 2016, see
  https://www.ietf.org/mail-archive/web/oauth/current/msg15796.html,
  feedback resulted in refocusing the scope of the specification,
  removing everything except for the authorization server metadata.

  Now, almost a year later these concerns have been resolved and
  the document is ready for publication.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

  The document scope has been changed to capture current deployment
  practice.

  There are 34 authorization server and 9 OAuth client implementations
  listed at http://openid.net/certification/ that implement metadata
  compatible with the AS metadata specification.
  (See the "Config OP" and "Config RP" columns.)

  Microsoft and Google are using this specification in deployment.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Hannes Tschofenig is the document shepherd and the responsible area
director is Kathleen Moriarty.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The document shepherd was involved in the working group review process
and verified the document for correctness.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 

There are no concerns regarding the document reviews.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

This document would benefit from security and internationalization reviews.
Particularly Section 4 of the document explaining string operations
deserves a review.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

The document shepherd has no concerns with the document.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

The authors have confirmed full conformance with the provisions of BCP 78
and BCP 79:

John: https://www.ietf.org/mail-archive/web/oauth/current/msg17060.html
Mike: https://www.ietf.org/mail-archive/web/oauth/current/msg17061.html
Nat: https://www.ietf.org/mail-archive/web/oauth/current/msg17185.html

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR disclosures have been filed for this document.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

There is consensus in the working group for publishing this
document.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

Nobody threatened an appeal or expressed extreme discontent with the
current version of the document.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

The shepherd checked the document.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No formal review is needed.

(13) Have all references within this document been identified as
either normative or informative?

Yes. The references are split into normative and informative references.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

The RFCs listed in the normative reference section are all finalized.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

There are four normative references to non-IETF specifications:

  [UNICODE]  The Unicode Consortium, "The Unicode Standard",
              .

  [USA15]    Davis, M. and K. Whistler, "Unicode Normalization Forms",
              Unicode Standard Annex 15, June 2015,
              .

  [OAuth.Post]
              Jones, M. and B. Campbell, "OAuth 2.0 Form Post Response
              Mode", April 2015, .

  [OAuth.Responses]
              de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M.
              Jones, "OAuth 2.0 Multiple Response Type Encoding
              Practices", February 2014, .

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

This document does not change the status of an existing RFC.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

This document does not request any actions by IANA.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

None.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

There is no text in formal languages in the document.
2017-04-10
06 Hannes Tschofenig
Shepherd Write-Up for "OAuth 2.0 Authorization Server Metadata"


(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  …
Shepherd Write-Up for "OAuth 2.0 Authorization Server Metadata"


(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

This specification is targeting a 'Proposed Standard'. The
type of RFC is indicated and contains protocols elements.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This specification defines a metadata format that an OAuth 2.0 client
  can use to obtain the information needed to interact with an OAuth
  2.0 authorization server, including its endpoint locations and
  authorization server capabilities.

Working Group Summary

  Work on a discovery mechanism for OAuth was planned since a long
  time but it took till late 2015 before a document was submitted
  to the group, which re-used work done in the OpenID Foundation.
  When the WGLC was started in 2016, see
  https://www.ietf.org/mail-archive/web/oauth/current/msg15796.html,
  feedback resulted in refocusing the scope of the specification,
  removing everything except for the authorization server metadata.

  Now, almost a year later these concerns have been resolved and
  the document is ready for publication.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

  The document scope has been changed to capture current deployment
  practice.

  There are 34 authorization server and 9 OAuth client implementations
  listed at http://openid.net/certification/ that implement metadata
  compatible with the AS metadata specification.
  (See the "Config OP" and "Config RP" columns.)

  Microsoft and Google are using this specification in deployment.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Hannes Tschofenig is the document shepherd and the responsible area
director is Kathleen Moriarty.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The document shepherd was involved in the working group review process
and verified the document for correctness.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 

There are no concerns regarding the document reviews.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

This document would benefit from security and internationalization reviews.
Particularly Section 4 of the document explaining string operations
deserves a review.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

The document shepherd has no concerns with the document.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

The authors have confirmed full conformance with the provisions of BCP 78
and BCP 79:

John: https://www.ietf.org/mail-archive/web/oauth/current/msg17060.html
Mike: https://www.ietf.org/mail-archive/web/oauth/current/msg17061.html
Nat: TBD

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR disclosures have been filed for this document.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

There is consensus in the working group for publishing this
document.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

Nobody threatened an appeal or expressed extreme discontent with the
current version of the document.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

The shepherd checked the document.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No formal review is needed.

(13) Have all references within this document been identified as
either normative or informative?

Yes. The references are split into normative and informative references.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

The RFCs listed in the normative reference section are all finalized.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

There are four normative references to non-IETF specifications:

  [UNICODE]  The Unicode Consortium, "The Unicode Standard",
              .

  [USA15]    Davis, M. and K. Whistler, "Unicode Normalization Forms",
              Unicode Standard Annex 15, June 2015,
              .

  [OAuth.Post]
              Jones, M. and B. Campbell, "OAuth 2.0 Form Post Response
              Mode", April 2015, .

  [OAuth.Responses]
              de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M.
              Jones, "OAuth 2.0 Multiple Response Type Encoding
              Practices", February 2014, .

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

This document does not change the status of an existing RFC.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

This document does not request any actions by IANA.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

None.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

There is no text in formal languages in the document.
2017-04-10
06 Hannes Tschofenig Responsible AD changed to Eric Rescorla
2017-04-10
06 Hannes Tschofenig IETF WG state changed to Submitted to IESG for Publication from WG Document
2017-04-10
06 Hannes Tschofenig IESG state changed to Publication Requested
2017-04-10
06 Hannes Tschofenig IESG process started in state Publication Requested
2017-04-10
06 Hannes Tschofenig Changed document writeup
2017-04-10
06 Hannes Tschofenig Changed consensus to Yes from Unknown
2017-04-10
06 Hannes Tschofenig Intended Status changed to Proposed Standard from None
2017-04-10
06 Hannes Tschofenig Notification list changed to Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
2017-04-10
06 Hannes Tschofenig Document shepherd changed to Hannes Tschofenig
2017-03-10
06 Michael Jones New version available: draft-ietf-oauth-discovery-06.txt
2017-03-10
06 (System) New version approved
2017-03-10
06 (System) Request for posting confirmation emailed to previous authors: Nat Sakimura , John Bradley , oauth-chairs@ietf.org, Michael Jones
2017-03-10
06 Michael Jones Uploaded new revision
2017-01-19
05 Michael Jones New version available: draft-ietf-oauth-discovery-05.txt
2017-01-19
05 (System) New version approved
2017-01-19
05 (System) Request for posting confirmation emailed to previous authors: "Nat Sakimura" , "Michael Jones" , oauth-chairs@ietf.org, "John Bradley"
2017-01-19
05 Michael Jones Uploaded new revision
2016-11-22
04 Hannes Tschofenig Added to session: IETF-97: oauth  Mon-0930
2016-08-03
04 Michael Jones New version available: draft-ietf-oauth-discovery-04.txt
2016-07-08
03 Michael Jones New version available: draft-ietf-oauth-discovery-03.txt
2016-03-21
02 Michael Jones New version available: draft-ietf-oauth-discovery-02.txt
2016-02-17
01 Michael Jones New version available: draft-ietf-oauth-discovery-01.txt
2016-02-09
00 Hannes Tschofenig This document now replaces draft-jones-oauth-discovery instead of None
2016-02-09
00 Michael Jones New version available: draft-ietf-oauth-discovery-00.txt