OAuth 2.0 Protected Resource Metadata
draft-ietf-oauth-resource-metadata-13
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2024-10-23
|
13 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2024-10-23
|
13 | Jean Mahoney | Request closed, assignment withdrawn: Jouni Korhonen Last Call GENART review |
2024-10-23
|
13 | Jean Mahoney | Closed request for Last Call review by GENART with state 'Overtaken by Events' |
2024-10-23
|
13 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2024-10-23
|
13 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2024-10-22
|
13 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2024-10-18
|
13 | Carlos Pignataro | Closed request for Last Call review by OPSDIR with state 'Overtaken by Events' |
2024-10-18
|
13 | Carlos Pignataro | Assignment of request for Last Call review by OPSDIR to Bo Wu was marked no-response |
2024-10-17
|
13 | (System) | RFC Editor state changed to EDIT |
2024-10-17
|
13 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2024-10-17
|
13 | (System) | Announcement was received by RFC Editor |
2024-10-16
|
13 | (System) | IANA Action state changed to In Progress |
2024-10-16
|
13 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2024-10-16
|
13 | Cindy Morgan | IESG has approved the document |
2024-10-16
|
13 | Cindy Morgan | Closed "Approve" ballot |
2024-10-16
|
13 | Cindy Morgan | Ballot approval text was generated |
2024-10-16
|
13 | Cindy Morgan | Ballot writeup was changed |
2024-10-16
|
13 | (System) | Removed all action holders (IESG state changed) |
2024-10-16
|
13 | Deb Cooley | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2024-10-15
|
13 | Michael Jones | New version available: draft-ietf-oauth-resource-metadata-13.txt |
2024-10-15
|
13 | Michael Jones | New version approved |
2024-10-15
|
13 | (System) | Request for posting confirmation emailed to previous authors: Aaron Parecki , Michael Jones , Phil Hunt |
2024-10-15
|
13 | Michael Jones | Uploaded new revision |
2024-10-10
|
12 | Murray Kucherawy | [Ballot comment] On the flipside, I appreciate that so much good guidance was given to the Designated Experts and even to us on how we … [Ballot comment] On the flipside, I appreciate that so much good guidance was given to the Designated Experts and even to us on how we should go about selecting them. It would be helpful if candidates could be nominated (if that hasn't already happened) for approval by the IESG. As rendered on the datatracker's HTML page, the numerous initial entries in Section 8.1.2 are all run together. Could we get them separated? In Section 2, why is "resource_name" only RECOMMENDED? In Section 2.1, second paragraph, the RECOMMENDED and SHOULD seem bare to me. Why would we allow anything other than what's specified, especially since BCP 47 prescribes a particular behavior? Section 4 of BCP 26 says: [...] Newly minted policies, including ones that combine the elements of procedures associated with these terms in novel ways, may be used if none of these policies are suitable; it will help the review process if an explanation is included as to why that is the case. I strongly suggest including a sentence or two in your IANA Considerations that explains the innovated registration policy being created here. I would also recommend saying something about the possibility of a registration being made against the promise of a future specification that, in the end, never actually appears. |
2024-10-10
|
12 | Murray Kucherawy | [Ballot Position Update] Position for Murray Kucherawy has been changed to No Objection from Discuss |
2024-10-03
|
12 | (System) | Changed action holders to Deb Cooley (IESG state changed) |
2024-10-03
|
12 | (System) | Sub state has been changed to AD Followup from Revised I-D Needed |
2024-10-03
|
12 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2024-10-03
|
12 | Michael Jones | New version available: draft-ietf-oauth-resource-metadata-12.txt |
2024-10-03
|
12 | Michael Jones | New version approved |
2024-10-03
|
12 | (System) | Request for posting confirmation emailed to previous authors: Aaron Parecki , Michael Jones , Phil Hunt |
2024-10-03
|
12 | Michael Jones | Uploaded new revision |
2024-10-03
|
11 | (System) | Changed action holders to Phil Hunt, Aaron Parecki, Michael Jones (IESG state changed) |
2024-10-03
|
11 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2024-10-03
|
11 | Francesca Palombini | [Ballot comment] Thank you for this document. Many thanks to Mike Bishop for the HTTPDIR review. One more IANA point. Section 8 states: > Registration … [Ballot comment] Thank you for this document. Many thanks to Mike Bishop for the HTTPDIR review. One more IANA point. Section 8 states: > Registration requests that are undetermined for a period longer than 21 days can be brought to the IESG's attention (using the iesg@ietf.org mailing list) for resolution. Maybe it is me not being a native speaker, but it is not clear to me what is requested of the IESG. If the goal is to add a "IESG Approval" (see https://www.rfc-editor.org/rfc/rfc8126#section-4.10 ), then it should be stated clearly, and by the way I do not think that is a good idea. If it is escalation, then IANA already has procedures in place for that, and I don't think this text adds anything to that. Can you expand? |
2024-10-03
|
11 | Francesca Palombini | [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini |
2024-10-02
|
11 | Éric Vyncke | [Ballot comment] Thanks for the document and thanks to Rifaat Shekh-Yusef for the shepherd write-up including the WG consensus and the justification of the intended … [Ballot comment] Thanks for the document and thanks to Rifaat Shekh-Yusef for the shepherd write-up including the WG consensus and the justification of the intended status. As a Belgian French-speaking person, I smiled when reading `using fr might be sufficient in many contexts, rather than fr-CA or fr-FR` :-) More seriously, should the examples in section 3.1 use a more recent HTTP version ? Superb use of SVG in section 5, suggest to introduce the "AS" acronym used in step 6 in the text below the figure (this comment could possibly apply to other acronyms). Finally, I agree with John and Murray about their comments about the IANA section. |
2024-10-02
|
11 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2024-10-02
|
11 | Murray Kucherawy | [Ballot discuss] I concur strongly enough with John Scudder's comment about the IANA registry that I'd like to discuss it. Moreover, Section 4 of BCP … [Ballot discuss] I concur strongly enough with John Scudder's comment about the IANA registry that I'd like to discuss it. Moreover, Section 4 of BCP 26 says: [...] Newly minted policies, including ones that combine the elements of procedures associated with these terms in novel ways, may be used if none of these policies are suitable; it will help the review process if an explanation is included as to why that is the case. Is that explanation available anywhere? I think John's right, this is a peculiar loophole, and it would be helpful to know why the WG thinks this is necessary. There's already a debate in progress about whether an I-D (which expires) is viable in a Specification Required registry, and we're about to charter a WG to revise BCP 26, so this is actually quite topical. |
2024-10-02
|
11 | Murray Kucherawy | [Ballot comment] On the flipside, I appreciate that so much good guidance was given to the Designated Experts and even to us on how we … [Ballot comment] On the flipside, I appreciate that so much good guidance was given to the Designated Experts and even to us on how we should go about selecting them. It would be helpful if candidates could be nominated (if that hasn't already happened) for approval by the IESG. As rendered on the datatracker's HTML page, the numerous initial entries in Section 8.1.2 are all run together. Could we get them separated? In Section 2, why is "resource_name" only RECOMMENDED? In Section 2.1, second paragraph, the RECOMMENDED and SHOULD seem bare to me. Why would we allow anything other than what's specified, especially since BCP 47 prescribes a particular behavior? |
2024-10-02
|
11 | Murray Kucherawy | [Ballot Position Update] New position, Discuss, has been recorded for Murray Kucherawy |
2024-10-02
|
11 | John Scudder | [Ballot comment] Thanks for the well-written document. I have a couple of comments — - Section 1 “This use of WWW-Authenticate can indicate that the … [Ballot comment] Thanks for the well-written document. I have a couple of comments — - Section 1 “This use of WWW-Authenticate can indicate that the protected resource metadata MAY have changed.” That’s a misuse of the RFC 2119 MAY. You aren’t specifying procedure here, so you should be using lowercase “may”. This recurs in Section 5.2, “its metadata MAY have changed”. - In Section 8, you say the registration policy is Specification Required, but then you go on to say “However, to allow for the allocation of values prior to publication, the Designated Experts may approve registration once they are satisfied that such a specification will be published.” As far as I can tell, that is not compatible with the plain language of the policy called “Specification Required“ as described in RFC 8126. I also wonder how the experts could possibly do a proper review if all they have to look at is an IOU for a specification. |
2024-10-02
|
11 | John Scudder | [Ballot Position Update] New position, No Objection, has been recorded for John Scudder |
2024-10-02
|
11 | Orie Steele | [Ballot comment] Thanks for addressing my comments. I'm clearing my discuss: https://mailarchive.ietf.org/arch/msg/oauth/1VFHst9xvvP6AxW3lmwemx0mLCU/ |
2024-10-02
|
11 | Orie Steele | [Ballot Position Update] Position for Orie Steele has been changed to No Objection from Discuss |
2024-10-02
|
11 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2024-10-02
|
11 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2024-10-02
|
11 | Michael Jones | New version available: draft-ietf-oauth-resource-metadata-11.txt |
2024-10-02
|
11 | Michael Jones | New version approved |
2024-10-02
|
11 | (System) | Request for posting confirmation emailed to previous authors: Aaron Parecki , Michael Jones , Phil Hunt |
2024-10-02
|
11 | Michael Jones | Uploaded new revision |
2024-10-02
|
10 | Zaheduzzaman Sarker | [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker |
2024-10-01
|
10 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2024-10-01
|
10 | Paul Wouters | [Ballot comment] La mia bella recensione resource_signing_alg_values_supported No default algorithms are implied if this entry is omitted. What does this imply? … [Ballot comment] La mia bella recensione resource_signing_alg_values_supported No default algorithms are implied if this entry is omitted. What does this imply? Does it mean a value can be supplied later? Or that the request will never be able to succeed? In Section 5.1 there is an error message, but unlike earlier in the document, there seems to be no language support here. I guess that is a shortcoming of RFC6750. I am also interested to hear the response to Orie's DISCUSS |
2024-10-01
|
10 | Paul Wouters | [Ballot Position Update] New position, No Objection, has been recorded for Paul Wouters |
2024-10-01
|
10 | Orie Steele | [Ballot discuss] ## Discuss ### Forbidden Query & Fragment ``` 175 The Protected resource's resource identifier, which is a URL that 176 … [Ballot discuss] ## Discuss ### Forbidden Query & Fragment ``` 175 The Protected resource's resource identifier, which is a URL that 176 uses the https scheme and has no query or fragment components. ``` I can understand the decision to keep fragment off, per: https://url.spec.whatwg.org/#url-equivalence But I don't understand why query is forbidden, especially considering: https://datatracker.ietf.org/doc/html/rfc3986#section-3.4 I would expect query to be allowed, and for some comment about canonical URI encoding based on query ordering to be made. I assume query is omitted to make processing rules described in Section 3 simpler... This also restricts the set of existing resources which this specification could apply to... and implies that resource identifiers that are URLs do not contain queries. It seems like a specification should be able to describe transformation rules that use query or hostname rewriting, even if the current spec sees no need to use query or hostname structures, why should other specifications be forbidden from doing so? For an example: https://example.com/oauth-protected-resource https://example.com/.well-known/oauth-protected-resource vs https://oauth-protected.example.com/.well-known/fancy-index?key=value https://example.com/.well-known/oauth-protected?key=value... I searched github and the mailing list to see if there was discussion regarding this, please point it out if I somehow missed it. |
2024-10-01
|
10 | Orie Steele | [Ballot comment] # Orie Steele, ART AD, comments for draft-ietf-oauth-resource-metadata-10 CC @OR13 * line numbers: - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-oauth-resource-metadata-10.txt&submitcheck=True * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md * … [Ballot comment] # Orie Steele, ART AD, comments for draft-ietf-oauth-resource-metadata-10 CC @OR13 * line numbers: - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-oauth-resource-metadata-10.txt&submitcheck=True * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md * "Handling Ballot Positions": - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ ## Comments Thanks to Arnt Gulbrandsen for the ART ART review. ### JSON Serialization Forbidden? ``` 158 Compact Serialization or the JWE Compact Serialization; the JWS JSON 159 Serialization and the JWE JSON Serialization are not used. ``` This is descriptive, but I wonder if there is an intention to enable better interoperability by explicitly forbidding JSON Serialization. ### signed_metadata in JWT claims ``` 346 JWT. A signed_metadata metadata value SHOULD NOT appear as a 347 claim in the JWT. ``` When this should is ignored what happens? Raise and error or ignore? ### media type of response ``` 425 configuration. A successful response MUST use the 200 OK HTTP status 426 code and return a JSON object using the application/json content type 427 that contains a set of claims as its members that are a subset of the 428 metadata values defined in Section 2. Other claims MAY also be 429 returned. ``` Based on the last sentence, it seems like the metadata resource is intended to be extended, should it be possible to negotiate its extended representations? Why restrict the media type to "application/json" ? ### Identical URIs ``` 460 metadata. If these values are not identical, the data contained in 461 the response MUST NOT be used. ``` Consider being more precise regarding what "identical" means here, see the URL equivalence section of WHATWG URL spec for example: https://url.spec.whatwg.org/#url-equivalence I also wonder if URL patterns are useful here... https://urlpattern.spec.whatwg.org/ You might also consider calling out Section 6 here. ## Nits ### Missing owner? ``` 627 At any point, for any reason determined by the protected resource, 628 the protected resource MAY respond with a new WWW-Authenticate ``` |
2024-10-01
|
10 | Orie Steele | [Ballot Position Update] New position, Discuss, has been recorded for Orie Steele |
2024-09-30
|
10 | Jim Guichard | [Ballot Position Update] New position, No Objection, has been recorded for Jim Guichard |
2024-09-30
|
10 | Roman Danyliw | [Ballot comment] ** Section 2.2 signed_metadata A JWT containing metadata values about the protected resource as claims. This … [Ballot comment] ** Section 2.2 signed_metadata A JWT containing metadata values about the protected resource as claims. This is a string value consisting of the entire signed JWT. A signed_metadata metadata value SHOULD NOT appear as a claim in the JWT. If signed_metadata appears as a claim, what should be done with it? ** Section 7.1 Implementations SHOULD follow the guidance in BCP 195 [RFC8996] [RFC9325], which provides recommendations and requirements for improving the security of deployed services that use TLS. Why can’t this document require (MUST) conformance to BCP 195 and delegate responsibility to maintaining those recommendations to the BCP? ** Section 7.3 TLS certificate checking MUST be performed by the client, as described in Section 7.1, What guidance in Section 7.1 discusses TLS certificate checking? ** Section 8.1.1 Change Controller: For Standards Track RFCs, list the "IETF". Wouldn’t “IETF” be listed for all RFCs in the IETF stream? ** Section 8.3.1 * URI suffix: oauth-protected-resource * Change controller: IETF * Specification document: Section 3 of [[ this specification ]] * Related information: (none) For editorial clarity, https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml uses “Reference” not “Specification document”. Consider harmonizing the column names. |
2024-09-30
|
10 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2024-09-27
|
10 | Mike Bishop | Request for Telechat review by HTTPDIR Completed: Ready with Issues. Reviewer: Mike Bishop. Sent review to list. |
2024-09-27
|
10 | Gunter Van de Velde | [Ballot Position Update] New position, No Objection, has been recorded for Gunter Van de Velde |
2024-09-23
|
10 | Mark Nottingham | Request for Telechat review by HTTPDIR is assigned to Mike Bishop |
2024-09-23
|
10 | Francesca Palombini | Requested Telechat review by HTTPDIR |
2024-09-16
|
10 | Michael Jones | New version available: draft-ietf-oauth-resource-metadata-10.txt |
2024-09-16
|
10 | Michael Jones | New version approved |
2024-09-16
|
10 | (System) | Request for posting confirmation emailed to previous authors: Aaron Parecki , Michael Jones , Phil Hunt |
2024-09-16
|
10 | Michael Jones | Uploaded new revision |
2024-09-15
|
09 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2024-09-14
|
09 | Deb Cooley | Placed on agenda for telechat - 2024-10-03 |
2024-09-14
|
09 | Deb Cooley | Ballot has been issued |
2024-09-14
|
09 | Deb Cooley | [Ballot Position Update] New position, Yes, has been recorded for Deb Cooley |
2024-09-14
|
09 | Deb Cooley | Created "Approve" ballot |
2024-09-14
|
09 | Deb Cooley | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2024-09-13
|
09 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2024-09-13
|
09 | Michael Jones | New version available: draft-ietf-oauth-resource-metadata-09.txt |
2024-09-13
|
09 | Michael Jones | New version approved |
2024-09-13
|
09 | (System) | Request for posting confirmation emailed to previous authors: Aaron Parecki , Michael Jones , Phil Hunt |
2024-09-13
|
09 | Michael Jones | Uploaded new revision |
2024-08-29
|
08 | Bo Wu | Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Bo Wu. Sent review to list. |
2024-08-27
|
08 | David Dong | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2024-08-27
|
08 | David Dong | The Well-Known URIs and OAuth Authorization Server Metadata registrations have been approved. |
2024-08-27
|
08 | David Dong | IANA Experts State changed to Expert Reviews OK from Reviews assigned |
2024-08-26
|
08 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2024-08-23
|
08 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2024-08-23
|
08 | David Dong | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: IANA has completed its review of draft-ietf-oauth-resource-metadata-08. If any part of this review is inaccurate, please let us know. The … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: IANA has completed its review of draft-ietf-oauth-resource-metadata-08. If any part of this review is inaccurate, please let us know. The IANA understands that, upon approval of this document, there are three actions which we must complete. We also have a question about the first action. First, a new registry is to be created called the OAuth Protected Resource Metadata registry. The new registry will be located in the OAuth Parameters registry group located at: https://www.iana.org/assignments/oauth-parameters/ The new registry will be managed by Specification Required as defined in [RFC8126]. All registrations in the new registry will be subject to a two week mailing list review as defined in [ RFC-to-be ]. There are initial registrations in the new registry as follows: Metadata Name: resource Metadata Description: Protected resource's resource identifier URL Change Controller: IETF Specification Document(s): [ RFC-to-be; Section 2 ] Metadata Name: authorization_servers Metadata Description: JSON array containing a list of OAuth authorization server issuer identifiers Change Controller: IETF Specification Document(s): [ RFC-to-be; Section 2 ] Metadata Name: jwks_uri Metadata Description: URL of the protected resource's JWK Set document Change Controller: IETF Specification Document(s): [ RFC-to-be; Section 2 ] Metadata Name: scopes_supported Metadata Description: JSON array containing a list of the OAuth 2.0 scope values that are used in authorization requests to request access this protected resource Change Controller: IETF Specification Document(s): [ RFC-to-be; Section 2 ] Metadata Name: bearer_methods_supported Metadata Description: JSON array containing a list of the OAuth 2.0 Bearer Token presentation methods that this protected resource supports Change Controller: IETF Specification Document(s): [ RFC-to-be; Section 2 ] Metadata Name: resource_signing_alg_values_supported Metadata Description: JSON array containing a list of the JWS signing algorithms (alg values) supported by the protected resource for signed content Change Controller: IETF Specification Document(s): [ RFC-to-be; Section 2 ] Metadata Name: resource_documentation Metadata Description: URL of a page containing human-readable information that developers might want or need to know when using the protected resource Change Controller: IETF Specification Document(s): [ RFC-to-be; Section 2 ] Metadata Name: resource_policy_uri Metadata Description: URL that the protected resource provides to read about the protected resource's requirements on how the client can use the data provided by the protected resource Change Controller: IETF Specification Document(s): [ RFC-to-be; Section 2 ] Metadata Name: resource_tos_uri Metadata Description: URL that the protected resource provides to read about the protected resource's terms of service Change Controller: IETF Specification Document(s): [ RFC-to-be; Section 2 ] Metadata Name: signed_metadata Metadata Description: Signed JWT containing metadata values about the protected resource as claims Change Controller: IETF Specification Document(s): [ RFC-to-be; Section 2.1 ] IANA Question -> Is there a missing "to" in the Metadata Description for "scopes_supported"? "JSON array containing a list of the OAuth 2.0 scope values that are used in authorization requests to request access [to] this protected resource". Second, in the OAuth Authorization Server Metadata registry also in the OAuth Parameters registry group located at: https://www.iana.org/assignments/oauth-parameters/ A single new registration will be made as follows: Metadata Name: protected_resources Metadata Description: JSON array containing a list of resource identifiers for OAuth protected resources Change Controller: IETF Specification Document(s): [ RFC-to-be; Section 4 ] As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK." Third, in the Well-Known URIs registry located at: https://www.iana.org/assignments/well-known-uris/ A single registration will be made as follows: URI Suffix: oauth-protected-resource Change Controller: IETF Reference: [ RFC-to-be; Section 3 ] Status: permanent Related Information: Date Registered: [ TBD-at-Registration ] Date Modified: As this also requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we have initiated and completed the required Expert Review via a separate request. We understand 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 meant only to confirm the list of actions that will be performed. For definitions of IANA review states, please see: https://datatracker.ietf.org/help/state/draft/iana-review Thank you, David Dong IANA Services Sr. Specialist |
2024-08-22
|
08 | Carlos Pignataro | Request for Last Call review by OPSDIR is assigned to Bo Wu |
2024-08-22
|
08 | Carlos Pignataro | Request for Last Call review by OPSDIR is assigned to Bo Wu |
2024-08-16
|
08 | David Mandelberg | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: David Mandelberg. Sent review to list. |
2024-08-15
|
08 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to David Mandelberg |
2024-08-15
|
08 | David Dong | The Well-Known URIs registration has been approved. |
2024-08-15
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Jouni Korhonen |
2024-08-14
|
08 | Arnt Gulbrandsen | Request for Last Call review by ARTART Completed: Ready with Nits. Reviewer: Arnt Gulbrandsen. |
2024-08-13
|
08 | David Dong | IANA Experts State changed to Reviews assigned |
2024-08-13
|
08 | Barry Leiba | Request for Last Call review by ARTART is assigned to Arnt Gulbrandsen |
2024-08-12
|
08 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2024-08-12
|
08 | Cindy Morgan | The following Last Call announcement was sent out (ends 2024-08-26): From: The IESG To: IETF-Announce CC: debcooley1@gmail.com, draft-ietf-oauth-resource-metadata@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org, rifaat.s.ietf@gmail.com … The following Last Call announcement was sent out (ends 2024-08-26): From: The IESG To: IETF-Announce CC: debcooley1@gmail.com, draft-ietf-oauth-resource-metadata@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org, rifaat.s.ietf@gmail.com Reply-To: last-call@ietf.org Sender: Subject: Last Call: (OAuth 2.0 Protected Resource 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 Protected Resource 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 last-call@ietf.org mailing lists by 2024-08-26. 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 or authorization server can use to obtain the information needed to interact with an OAuth 2.0 protected resource. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-metadata/ No IPR declarations have been submitted directly on this I-D. |
2024-08-12
|
08 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2024-08-12
|
08 | Deb Cooley | Last call was requested |
2024-08-12
|
08 | Deb Cooley | Last call announcement was generated |
2024-08-12
|
08 | Deb Cooley | Ballot approval text was generated |
2024-08-12
|
08 | Deb Cooley | Ballot writeup was generated |
2024-08-12
|
08 | Deb Cooley | IESG state changed to Last Call Requested from AD Evaluation |
2024-08-12
|
08 | Michael Jones | New version available: draft-ietf-oauth-resource-metadata-08.txt |
2024-08-12
|
08 | (System) | New version approved |
2024-08-12
|
08 | (System) | Request for posting confirmation emailed to previous authors: Aaron Parecki , Michael Jones , Phil Hunt |
2024-08-12
|
08 | Michael Jones | Uploaded new revision |
2024-08-09
|
07 | Deb Cooley | IESG state changed to AD Evaluation from Publication Requested |
2024-07-29
|
07 | Rifaat Shekh-Yusef | ## Document History 1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did … ## Document History 1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement? There was a broad support for this document. 2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? No such controversy. 3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize 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.) No such threats. 4. For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as [RFC 7942][3] recommends) or elsewhere (where)? OpenID Federation implementations use the Protected Resource Metadata definitions in this specification. Connect2ID and Authlete have OpenID Federation implementations. Italian SPID CIE national federation. ## Additional Reviews 5. Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place. No 6. Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. None is needed, as no new types are defined by this document. 7. If the document contains a YANG module, has the final version of the module been checked with any of the [recommended validation tools][4] for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in [RFC 8342][5]? No YANG model 8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc. There is no formal language in the document. ## Document Shepherd Checks 9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director? Yes, the document is well written and addresses a specific need. 10. Several IETF Areas have assembled [lists of common issues that their reviewers encounter][6]. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews? Not applicable 11. What type of RFC publication is being requested on the IETF stream ([Best Current Practice][12], [Proposed Standard, Internet Standard][13], [Informational, Experimental or Historic][14])? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent? Standards Track, as this is a defined a metadata format to be used by resource servers, and a mechanims to access thia metadata. 12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in [BCP 79][7]? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable. All authors provided their IP disclosure on the mailing list: Mike: https://mailarchive.ietf.org/arch/msg/oauth/NZNmDtAlC3gYUb46u25NuYUpFeM/ Phil: https://mailarchive.ietf.org/arch/msg/oauth/f3Elb9jKQ461Fvv1YuRTU9nRJPw/ Aaron: https://mailarchive.ietf.org/arch/msg/oauth/CNthgap0GMMzI7A7acm5AJxOHCM/ 13. Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front page is greater than five, please provide a justification. Yes 14. Document any remaining I-D nits in this document. Simply running the [idnits tool][8] is not enough; please review the ["Content Guidelines" on authors.ietf.org][15]. (Also note that the current idnits tool generates some incorrect warnings; a rewrite is underway.) The authors addressed the nits identified in the shepherd review. 15. Should any informative references be normative or vice-versa? See the [IESG Statement on Normative and Informative References][16]. No 16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? All normative references are freely available. 17. Are there any normative downward references (see [RFC 3967][9] and [BCP 97][10]) that are not already listed in the [DOWNREF registry][17]? If so, list them. No such references. 18. Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state? If so, what is the plan for their completion? No such references. 19. Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed. No change to existing RFCs. 20. 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 aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see [RFC 8126][11]). The IANA consideration section is consistent with the body of the document. 21. List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate. The document establishes the new IANA "OAuth Protected Resource Metadata" registry. The document provides clear instruction to the desginated expert. [1]: https://www.ietf.org/about/groups/iesg/ [2]: https://www.rfc-editor.org/rfc/rfc4858.html [3]: https://www.rfc-editor.org/rfc/rfc7942.html [4]: https://wiki.ietf.org/group/ops/yang-review-tools [5]: https://www.rfc-editor.org/rfc/rfc8342.html [6]: https://wiki.ietf.org/group/iesg/ExpertTopics [7]: https://www.rfc-editor.org/info/bcp79 [8]: https://www.ietf.org/tools/idnits/ [9]: https://www.rfc-editor.org/rfc/rfc3967.html [10]: https://www.rfc-editor.org/info/bcp97 [11]: https://www.rfc-editor.org/rfc/rfc8126.html [12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5 [13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1 [14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2 [15]: https://authors.ietf.org/en/content-guidelines-overview [16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/ [17]: https://datatracker.ietf.org/doc/downref/ |
2024-07-29
|
07 | Rifaat Shekh-Yusef | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2024-07-29
|
07 | Rifaat Shekh-Yusef | IESG state changed to Publication Requested from I-D Exists |
2024-07-29
|
07 | (System) | Changed action holders to Deb Cooley (IESG state changed) |
2024-07-29
|
07 | Rifaat Shekh-Yusef | Responsible AD changed to Deb Cooley |
2024-07-29
|
07 | Rifaat Shekh-Yusef | Document is now in IESG state Publication Requested |
2024-07-29
|
07 | Rifaat Shekh-Yusef | Changed consensus to Yes from Unknown |
2024-07-29
|
07 | Rifaat Shekh-Yusef | Intended Status changed to Proposed Standard from None |
2024-07-22
|
07 | Michael Jones | New version available: draft-ietf-oauth-resource-metadata-07.txt |
2024-07-22
|
07 | Michael Jones | New version approved |
2024-07-22
|
07 | (System) | Request for posting confirmation emailed to previous authors: Aaron Parecki , Michael Jones , Phil Hunt |
2024-07-22
|
07 | Michael Jones | Uploaded new revision |
2024-07-17
|
06 | Rifaat Shekh-Yusef | ## Document History 1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did … ## Document History 1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement? There was a broad support for this document. 2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? No such controversy. 3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize 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.) No such threats. 4. For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as [RFC 7942][3] recommends) or elsewhere (where)? OpenID Federation implementations use the Protected Resource Metadata definitions in this specification. Connect2ID and Authlete have OpenID Federation implementations. Italian SPID CIE national federation. ## Additional Reviews 5. Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place. No 6. Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. None is needed, as no new types are defined by this document. 7. If the document contains a YANG module, has the final version of the module been checked with any of the [recommended validation tools][4] for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in [RFC 8342][5]? No YANG model 8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc. There is no formal language in the document. ## Document Shepherd Checks 9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director? Yes, the document is well written and addresses a specific need. 10. Several IETF Areas have assembled [lists of common issues that their reviewers encounter][6]. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews? Not applicable 11. What type of RFC publication is being requested on the IETF stream ([Best Current Practice][12], [Proposed Standard, Internet Standard][13], [Informational, Experimental or Historic][14])? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent? Standards Track, as this is a defined a metadata format to be used by resource servers, and a mechanims to access thia metadata. 12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in [BCP 79][7]? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable. All authors provided their IP disclosure on the mailing list: Mike: https://mailarchive.ietf.org/arch/msg/oauth/NZNmDtAlC3gYUb46u25NuYUpFeM/ Phil: https://mailarchive.ietf.org/arch/msg/oauth/f3Elb9jKQ461Fvv1YuRTU9nRJPw/ Aaron: https://mailarchive.ietf.org/arch/msg/oauth/CNthgap0GMMzI7A7acm5AJxOHCM/ 13. Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front page is greater than five, please provide a justification. Yes 14. Document any remaining I-D nits in this document. Simply running the [idnits tool][8] is not enough; please review the ["Content Guidelines" on authors.ietf.org][15]. (Also note that the current idnits tool generates some incorrect warnings; a rewrite is underway.) The authors addressed the nits identified in the shepherd review. 15. Should any informative references be normative or vice-versa? See the [IESG Statement on Normative and Informative References][16]. No 16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? All normative references are freely available. 17. Are there any normative downward references (see [RFC 3967][9] and [BCP 97][10]) that are not already listed in the [DOWNREF registry][17]? If so, list them. No such references. 18. Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state? If so, what is the plan for their completion? No such references. 19. Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed. No change to existing RFCs. 20. 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 aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see [RFC 8126][11]). The IANA consideration section is consistent with the body of the document. 21. List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate. The document establishes the new IANA "OAuth Protected Resource Metadata" registry. The document provides clear instruction to the desginated expert. [1]: https://www.ietf.org/about/groups/iesg/ [2]: https://www.rfc-editor.org/rfc/rfc4858.html [3]: https://www.rfc-editor.org/rfc/rfc7942.html [4]: https://wiki.ietf.org/group/ops/yang-review-tools [5]: https://www.rfc-editor.org/rfc/rfc8342.html [6]: https://wiki.ietf.org/group/iesg/ExpertTopics [7]: https://www.rfc-editor.org/info/bcp79 [8]: https://www.ietf.org/tools/idnits/ [9]: https://www.rfc-editor.org/rfc/rfc3967.html [10]: https://www.rfc-editor.org/info/bcp97 [11]: https://www.rfc-editor.org/rfc/rfc8126.html [12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5 [13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1 [14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2 [15]: https://authors.ietf.org/en/content-guidelines-overview [16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/ [17]: https://datatracker.ietf.org/doc/downref/ |
2024-07-08
|
06 | Michael Jones | New version available: draft-ietf-oauth-resource-metadata-06.txt |
2024-07-08
|
06 | Michael Jones | New version approved |
2024-07-08
|
06 | (System) | Request for posting confirmation emailed to previous authors: Aaron Parecki , Michael Jones , Phil Hunt |
2024-07-08
|
06 | Michael Jones | Uploaded new revision |
2024-06-10
|
05 | Rifaat Shekh-Yusef | Notification list changed to rifaat.s.ietf@gmail.com because the document shepherd was set |
2024-06-10
|
05 | Rifaat Shekh-Yusef | Document shepherd changed to Rifaat Shekh-Yusef |
2024-06-05
|
05 | Rifaat Shekh-Yusef | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2024-05-03
|
05 | Michael Jones | New version available: draft-ietf-oauth-resource-metadata-05.txt |
2024-05-03
|
05 | Michael Jones | New version approved |
2024-05-03
|
05 | (System) | Request for posting confirmation emailed to previous authors: Aaron Parecki , Michael Jones , Phil Hunt |
2024-05-03
|
05 | Michael Jones | Uploaded new revision |
2024-04-26
|
04 | Michael Jones | New version available: draft-ietf-oauth-resource-metadata-04.txt |
2024-04-26
|
04 | Michael Jones | New version accepted (logged-in submitter: Michael Jones) |
2024-04-26
|
04 | Michael Jones | Uploaded new revision |
2024-03-27
|
03 | Rifaat Shekh-Yusef | IETF WG state changed to In WG Last Call from WG Document |
2024-03-15
|
03 | Rifaat Shekh-Yusef | Added to session: IETF-119: oauth Tue-2330 |
2024-02-01
|
03 | Michael Jones | New version available: draft-ietf-oauth-resource-metadata-03.txt |
2024-02-01
|
03 | Michael Jones | New version approved |
2024-02-01
|
03 | (System) | Request for posting confirmation emailed to previous authors: Aaron Parecki , Michael Jones , Phil Hunt |
2024-02-01
|
03 | Michael Jones | Uploaded new revision |
2024-01-24
|
02 | Michael Jones | New version available: draft-ietf-oauth-resource-metadata-02.txt |
2024-01-24
|
02 | Michael Jones | New version approved |
2024-01-24
|
02 | (System) | Request for posting confirmation emailed to previous authors: Aaron Parecki , Michael Jones , Phil Hunt |
2024-01-24
|
02 | Michael Jones | Uploaded new revision |
2023-10-20
|
01 | Michael Jones | New version available: draft-ietf-oauth-resource-metadata-01.txt |
2023-10-20
|
01 | Aaron Parecki | New version approved |
2023-10-20
|
01 | (System) | Request for posting confirmation emailed to previous authors: Aaron Parecki , Michael Jones , Phil Hunt |
2023-10-20
|
01 | Michael Jones | Uploaded new revision |
2023-09-07
|
00 | Rifaat Shekh-Yusef | This document now replaces draft-jones-oauth-resource-metadata instead of None |
2023-09-06
|
00 | Michael Jones | New version available: draft-ietf-oauth-resource-metadata-00.txt |
2023-09-06
|
00 | Rifaat Shekh-Yusef | WG -00 approved |
2023-09-06
|
00 | Michael Jones | Set submitter to "Michael Jones ", replaces to (none) and sent approval email to group chairs: oauth-chairs@ietf.org |
2023-09-06
|
00 | Michael Jones | Uploaded new revision |