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 |