Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth)
draft-ietf-ace-oauth-authz-37
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2021-02-04 |
37 | Göran Selander | New version available: draft-ietf-ace-oauth-authz-37.txt |
2021-02-04 |
37 | (System) | New version accepted (logged-in submitter: Göran Selander) |
2021-02-04 |
37 | Göran Selander | Uploaded new revision |
2020-11-16 |
36 | Ludwig Seitz | New version available: draft-ietf-ace-oauth-authz-36.txt |
2020-11-16 |
36 | (System) | New version approved |
2020-11-16 |
36 | (System) | Request for posting confirmation emailed to previous authors: Samuel Erdtman <erdtman@spotify.com>, Ludwig Seitz <ludwig.seitz@combitech.se>, Goeran Selander <goran.selander@ericsson.com>, Hannes Tschofenig <hannes.tschofenig@arm.com>, Erik Wahlstroem <erik@wahlstromstekniska.se> |
2020-11-16 |
36 | Ludwig Seitz | Uploaded new revision |
2020-06-24 |
35 | Ludwig Seitz | New version available: draft-ietf-ace-oauth-authz-35.txt |
2020-06-24 |
35 | (System) | New version approved |
2020-06-24 |
35 | (System) | Request for posting confirmation emailed to previous authors: Erik Wahlstroem <erik@wahlstromstekniska.se>, Ludwig Seitz <ludwig.seitz@combitech.se>, Goeran Selander <goran.selander@ericsson.com>, Samuel Erdtman <erdtman@spotify.com>, Hannes Tschofenig <hannes.tschofenig@arm.com> |
2020-06-24 |
35 | Ludwig Seitz | Uploaded new revision |
2020-06-22 |
34 | Ludwig Seitz | New version available: draft-ietf-ace-oauth-authz-34.txt |
2020-06-22 |
34 | (System) | New version approved |
2020-06-22 |
34 | (System) | Request for posting confirmation emailed to previous authors: Hannes Tschofenig <hannes.tschofenig@arm.com>, Goeran Selander <goran.selander@ericsson.com>, Ludwig Seitz <ludwig.seitz@combitech.se>, Erik Wahlstroem <erik@wahlstromstekniska.se>, Samuel Erdtman <erdtman@spotify.com> |
2020-06-22 |
34 | Ludwig Seitz | Uploaded new revision |
2020-04-28 |
33 | Benjamin Kaduk | IETF LC comments are all addressed. I don't have full data on whether IANA has all the needed approvals, but they will look again when … IETF LC comments are all addressed. I don't have full data on whether IANA has all the needed approvals, but they will look again when this goes on a telechat. Putting in "external party" since we are waiting to have the cluster of four documents go to the IESG together. |
2020-04-28 |
33 | Benjamin Kaduk | IESG state changed to Waiting for Writeup::External Party from Waiting for Writeup::AD Followup |
2020-02-06 |
33 | Ludwig Seitz | New version available: draft-ietf-ace-oauth-authz-33.txt |
2020-02-06 |
33 | (System) | New version approved |
2020-02-06 |
33 | (System) | Request for posting confirmation emailed to previous authors: Hannes Tschofenig <hannes.tschofenig@arm.com>, Goeran Selander <goran.selander@ericsson.com>, Samuel Erdtman <erdtman@spotify.com>, Ludwig Seitz <ludwig.seitz@combitech.se>, Erik Wahlstroem <erik@wahlstromstekniska.se> |
2020-02-06 |
33 | Ludwig Seitz | Uploaded new revision |
2020-02-03 |
32 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'Overtaken by Events' |
2020-02-01 |
32 | Ludwig Seitz | New version available: draft-ietf-ace-oauth-authz-32.txt |
2020-02-01 |
32 | (System) | New version approved |
2020-02-01 |
32 | (System) | Request for posting confirmation emailed to previous authors: Hannes Tschofenig <hannes.tschofenig@arm.com>, Goeran Selander <goran.selander@ericsson.com>, Samuel Erdtman <erdtman@spotify.com>, Ludwig Seitz <ludwig.seitz@combitech.se>, Erik Wahlstroem <erik@wahlstromstekniska.se> |
2020-02-01 |
32 | Ludwig Seitz | Uploaded new revision |
2020-01-19 |
31 | Gunter Van de Velde | Assignment of request for Last Call review by OPSDIR to Victor Kuarsingh was marked no-response |
2020-01-18 |
31 | Ludwig Seitz | New version available: draft-ietf-ace-oauth-authz-31.txt |
2020-01-18 |
31 | (System) | New version approved |
2020-01-18 |
31 | (System) | Request for posting confirmation emailed to previous authors: Hannes Tschofenig <hannes.tschofenig@arm.com>, Goeran Selander <goran.selander@ericsson.com>, Samuel Erdtman <erdtman@spotify.com>, Ludwig Seitz <ludwig.seitz@combitech.se>, Erik Wahlstroem <erik@wahlstromstekniska.se> |
2020-01-18 |
31 | Ludwig Seitz | Uploaded new revision |
2020-01-11 |
30 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2020-01-11 |
30 | Ludwig Seitz | New version available: draft-ietf-ace-oauth-authz-30.txt |
2020-01-11 |
30 | (System) | New version approved |
2020-01-11 |
30 | (System) | Request for posting confirmation emailed to previous authors: Hannes Tschofenig <hannes.tschofenig@arm.com>, Goeran Selander <goran.selander@ericsson.com>, Samuel Erdtman <erdtman@spotify.com>, Ludwig Seitz <ludwig.seitz@combitech.se>, Erik Wahlstroem <erik@wahlstromstekniska.se> |
2020-01-11 |
30 | Ludwig Seitz | Uploaded new revision |
2020-01-07 |
29 | Benjamin Kaduk | IESG state changed to Waiting for Writeup::Revised I-D Needed from Waiting for Writeup |
2019-12-14 |
29 | Ludwig Seitz | New version available: draft-ietf-ace-oauth-authz-29.txt |
2019-12-14 |
29 | (System) | New version approved |
2019-12-14 |
29 | (System) | Request for posting confirmation emailed to previous authors: Hannes Tschofenig <hannes.tschofenig@arm.com>, Goeran Selander <goran.selander@ericsson.com>, Samuel Erdtman <erdtman@spotify.com>, Ludwig Seitz <ludwig.seitz@combitech.se>, Erik Wahlstroem <erik@wahlstromstekniska.se> |
2019-12-14 |
29 | Ludwig Seitz | Uploaded new revision |
2019-12-14 |
28 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2019-12-14 |
28 | Ludwig Seitz | New version available: draft-ietf-ace-oauth-authz-28.txt |
2019-12-14 |
28 | (System) | New version approved |
2019-12-14 |
28 | (System) | Request for posting confirmation emailed to previous authors: ace-chairs@ietf.org, Erik Wahlstroem <erik@wahlstromstekniska.se>, Ludwig Seitz <ludwig.seitz@ri.se>, Hannes Tschofenig <hannes.tschofenig@arm.com>, Goeran Selander <goran.selander@ericsson.com>, Samuel Erdtman <erdtman@spotify.com> |
2019-12-14 |
28 | Ludwig Seitz | Uploaded new revision |
2019-12-13 |
27 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2019-12-13 |
27 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-ace-oauth-authz-27. If any part of this review is inaccurate, please let us … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-ace-oauth-authz-27. If any part of this review is inaccurate, please let us know. The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document. The IANA Functions Operator understands that, upon approval of this document, there are fifteen actions which we must complete. NOTE: We’re asking the ADs how to handle the registrations for which Hannes is the only reviewer. IANA Question --> Several sections of the current draft propose to create new registries (Sections 8.1, 8.3, 8.4, 8.6, 8.7, 8.9, and 8.11). For each of these requests, IANA asks the authors where the new registries are to be located. Should they be added to an existing registry page? If not, do they belong in an existing category at http://www.iana.org/protocols? For each of the new registries, it is not clear from the context of the request where the new registries should be established. First, a new registry is to be created called the ACE Authorization Server Request Creation Hints registry. The new registry will be established in a location to be determined later. IANA Question --> What is the range of values possible for CBOR Keys? The registration rules for the new registry are as follows: < 65536 : Private Use -65536 to -257 : Specification Required -256 to 255 : Standards Action 256 to 65535 : Specification Required There are initial registrations in the new registry as follows: +-----------+----------+---------------------+---------------| | Name | CBOR Key | Value Type | Reference | |-----------+----------+---------------------|---------------| | AS | 1 | text string | [ RFC-to-be ] | | kid | 2 | byte string | [ RFC-to-be ] | | unassigned| 3-4 | | | | audience | 5 | text string | [ RFC-to-be ] | | unassigned| 6-8 | | | | scope | 9 | text or byte string | [ RFC-to-be ] | | unassigned| 10-38 | | | | cnonce | 39 | byte string | [ RFC-to-be ] | +-----------+----------+---------------------+---------------+ Second, in the OAuth Extensions Error Registry on the OAuth Parameters registry page located at: https://www.iana.org/assignments/oauth-parameters/ the following two registrations will be made: Name: unsupported_pop_key Usage Location: token error response Protocol Extension: The ACE framework [ RFC-to-be ] Change Controller: IESG Reference: [ RFC-to-be Section 5.6.3] Name: incompatible_profiles Usage Location: token error response Protocol Extension: The ACE framework [ RFC-to-be ] Change Controller: IESG Reference: [ RFC-to-be Section 5.6.3] As this section requests registrations in a Specification Required (see RFC 8126) registry, the IESG-designated expert for the OAuth Extensions Error Registry has asked that you send a review request to the mailing list oauth-ext-review@ietf.org. This review must be completed before the document's IANA state can be changed to "IANA OK." Third, a new registry is to be created called the OAuth Error Code CBOR Mappings registry. The new registry will be established in a location to be determined later. IANA Question --> What is the range of values possible for CBOR Values? The registration rules for the new registry are as follows: < -65536 : Private Use All other values : Expert Review There are initial assignments in the new registry as follows: +------------------------+-------------+---------------+ | Name | CBOR Values | Reference | |------------------------+-------------|---------------| | invalid_request | 1 | [ RFC-to-be ] | | invalid_client | 2 | [ RFC-to-be ] | | invalid_grant | 3 | [ RFC-to-be ] | | unauthorized_client | 4 | [ RFC-to-be ] | | unsupported_grant_type | 5 | [ RFC-to-be ] | | invalid_scope | 6 | [ RFC-to-be ] | | unsupported_pop_key | 7 | [ RFC-to-be ] | | incompatible_profiles | 8 | [ RFC-to-be ] | +------------------------+-------------+---------------+ Fourth, a new registry is to be created called the OAuth Grant Type CBOR Mappings registry. The new registry will be established in a location to be determined later. IANA Question --> What is the range of values possible for CBOR Values? The registration rules for the new registry are as follows: < -65536 : Private Use All other values : Expert Review There are initial assignments in the new registry as follows: +--------------------+------------+---------------+---------------+ | Name | CBOR Value | Original | Reference | | | | Specification | | |--------------------+------------+---------------+---------------| | password | 0 | RFC6749 | [ RFC-to-be ] | | authorization_code | 1 | RFC6749 | [ RFC-to-be ] | | client_credentials | 2 | RFC6749 | [ RFC-to-be ] | | refresh_token | 3 | RFC6749 | [ RFC-to-be ] | +--------------------+------------+---------------+---------------+ Fifth, in the OAuth Access Token Types registry on the OAuth Parameters registry page located at: https://www.iana.org/assignments/oauth-parameters/ the following, single registration will be made: Type name: PoP Additional Token Endpoint Response Parameters: cnf, rs_cnf HTTP Authentication Scheme(s): N/A Change Controller: IESG Reference: [ RFC-to-be ] As this section also requests a registration in a Specification Required (see RFC 8126) registry, the IESG-designated expert for the OAuth Access Token Types Registry has asked that you send a review request to the mailing list oauth-ext-review@ietf.org. This review must be completed before the document's IANA state can be changed to "IANA OK." Sixth, a new registry is to be created called the OAuth Access Token Type CBOR Mappings registry. The new registry will be established in a location to be determined later. IANA Question --> What is the range of values possible for CBOR Values? The registration rules for the new registry are as follows: < -65536 : Private Use All other values : Expert Review There are initial assignments in the new registry as follows: +--------+--------+---------------+-----------------+ | Name | CBOR | Reference | Original | | | Value | | Specification | +--------+--------+---------------+-----------------+ | Bearer | 1 | [ RFC-to-be ] | RFC6749 | | PoP | 2 | [ RFC-to-be ] | [ RFC-to-be ] | +--------+--------+---------------+-----------------+ Seventh, a new registry is to be created called the ACE Profile registry. The new registry will be established in a location to be determined later. IANA Question --> What is the range of values possible for CBOR Keys? The registration rules for the new registry are as follows: < 65536 : Private Use -65536 to -257 : Specification Required -256 to 255 : Standards Action 256 to 65535 : Specification Required Initially, this registry will be empty. Eighth, in the OAuth Parameters registry on the OAuth Parameters registry page located at: https://www.iana.org/assignments/oauth-parameters/ the following, single registration will be made: Name: ace_profile Parameter Usage Location: token response Change Controller: IESG Reference: [ RFC-to-be Section 5.6.4.3] As this section also requests a registration in a Specification Required (see RFC 8126) registry, the IESG-designated expert for the OAuth Parameters Registry has asked that you send a review request to the mailing list oauth-ext-review@ietf.org. This review must be completed before the document's IANA state can be changed to "IANA OK." Ninth, a new registry is to be created called the OAuth Parameters CBOR Mappings registry. The new registry will be established in a location to be determined later. IANA Question --> What is the range of values possible for CBOR Values? The registration rules for the new registry are as follows: < -65536 : Private Use All other values : Expert Review There are initial assignments in the new registry as follows: +-------------------+----------+---------------------+---------------+ | Name | CBOR Key | Value Type | Reference | |-------------------+----------+---------------------|---------------| | access_token | 1 | byte string | [ RFC-to-be ] | | expires_in | 2 | unsigned integer | [ RFC-to-be ] | | unassigned | 3-4 | | | | audience | 5 | text string | [ RFC-to-be ] | | unassigned | 6-8 | | | | scope | 9 | text or byte string | [ RFC-to-be ] | | unassigned | 10-23 | | | | client_id | 24 | text string | [ RFC-to-be ] | | client_secret | 25 | byte string | [ RFC-to-be ] | | response_type | 26 | text string | [ RFC-to-be ] | | redirect_uri | 27 | text string | [ RFC-to-be ] | | state | 28 | text string | [ RFC-to-be ] | | code | 29 | byte string | [ RFC-to-be ] | | error | 30 | unsigned integer | [ RFC-to-be ] | | error_description | 31 | text string | [ RFC-to-be ] | | error_uri | 32 | text string | [ RFC-to-be ] | | grant_type | 33 | unsigned integer | [ RFC-to-be ] | | token_type | 34 | unsigned integer | [ RFC-to-be ] | | username | 35 | text string | [ RFC-to-be ] | | password | 36 | text string | [ RFC-to-be ] | | refresh_token | 37 | byte string | [ RFC-to-be ] | | ace_profile | 38 | unsigned integer | [ RFC-to-be ] | | cnonce | 39 | byte string | [ RFC-to-be ] | +-------------------+----------+---------------------+---------------+ Tenth, in the OAuth Parameters registry on the OAuth Token Introspection Response registry page located at: https://www.iana.org/assignments/oauth-parameters/ the following, single registration will be made: Name: ace_profile Description: The communication and communication security profile used between client and RS, as defined in ACE profiles. Change Controller: IESG Reference: [ RFC-to-be Section 5.7.2] As this section also requests a registration in a Specification Required (see RFC 8126) registry, the IESG-designated experts for the OAuth Token Introspection Response Registry have asked that you send a review request to the mailing list oauth-ext-review@ietf.org. This review must be completed before the document's IANA state can be changed to "IANA OK." Eleventh, a new registry is to be created called the OAuth Token Introspection Response CBOR Mappings registry. The new registry will be established in a location to be determined later. IANA Question --> What is the range of values possible for CBOR Values? The registration rules for the new registry are as follows: < -65536 : Private Use All other values : Expert Review There are initial assignments in the new registry as follows: +-------------------+----------+-------------------------+---------------+ | Parameter name | CBOR Key | Value Type | Reference | |-------------------+----------+-------------------------|---------------+ | iss | 1 | text string | [ RFC-to-be ] | | sub | 2 | text string | [ RFC-to-be ] | | aud | 3 | text string | [ RFC-to-be ] | | exp | 4 | integer or | [ RFC-to-be ] | | | | floating-point number | [ RFC-to-be ] | | nbf | 5 | integer or | [ RFC-to-be ] | | | | floating-point number | [ RFC-to-be ] | | iat | 6 | integer or | [ RFC-to-be ] | | | | floating-point number | [ RFC-to-be ] | | cti | 7 | byte string | [ RFC-to-be ] | | unassigned | 8 | | | | scope | 9 | text or byte string | [ RFC-to-be ] | | active | 10 | True or False | [ RFC-to-be ] | | token | 11 | byte string | [ RFC-to-be ] | | unassigned | 12-23 | | | | client_id | 24 | text string | [ RFC-to-be ] | | unassigned | 25-29 | | | | error | 30 | unsigned integer | [ RFC-to-be ] | | error_description | 31 | text string | [ RFC-to-be ] | | error_uri | 32 | text string | [ RFC-to-be ] | | token_type_hint | 33 | text string | [ RFC-to-be ] | | token_type | 34 | text string | [ RFC-to-be ] | | username | 35 | text string | [ RFC-to-be ] | | unassigned | 36-37 | | | | ace_profile | 38 | unsigned integer | [ RFC-to-be ] | | cnonce | 39 | byte string | [ RFC-to-be ] | | exi | 40 | unsigned integer | [ RFC-to-be ] | +-------------------+----------+-------------------------+---------------| Twelfth, in the JSON Web Token Claims registry on the JSON Web Token (JWT) registry page located at: https://www.iana.org/assignments/jwt/ the following three registrations will be made: Claim Name: ace_profile Claim Description: The profile a token is supposed to be used with. Change Controller: IESG Reference: [ RFC-to-be Section 5.8] Claim Name: exi Claim Description: "Expires in". Lifetime of the token in seconds from the time the RS first sees it. Used to implement a weaker from of token expiration for devices that cannot synchronize their internal clocks. Change Controller: IESG Reference: [ RFC-to-be Section 5.8.3] Claim Name: cnonce Claim Description: "client-nonce". A nonce previously provided to the AS by the RS via the client. Used to verify token freshness when the RS cannot synchronize its clock with the AS. Change Controller: IESG Reference: [ RFC-to-be ] As this section also requests a registration in a Specification Required (see RFC 8126) registry, the IESG-designated experts for the JSON Web Token Claims Registry have asked that you send a review request to the mailing list jwt-reg-review@ietf.org. This review must be completed before the document's IANA state can be changed to "IANA OK." Thirteenth, in the CBOR Web Token (CWT) Claims registry located at: https://www.iana.org/assignments/cwt/ the following, four new registrations will be made: Claim Name: scope Claim Description: The scope of an access token as defined in [RFC6749]. JWT Claim Name: scope Claim Key: [ TBD-at-Registration ] Claim Value Type: byte string or text string Change Controller: IESG Reference: [I-D.ietf-oauth-token-exchange] Claim Name: ace_profile Claim Description: The profile a token is supposed to be used with. JWT Claim Name: ace_profile Claim Key: [ TBD-at-Registration ] Claim Value Type: integer Change Controller: IESG Reference: [ RFC-to-be Section 5.8] Claim Name: exi Claim Description: The expiration time of a token measured from when it was received at the RS in seconds. JWT Claim Name: exi Claim Key: [ TBD-at-Registration ] Claim Value Type: integer Change Controller: IESG Reference: [ RFC-to-be Section 5.8.3] Claim Name: cnonce Claim Description: The client-nonce sent to the AS by the RS via the client. JWT Claim Name: [ TBD-at-Registration ] Claim Key: cnonce Claim Value Type: byte string Change Controller: IESG Reference: [ RFC-to-be Section 5.8] IANA notes that the authors suggest Claim Key values for ace_profile (38), exi (40) and cnonce (39). As this section also requests a registration in a Specification Required (see RFC 8126) registry, the IESG-designated experts for the CBOR Web Token (CWT) Claims Registry have asked that you send a review request to the mailing list cwt-reg-review@ietf.org. This review must be completed before the document's IANA state can be changed to "IANA OK." Fourteenth, in the application registry on the Media Types registry located at: https://www.iana.org/assignments/media-types/ a single, new media type is to be registered as follows: Name: ace+cbor Template: [ TBD-at-Registration ] Reference: [ RFC-to-be ] Fifteenth, in the CoAP Content-Formats on the Constrained RESTful Environments (CoRE) Parameters registry page located at: https://www.iana.org/assignments/core-parameters/ the following, single registration will be made: Media Type: application/ace+cbor Encoding: ID: [ TBD-at-Registration ] Reference: [ RFC-to-be ] IANA notes that the authors have suggested a value of 19 for this registration. 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." The IANA Functions Operator understands that these are the only actions 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. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2019-12-13 |
27 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2019-12-12 |
27 | Stewart Bryant | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Stewart Bryant. Sent review to list. |
2019-12-08 |
27 | Stephen Kent | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Stephen Kent. Sent review to list. |
2019-12-05 |
27 | Jean Mahoney | Request for Last Call review by GENART is assigned to Stewart Bryant |
2019-12-05 |
27 | Jean Mahoney | Request for Last Call review by GENART is assigned to Stewart Bryant |
2019-12-05 |
27 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Stephen Kent |
2019-12-05 |
27 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Stephen Kent |
2019-12-05 |
27 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Victor Kuarsingh |
2019-12-05 |
27 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Victor Kuarsingh |
2019-11-29 |
27 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2019-11-29 |
27 | Amy Vezza | The following Last Call announcement was sent out (ends 2019-12-13): From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: ace-chairs@ietf.org, ietf@augustcellars.com, draft-ietf-ace-oauth-authz@ietf.org, Jim Schaad <ietf@augustcellars.com>, kaduk@mit.edu, … The following Last Call announcement was sent out (ends 2019-12-13): From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: ace-chairs@ietf.org, ietf@augustcellars.com, draft-ietf-ace-oauth-authz@ietf.org, Jim Schaad <ietf@augustcellars.com>, kaduk@mit.edu, ace@ietf.org Reply-To: last-call@ietf.org Sender: <iesg-secretary@ietf.org> Subject: Last Call: <draft-ietf-ace-oauth-authz-27.txt> (Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth)) to Proposed Standard The IESG has received a request from the Authentication and Authorization for Constrained Environments WG (ace) to consider the following document: - 'Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth)' <draft-ietf-ace-oauth-authz-27.txt> 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 2019-12-13. 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 framework for authentication and authorization in Internet of Things (IoT) environments called ACE- OAuth. The framework is based on a set of building blocks including OAuth 2.0 and CoAP, thus transforming a well-known and widely used authorization solution into a form suitable for IoT devices. Existing specifications are used where possible, but extensions are added and profiles are defined to better serve the IoT use cases. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/3123/ The document contains these normative downward references. See RFC 3967 for additional information: rfc4949: Internet Security Glossary, Version 2 (Informational - Independent Submission Editor stream) |
2019-11-29 |
27 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2019-11-29 |
27 | Amy Vezza | Last call announcement was changed |
2019-11-28 |
27 | Benjamin Kaduk | Last call was requested |
2019-11-28 |
27 | Benjamin Kaduk | Last call announcement was generated |
2019-11-28 |
27 | Benjamin Kaduk | Ballot approval text was generated |
2019-11-28 |
27 | Benjamin Kaduk | Ballot writeup was generated |
2019-11-28 |
27 | Benjamin Kaduk | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2019-11-20 |
27 | Ludwig Seitz | New version available: draft-ietf-ace-oauth-authz-27.txt |
2019-11-20 |
27 | (System) | New version approved |
2019-11-20 |
27 | (System) | Request for posting confirmation emailed to previous authors: Ludwig Seitz <ludwig.seitz@ri.se>, Hannes Tschofenig <hannes.tschofenig@arm.com>, Goeran Selander <goran.selander@ericsson.com>, Samuel Erdtman <erdtman@spotify.com>, Erik Wahlstroem <erik@wahlstromstekniska.se> |
2019-11-20 |
27 | Ludwig Seitz | Uploaded new revision |
2019-11-19 |
26 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-11-19 |
26 | Ludwig Seitz | New version available: draft-ietf-ace-oauth-authz-26.txt |
2019-11-19 |
26 | (System) | New version approved |
2019-11-19 |
26 | (System) | Request for posting confirmation emailed to previous authors: Ludwig Seitz <ludwig.seitz@ri.se>, Hannes Tschofenig <hannes.tschofenig@arm.com>, Goeran Selander <goran.selander@ericsson.com>, Samuel Erdtman <erdtman@spotify.com>, Erik Wahlstroem <erik@wahlstromstekniska.se> |
2019-11-19 |
26 | Ludwig Seitz | Uploaded new revision |
2019-11-12 |
25 | Benjamin Kaduk | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup |
2019-10-30 |
25 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-10-30 |
25 | Ludwig Seitz | New version available: draft-ietf-ace-oauth-authz-25.txt |
2019-10-30 |
25 | (System) | New version approved |
2019-10-30 |
25 | (System) | Request for posting confirmation emailed to previous authors: Ludwig Seitz <ludwig.seitz@ri.se>, Hannes Tschofenig <hannes.tschofenig@arm.com>, Goeran Selander <goran.selander@ericsson.com>, Samuel Erdtman <erdtman@spotify.com>, Erik Wahlstroem <erik@wahlstromstekniska.se> |
2019-10-30 |
25 | Ludwig Seitz | Uploaded new revision |
2019-09-26 |
24 | Benjamin Kaduk | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2019-07-29 |
24 | Benjamin Kaduk | IESG state changed to AD Evaluation from Publication Requested |
2019-03-27 |
24 | Ludwig Seitz | New version available: draft-ietf-ace-oauth-authz-24.txt |
2019-03-27 |
24 | (System) | New version approved |
2019-03-27 |
24 | (System) | Request for posting confirmation emailed to previous authors: Ludwig Seitz <ludwig.seitz@ri.se>, Hannes Tschofenig <hannes.tschofenig@arm.com>, Goeran Selander <goran.selander@ericsson.com>, Samuel Erdtman <erdtman@spotify.com>, Erik Wahlstroem <erik@wahlstromstekniska.se> |
2019-03-27 |
24 | Ludwig Seitz | Uploaded new revision |
2019-03-25 |
23 | Ludwig Seitz | New version available: draft-ietf-ace-oauth-authz-23.txt |
2019-03-25 |
23 | (System) | New version approved |
2019-03-25 |
23 | (System) | Request for posting confirmation emailed to previous authors: Ludwig Seitz <ludwig.seitz@ri.se>, Hannes Tschofenig <hannes.tschofenig@arm.com>, Goeran Selander <goran.selander@ericsson.com>, Samuel Erdtman <erdtman@spotify.com>, Erik Wahlstroem <erik@wahlstromstekniska.se> |
2019-03-25 |
23 | Ludwig Seitz | Uploaded new revision |
2019-03-11 |
22 | Jim Schaad | Added to session: IETF-104: ace Fri-1050 |
2019-03-05 |
22 | Jim Schaad | DATE 2 March 2019 - version -21 As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected … DATE 2 March 2019 - version -21 As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) Is should be a Proposed Standard and that is reflected in the meta information. (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 document describes a framework for the use of OAuth 2.0 in a constrained environment. The document is mainly targeted at the protocols defined for CoAP, but other protocols can be used as well. The framework defines the fields and symmantics needed for doing authorization and authenticiation of a client. Working Group Summary The concesus on the document wa generally very solid. There were some issues that arose between the ACE and OAuth working groups over a couple of issues. These issues appear to have been resolved. Document Quality There have been at least four different groups who have announced an implementation at some level of the specification. While two of those implementations share a certain amount of common code, there are two implementations which have done interop tests at various times which do not share any code based on this document. The scope and issues of trying to deal with some of the OAuth 2.0 documents can be challenging at times. While it is believed that a good job has been done, there are some potential areas where different people might end up doing new things. Personnel Jim Schaad is the Document Shepherd. Ben Kaduk is the responsible AD. (3) I have done a detailed read a number of times during the WGLC process and while shepherding to make sure all WGLC comments were addressed. Additionally, I have done an implementation of the document during development. (4) Between the implentations of the framework that we have and the healthy discussions during the WGLC, I am confident that there has been quite broad review of the document. (5) No broader review should be needed. During the process there has been significant review from the OAuth working group. (6) I have no issues with this specific document. I do have a problem with how the registries have been setup in OAuth, but that is not germane to this document. (7) All authors have indicated that they do no know of any additional IPR that needs to be disclosed. Ludwig 2/25/19 Goren 2/25/19 Erdtman 2/25/19 Hannes 2/27/19 (8) There is an IPR disclosure on this document. During the shepards review, I specifically requested if there were any concerns about this IPR and none were raised. (9) The set of people that have contributed probably represent about a dozen individuals in the WG. (10) There has been no extreme discontent expressed during the discussions. (11) No ID nits are called out. (12) The only formal review needed is for a new media type. The media type request for application/ace+cbor was mailed 23 Feb 2019. (13) All references are tagged and reasonable. (14) All of the normative documents which are in process are at the same stage of development and thus should not cause any issues. (15) There are no downward normative references. (16) This document represents the first iteration. It profiles and extends some of the OAuth documents, but this is not done by modifications of the documents themselves. (17) It was somewhat painful. I looked at all items that were defined and should be registered to make sure that they existed in the IANA considerations. I compared the registrations of items with the required templates or columns in the IANA registries. A detailed walk of the new registries along with reasonable behavior was examined. (18) The following new IANA registries are created: ACE Authorization Server Request Creation Hints - Contains a set of attributes to be returned from a resource server that can be used by a client when building the request to the authorization server. There is not currently an equivalent registry for OAuth so it is not clear that an OAuth person is going to be extremely useful. Some implementation experience would probably be useful, but is definitely not required. OAuth Error Code CBOR Mappings - Contains a mapping of errors that can be returned in OAuth. No special expertise should be required for the experts. OAuth Grant Type CBOR Mappings - Contains a mapping of grant types from the OAuth registry to a CBOR integer. No special expertise should be required for the experts. OAuth Access Token Type CBOR Mapping - Contains a mapping of token types from the OAuth registry to a CBOR integer. No special expertise should be required for the experts. ACE Profile - Contains the set of ACE profiles that use the framework. The experts should have a solid working knowledge of the framework as they need to be able to evaluate any new profile against the framework to make sure that all of the conditions outlined are fulfilled. OAuth Parameters CBOR Mapping - Contains the set of mappings from OAuth parameters to integer values. No special expertise should be required for the experts. OAuth Token Introspection Response CBOR Mappings - Contains the mapping of response parameters from the OAuth registry to a CBOR integer and type. No special expertise should be required for the experts. 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. (19) No automated checks were done. |
2019-03-05 |
22 | Jim Schaad | Responsible AD changed to Benjamin Kaduk |
2019-03-05 |
22 | Jim Schaad | IETF WG state changed to Submitted to IESG for Publication from In WG Last Call |
2019-03-05 |
22 | Jim Schaad | IESG state changed to Publication Requested from I-D Exists |
2019-03-05 |
22 | Jim Schaad | IESG process started in state Publication Requested |
2019-03-05 |
22 | Jim Schaad | Tag Revised I-D Needed - Issue raised by WGLC cleared. |
2019-03-05 |
22 | Ludwig Seitz | New version available: draft-ietf-ace-oauth-authz-22.txt |
2019-03-05 |
22 | (System) | New version approved |
2019-03-05 |
22 | (System) | Request for posting confirmation emailed to previous authors: Ludwig Seitz <ludwig.seitz@ri.se>, Hannes Tschofenig <hannes.tschofenig@arm.com>, Goeran Selander <goran.selander@ericsson.com>, Samuel Erdtman <erdtman@spotify.com>, Erik Wahlstroem <erik@wahlstromstekniska.se> |
2019-03-05 |
22 | Ludwig Seitz | Uploaded new revision |
2019-03-02 |
21 | Jim Schaad | DATE 2 March 2019 - version -21 As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected … DATE 2 March 2019 - version -21 As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) Is should be a Proposed Standard and that is reflected in the meta information. (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 document describes a framework for the use of OAuth 2.0 in a constrained environment. The document is mainly targeted at the protocols defined for CoAP, but other protocols can be used as well. The framework defines the fields and symmantics needed for doing authorization and authenticiation of a client. Working Group Summary The concesus on the document wa generally very solid. There were some issues that arose between the ACE and OAuth working groups over a couple of issues. These issues appear to have been resolved. Document Quality There have been at least four different groups who have announced an implementation at some level of the specification. While two of those implementations share a certain amount of common code, there are two implementations which have done interop tests at various times which do not share any code based on this document. The scope and issues of trying to deal with some of the OAuth 2.0 documents can be challenging at times. While it is believed that a good job has been done, there are some potential areas where different people might end up doing new things. Personnel Jim Schaad is the Document Shepherd. Ben Kaduk is the responsible AD. (3) I have done a detailed read a number of times during the WGLC process and while shepherding to make sure all WGLC comments were addressed. Additionally, I have done an implementation of the document during development. (4) Between the implentations of the framework that we have and the healthy discussions during the WGLC, I am confident that there has been quite broad review of the document. (5) No broader review should be needed. During the process there has been significant review from the OAuth working group. (6) I have no issues with this specific document. I do have a problem with how the registries have been setup in OAuth, but that is not germane to this document. (7) All authors have indicated that they do no know of any additional IPR that needs to be disclosed. Ludwig 2/25/19 Goren 2/25/19 Erdtman 2/25/19 Hannes 2/27/19 (8) There is an IPR disclosure on this document. During the shepards review, I specifically requested if there were any concerns about this IPR and none were raised. (9) The set of people that have contributed probably represent about a dozen individuals in the WG. (10) There has been no extreme discontent expressed during the discussions. (11) No ID nits are called out. (12) The only formal review needed is for a new media type. The media type request for application/ace+cbor was mailed 23 Feb 2019. (13) All references are tagged and reasonable. (14) All of the normative documents which are in process are at the same stage of development and thus should not cause any issues. (15) There are no downward normative references. (16) This document represents the first iteration. It profiles and extends some of the OAuth documents, but this is not done by modifications of the documents themselves. (17) It was somewhat painful. I looked at all items that were defined and should be registered to make sure that they existed in the IANA considerations. I compared the registrations of items with the required templates or columns in the IANA registries. A detailed walk of the new registries along with reasonable behavior was examined. (18) The following new IANA registries are created: ACE Authorization Server Request Creation Hints - Contains a set of attributes to be returned from a resource server that can be used by a client when building the request to the authorization server. There is not currently an equivalent registry for OAuth so it is not clear that an OAuth person is going to be extremely useful. Some implementation experience would probably be useful, but is definitely not required. OAuth Error Code CBOR Mappings - Contains a mapping of errors that can be returned in OAuth. No special expertise should be required for the experts. OAuth Grant Type CBOR Mappings - Contains a mapping of grant types from the OAuth registry to a CBOR integer. No special expertise should be required for the experts. OAuth Access Token Type CBOR Mapping - Contains a mapping of token types from the OAuth registry to a CBOR integer. No special expertise should be required for the experts. ACE Profile - Contains the set of ACE profiles that use the framework. The experts should have a solid working knowledge of the framework as they need to be able to evaluate any new profile against the framework to make sure that all of the conditions outlined are fulfilled. OAuth Parameters CBOR Mapping - Contains the set of mappings from OAuth parameters to integer values. No special expertise should be required for the experts. OAuth Token Introspection Response CBOR Mappings - Contains the mapping of response parameters from the OAuth registry to a CBOR integer and type. No special expertise should be required for the experts. 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. (19) No automated checks were done. |
2019-02-14 |
21 | Ludwig Seitz | New version available: draft-ietf-ace-oauth-authz-21.txt |
2019-02-14 |
21 | (System) | New version approved |
2019-02-14 |
21 | (System) | Request for posting confirmation emailed to previous authors: Ludwig Seitz <ludwig.seitz@ri.se>, Hannes Tschofenig <hannes.tschofenig@arm.com>, Goeran Selander <goran.selander@ericsson.com>, Samuel Erdtman <erdtman@spotify.com>, Erik Wahlstroem <erik@wahlstromstekniska.se> |
2019-02-14 |
21 | Ludwig Seitz | Uploaded new revision |
2019-02-11 |
20 | Ludwig Seitz | New version available: draft-ietf-ace-oauth-authz-20.txt |
2019-02-11 |
20 | (System) | New version approved |
2019-02-11 |
20 | (System) | Request for posting confirmation emailed to previous authors: Ludwig Seitz <ludwig.seitz@ri.se>, Hannes Tschofenig <hannes.tschofenig@arm.com>, Goeran Selander <goran.selander@ericsson.com>, Samuel Erdtman <erdtman@spotify.com>, Erik Wahlstroem <erik@wahlstromstekniska.se> |
2019-02-11 |
20 | Ludwig Seitz | Uploaded new revision |
2019-01-31 |
19 | Ludwig Seitz | New version available: draft-ietf-ace-oauth-authz-19.txt |
2019-01-31 |
19 | (System) | New version approved |
2019-01-31 |
19 | (System) | Request for posting confirmation emailed to previous authors: Ludwig Seitz <ludwig.seitz@ri.se>, Hannes Tschofenig <hannes.tschofenig@arm.com>, Goeran Selander <goran.selander@ericsson.com>, Samuel Erdtman <erdtman@spotify.com>, Erik Wahlstroem <erik@wahlstromstekniska.se> |
2019-01-31 |
19 | Ludwig Seitz | Uploaded new revision |
2019-01-29 |
18 | Jim Schaad | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (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? (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 Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? 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? Personnel Who is the Document Shepherd? Who is the Responsible Area Director? (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. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? (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. (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. (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. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. (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? (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.) (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. (13) Have all references within this document been identified as either normative or informative? (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? (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. (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. (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). (18) The following new IANA registries are created: ACE Authorization Server Information - OAuth Error Code CBOR Mappings - OAuth Grant Type CBOR Mappings - Token Type CBOR Mappings - ACE Profile - Token Endpoint CBOR Mappings - Introspection Endpoint CBOR Mappings - 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. (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. ************************************************************************** **DONE** Stefanie Gerdes Ben Kaduk > > On 22/10/2018 21:09, Jim Schaad wrote: > > * Section 5.8.2 - If the RS is going to do introspection, can it send some > > type of "Server Busy - try again in xxx" while it does the introspection > > rather than just doing an ack of the request and possibly waiting a long > > time? > > This is probably transport protocol specific, and we were asked not to > link the framework to a specific protocol, thus I don't know if we can > provide guidance here. I think it would be okay to say something like "some transport protocols may provide a way to indicate that the server is busy and the client should retry after an interval; this type of status update would be appropriate while the server is waiting for an introspection response". Which does provide guidance, but in a non-normative fashion that does not require or prohibit any given transport protocol. Mike Jones: **IGNORE** IT CAN'T BE A COINCIDENCE: There's clearly a relationship between many of the CBOR numeric values used in this this specification and corresponding CBOR Web Token (CWT) claim identifiers, but oddly, the relationship is currently unspecified and the goals behind it are undefined. The spec should be augmented to make the nature and goals of this relationship explicit. I infer that there's such a relationship because the Mapping Parameters to CBOR in Section 5.6.5 apparently carefully do not overlap with the values registered in the IANA CWT Claims registry at https://www.iana.org/assignments/cwt/cwt.xhtml. The Introspection mappings in Section 5.7.4 apparently carefully use the same values as CWT for the same things, but then adds additional values. And some of these values are the same as values proposed for the CWT Claims registry in 8.13. This has to be more than a coincidence but the spec doesn't currently say why. Per my earlier reviews of the ace-authz spec, I believe that the ACE OAuth parameters should all be registered in the CWT Claims registry because of the possibility of them being used in signed requests in a manner analogous to https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-17. The parameters need to be registered to avoid future claim number conflicts. While conflicts have clearly been carefully avoided to date, they will inevitably occur in the future unless the values are actually registered. Please do so. DON'T SQUAT ON NUMERIC REGISTRY VALUES: Please change all instances of numbers to be assigned by designated experts in existing registries from specific values to "TBD". For instance, all the values for the CWT Claims Registry in Section 8.13 (currently 12, 16, and 17) should be changed to TBD. Our chair, Jim Schaad has been a vigorous advocate of not squatting in my past interactions with him as a Designated Expert and I believe would support this request. Likewise, the "19" in the CoAP Content-Format Registration in Section 8.15 should become TBD. **DONE** req_aud: Several examples use the "req_aud" parameter without defining it. Doesn't this duplicate the "resource" parameter defined by https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-01? If so, please delete this parameter and use "resource". If not, say how it is different and why the differences are necessary. **DONE** rs_cnf: There isn't a clear normative definition of this parameter. It's mentioned obliquely but its purpose, syntax, and semantics should be plainly stated (as with each other newly defined parameter). The proposed numbers in Figures 12 and 16 contain mismatches. For instance, token_type is "14" in Figure 12 in Section 5.6.5 and "13" in Figure 16 in Section 5.7.4. There's too much alignment for it to be a coincidence but if you intend alignment, please say so explicitly and fix the alignment. The proposed ongoing alignment should also be described in the registration instructions for the Designated Experts. -- Mike P.S. Per my earlier reviews of this specification, in my view as a Designated Expert for the CWT Claims registry, I believe that it's not appropriate to use up rare single-byte identifiers for most of the OAuth parameter encodings specified in 5.6.5. I could be persuaded that "scope" merits one of these rare numbers, but "profile", "error", "grant_type", "access_token", and "token_type" probably do not, as they are application-specific and not of general applicability. I also believe that some of the other Designated Experts for this registry agree with me. Jim Schaad * Section 3.1 - Refresh Token - I don't think that refresh tokens are going to be strings because binary is more efficient. **DONE** * Section 3.2 - we need to reference TLS 1.3 even if DTLS 1.3 is not yet available. * Description for Figure 6 - Should the example somehow indicate in the message that it is going to be an application/ace+cbor content. Also, I don't know that this is a good example in some ways because this is not a currently documented profile anywhere. **DONE** * Section 5.6.3 - Should the content type for an error response be application/ace+cbor ? **DONE** * Section 5.7.1 - Is the content format for a request application/ace+cbor? I assume it is but that is not documented in this section. **DONE** Section 5.8 - bytes arrays or byte strings? I think CBOR uses the latter **DONE** * Section 5.8.1 - What is the purpose of creating an identifier for a token? Is this supposed to be used rather than the one from the AS for something like shared secret TLS? Note that this is an unprotected value. * Section 5.8.1 - Given the change in the OSCORE profile, you might want to make this an application/ace+cbor structure as well. **DONE** * Section 5.8.1 - If the token is "not valid" is the RS required (i.e. MUST) to try introspection before returning a response if the RS does introspection? The text currently says MAY. If this is really MAY then the text should say that the token is always successfully accepted by the RS. * Section 5.8.2 - If the RS is going to do introspection, can it send some type of "Server Busy - try again in xxx" while it does the introspection rather than just doing an ack of the request and possibly waiting a long time? * Section 5.8.3 - third point - I think that the correct text would be "The method does not provide timely expiration, but it makes sure that older tokens will cease to be valid after newer issued tokens are registered with the RS." My problem is that just issuing tokens is not enough as they may be going to a different RS for use. This may also need to have some type of rate limit to issued tokens or making the sequence number be on an RS/audience basis. * Section 6. - The recommendation not to use a shared secret for an audience which is hosted by multiple servers is interesting. This does require that a multiple recipient COSE structure be used and it may be worth calling that out. Also the size of the CWT is going to grow for that. You are also now losing the low-level authentication and thus a signature wrapping is now also needed. **DONE** * Section 6 - "Developers MUST" para - May want to add that this can also be mitigated to some extent by making sure that keys roll over more frequently. * Section 6 - I am not sure that I agree with the SHOULD NOT in the last paragraph. Think multicast. **DONE** * Section 6.4 - This also applies to sending back some type of identifier from the RS->C when a token is registered. **DONE** * Section 8.6.1 - Is pop still this document or is it Mike's document? **DONE** * Section 8.9 - The description of reference is wrong. **DONE** * Section 8.12 - some of these should move to the OAuth parameters document? **DONE** * Section 8.13 - ditto **DONE** * Appendix A - para "CBOR, COSE, CWT" - Is it really a requirement to use CBOR or is that a recommended? I thought this was part of what Hannes was looking at. **DONE** * Appendix A - para Client Credentials Grant s/can the/can then/ * Registries - I am wondering if we should think about re-writing a couple of the registries. As things stand it appears that the application/ace+cbor content type is being used in 5 or 6 places. It might make more sense to have a registry for all of the CBOR abbreviations that are being used in a single table and have multiple columns for each of the different places were the content format is being used. This would make it easier to keep everything constant and can make re-use of integer values easier to see. * Comments on protection of CWT/Token: I am wondering if there needs to be any comments on how a CWT is going to be protected. While it is ok to use either a symmetric key or a direct key agreement operation for a single recipient without forcing a signature operation to occur. If the token is going to be targeted a single audience hosted on multiple RSs then a signature operation would be required for the purposes of authentication. **DONE** * I am not sure where this issue should be raised so I am putting it here. Both of the profiles have as their last security consideration a statement that the use of multiple access tokens is a bad idea. Both of them also devote a large section of text to how to deal with multiple access tokens as does this document. More methods of having multiple access tokens seem to be coming down the path from the OAuth group. This appears to be a distinct contradiction within the set of documents that should be resolved. |
2019-01-28 |
18 | Jim Schaad | Notification list changed to Jim Schaad <ietf@augustcellars.com> from "Kepeng Li" <kepeng.lkp@alibaba-inc.com>, Jim Schaad <ietf@augustcellars.com> |
2019-01-28 |
18 | Jim Schaad | Notification list changed to "Kepeng Li" <kepeng.lkp@alibaba-inc.com>, Jim Schaad <ietf@augustcellars.com> from "Kepeng Li" <kepeng.lkp@alibaba-inc.com> |
2019-01-28 |
18 | Jim Schaad | Document shepherd changed to Jim Schaad |
2019-01-17 |
18 | Ludwig Seitz | New version available: draft-ietf-ace-oauth-authz-18.txt |
2019-01-17 |
18 | (System) | New version approved |
2019-01-17 |
18 | (System) | Request for posting confirmation emailed to previous authors: Ludwig Seitz <ludwig.seitz@ri.se>, Hannes Tschofenig <hannes.tschofenig@arm.com>, Goeran Selander <goran.selander@ericsson.com>, Samuel Erdtman <erdtman@spotify.com>, Erik Wahlstroem <erik@wahlstromstekniska.se> |
2019-01-17 |
18 | Ludwig Seitz | Uploaded new revision |
2018-11-26 |
17 | Ludwig Seitz | New version available: draft-ietf-ace-oauth-authz-17.txt |
2018-11-26 |
17 | (System) | New version approved |
2018-11-26 |
17 | (System) | Request for posting confirmation emailed to previous authors: Ludwig Seitz <ludwig.seitz@ri.se>, Hannes Tschofenig <hannes.tschofenig@arm.com>, Goeran Selander <goran.selander@ericsson.com>, Samuel Erdtman <erdtman@spotify.com>, Erik Wahlstroem <erik@wahlstromstekniska.se> |
2018-11-26 |
17 | Ludwig Seitz | Uploaded new revision |
2018-11-04 |
16 | Jim Schaad | Tag Revised I-D Needed - Issue raised by WGLC set. |
2018-10-22 |
16 | Jim Schaad | Added to session: IETF-103: ace Thu-1610 |
2018-10-08 |
16 | Jim Schaad | IETF WG state changed to In WG Last Call from WG Document |
2018-10-02 |
16 | Ludwig Seitz | New version available: draft-ietf-ace-oauth-authz-16.txt |
2018-10-02 |
16 | (System) | New version approved |
2018-10-02 |
16 | (System) | Request for posting confirmation emailed to previous authors: Ludwig Seitz <ludwig.seitz@ri.se>, Hannes Tschofenig <hannes.tschofenig@arm.com>, Goeran Selander <goran.selander@ericsson.com>, Samuel Erdtman <erdtman@spotify.com>, Erik Wahlstroem <erik@wahlstromstekniska.se> |
2018-10-02 |
16 | Ludwig Seitz | Uploaded new revision |
2018-09-27 |
15 | Ludwig Seitz | New version available: draft-ietf-ace-oauth-authz-15.txt |
2018-09-27 |
15 | (System) | New version approved |
2018-09-27 |
15 | (System) | Request for posting confirmation emailed to previous authors: Ludwig Seitz <ludwig.seitz@ri.se>, Hannes Tschofenig <hannes.tschofenig@arm.com>, Goeran Selander <goran.selander@ericsson.com>, Samuel Erdtman <erdtman@spotify.com>, Erik Wahlstroem <erik@wahlstromstekniska.se> |
2018-09-27 |
15 | Ludwig Seitz | Uploaded new revision |
2018-09-27 |
15 | (System) | Request for posting confirmation emailed to previous authors: Ludwig Seitz <ludwig.seitz@ri.se>, Hannes Tschofenig <hannes.tschofenig@arm.com>, Goeran Selander <goran.selander@ericsson.com>, Samuel Erdtman <erdtman@spotify.com>, Erik Wahlstroem <erik@wahlstromstekniska.se> |
2018-09-27 |
15 | Ludwig Seitz | Uploaded new revision |
2018-09-19 |
14 | Ludwig Seitz | New version available: draft-ietf-ace-oauth-authz-14.txt |
2018-09-19 |
14 | (System) | New version approved |
2018-09-19 |
14 | (System) | Request for posting confirmation emailed to previous authors: Ludwig Seitz <ludwig.seitz@ri.se>, Hannes Tschofenig <hannes.tschofenig@arm.com>, Goeran Selander <goran.selander@ericsson.com>, Samuel Erdtman <erdtman@spotify.com>, Erik Wahlstroem <erik@wahlstromstekniska.se> |
2018-09-19 |
14 | Ludwig Seitz | Uploaded new revision |
2018-07-14 |
13 | Roman Danyliw | Added to session: IETF-102: ace Mon-0930 |
2018-07-02 |
13 | Ludwig Seitz | New version available: draft-ietf-ace-oauth-authz-13.txt |
2018-07-02 |
13 | (System) | New version approved |
2018-07-02 |
13 | (System) | Request for posting confirmation emailed to previous authors: Ludwig Seitz <ludwig.seitz@ri.se>, Hannes Tschofenig <hannes.tschofenig@arm.com>, Goeran Selander <goran.selander@ericsson.com>, Samuel Erdtman <erdtman@spotify.com>, Erik Wahlstroem <erik@wahlstromstekniska.se> |
2018-07-02 |
13 | Ludwig Seitz | Uploaded new revision |
2018-05-21 |
12 | Ludwig Seitz | New version available: draft-ietf-ace-oauth-authz-12.txt |
2018-05-21 |
12 | (System) | New version approved |
2018-05-21 |
12 | (System) | Request for posting confirmation emailed to previous authors: Ludwig Seitz <ludwig.seitz@ri.se>, Hannes Tschofenig <hannes.tschofenig@arm.com>, Goeran Selander <goran.selander@ericsson.com>, Samuel Erdtman <erdtman@spotify.com>, Erik Wahlstroem <erik@wahlstromstekniska.se> |
2018-05-21 |
12 | Ludwig Seitz | Uploaded new revision |
2018-03-19 |
11 | Ludwig Seitz | New version available: draft-ietf-ace-oauth-authz-11.txt |
2018-03-19 |
11 | (System) | New version approved |
2018-03-19 |
11 | (System) | Request for posting confirmation emailed to previous authors: Ludwig Seitz <ludwig.seitz@ri.se>, Hannes Tschofenig <hannes.tschofenig@arm.com>, Goeran Selander <goran.selander@ericsson.com>, Samuel Erdtman <erdtman@spotify.com>, Erik Wahlstroem <erik@wahlstromstekniska.se> |
2018-03-19 |
11 | Ludwig Seitz | Uploaded new revision |
2018-03-13 |
10 | Jim Schaad | Added to session: IETF-101: ace Mon-0930 |
2018-02-13 |
10 | Ludwig Seitz | New version available: draft-ietf-ace-oauth-authz-10.txt |
2018-02-13 |
10 | (System) | New version approved |
2018-02-13 |
10 | (System) | Request for posting confirmation emailed to previous authors: ace-chairs@ietf.org, Ludwig Seitz <ludwig.seitz@ri.se>, Hannes Tschofenig <hannes.tschofenig@arm.com>, Erik Wahlstroem <erik@wahlstromtekniska.se>, Goeran Selander <goran.selander@ericsson.com>, Samuel Erdtman <erdtman@spotify.com> |
2018-02-13 |
10 | Ludwig Seitz | Uploaded new revision |
2017-12-21 |
Jasmine Magallanes | Posted related IPR disclosure: Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-ace-oauth-authz | |
2017-11-16 |
09 | Ludwig Seitz | New version available: draft-ietf-ace-oauth-authz-09.txt |
2017-11-16 |
09 | (System) | New version approved |
2017-11-16 |
09 | (System) | Request for posting confirmation emailed to previous authors: Ludwig Seitz <ludwig.seitz@ri.se>, Samuel Erdtman <erdtman@spotify.com>, Hannes Tschofenig <hannes.tschofenig@arm.com>, Goeran Selander <goran.selander@ericsson.com>, Erik Wahlstroem <erik@wahlstromtekniska.se> |
2017-11-16 |
09 | Ludwig Seitz | Uploaded new revision |
2017-11-08 |
08 | Jim Schaad | Added to session: IETF-100: ace Tue-0930 |
2017-10-19 |
08 | Ludwig Seitz | New version available: draft-ietf-ace-oauth-authz-08.txt |
2017-10-19 |
08 | (System) | New version approved |
2017-10-19 |
08 | (System) | Request for posting confirmation emailed to previous authors: Ludwig Seitz <ludwig.seitz@ri.se>, Samuel Erdtman <erdtman@spotify.com>, Hannes Tschofenig <hannes.tschofenig@arm.com>, Goeran Selander <goran.selander@ericsson.com>, Erik Wahlstroem <erik@wahlstromtekniska.se> |
2017-10-19 |
08 | Ludwig Seitz | Uploaded new revision |
2017-08-08 |
07 | Ludwig Seitz | New version available: draft-ietf-ace-oauth-authz-07.txt |
2017-08-08 |
07 | (System) | New version approved |
2017-08-08 |
07 | (System) | Request for posting confirmation emailed to previous authors: ace-chairs@ietf.org, Hannes Tschofenig <hannes.tschofenig@arm.com>, Erik Wahlstroem <erik@wahlstromtekniska.se>, Goeran Selander <goran.selander@ericsson.com>, Samuel Erdtman <erdtman@spotify.com>, Ludwig Seitz <ludwig@ri.se> |
2017-08-08 |
07 | Ludwig Seitz | Uploaded new revision |
2017-07-16 |
06 | Kepeng Li | Added to session: IETF-99: ace Mon-0930 |
2017-03-13 |
06 | Ludwig Seitz | New version available: draft-ietf-ace-oauth-authz-06.txt |
2017-03-13 |
06 | (System) | New version approved |
2017-03-13 |
06 | (System) | Request for posting confirmation emailed to previous authors: ace-chairs@ietf.org, Hannes Tschofenig <hannes.tschofenig@arm.com>, Erik Wahlstroem <erik@wahlstromtekniska.se>, =?utf-8?q?G=C3=B6ran_Selander?= <goran.selander@ericsson.com>, Samuel Erdtman <erdtman@spotify.com>, Ludwig Seitz <ludwig@sics.se> |
2017-03-13 |
06 | Ludwig Seitz | Uploaded new revision |
2017-02-06 |
05 | Ludwig Seitz | New version available: draft-ietf-ace-oauth-authz-05.txt |
2017-02-06 |
05 | (System) | New version approved |
2017-02-06 |
05 | (System) | Request for posting confirmation emailed to previous authors: "Ludwig Seitz" <ludwig@sics.se>, "Erik Wahlstroem" <erik@wahlstromtekniska.se>, "Goeran Selander" <goran.selander@ericsson.com>, "Samuel Erdtman" <erdtman@spotify.com>, "Hannes Tschofenig" <hannes.tschofenig@arm.com> |
2017-02-06 |
05 | Ludwig Seitz | Uploaded new revision |
2016-10-31 |
04 | Ludwig Seitz | New version available: draft-ietf-ace-oauth-authz-04.txt |
2016-10-31 |
04 | (System) | New version approved |
2016-10-31 |
03 | (System) | Request for posting confirmation emailed to previous authors: "Ludwig Seitz" <ludwig@sics.se>, "Erik Wahlstroem" <erik@wahlstromtekniska.se>, "Goeran Selander" <goran.selander@ericsson.com>, "Samuel Erdtman" <erdtman@spotify.com>, "Hannes Tschofenig" <hannes.tschofenig@arm.com> |
2016-10-31 |
03 | Ludwig Seitz | Uploaded new revision |
2016-10-12 |
03 | Ludwig Seitz | New version available: draft-ietf-ace-oauth-authz-03.txt |
2016-10-12 |
03 | (System) | New version approved |
2016-10-12 |
02 | (System) | Request for posting confirmation emailed to previous authors: ace-chairs@ietf.org, "Goeran Selander" <goran.selander@ericsson.com>, "Erik Wahlstroem" <erik.wahlstrom@nexusgroup.com>, "Ludwig Seitz" <ludwig@sics.se>, "Hannes Tschofenig" <hannes.tschofenig@arm.com>, "Samuel Erdtman" <erdtman@spotify.com> |
2016-10-12 |
02 | Ludwig Seitz | Uploaded new revision |
2016-06-10 |
02 | Ludwig Seitz | New version available: draft-ietf-ace-oauth-authz-02.txt |
2016-06-01 |
01 | Hannes Tschofenig | This document now replaces draft-tschofenig-ace-oauth-iot, draft-tschofenig-ace-oauth-bt, draft-seitz-ace-oauth-authz instead of draft-seitz-ace-oauth-authz |
2016-04-11 |
01 | Hannes Tschofenig | Changed consensus to Yes from Unknown |
2016-04-11 |
01 | Hannes Tschofenig | Intended Status changed to Proposed Standard from None |
2016-04-11 |
01 | Hannes Tschofenig | Notification list changed to "Kepeng Li" <kepeng.lkp@alibaba-inc.com> |
2016-04-11 |
01 | Hannes Tschofenig | Document shepherd changed to Kepeng Li |
2016-04-11 |
01 | Hannes Tschofenig | This document now replaces draft-seitz-ace-oauth-authz instead of None |
2016-02-25 |
01 | Ludwig Seitz | New version available: draft-ietf-ace-oauth-authz-01.txt |
2015-12-21 |
00 | Ludwig Seitz | New version available: draft-ietf-ace-oauth-authz-00.txt |