draft-ietf-ace-oauth-authz-21.txt   draft-ietf-ace-oauth-authz-22.txt 
ACE Working Group L. Seitz ACE Working Group L. Seitz
Internet-Draft RISE Internet-Draft RISE
Intended status: Standards Track G. Selander Intended status: Standards Track G. Selander
Expires: August 18, 2019 Ericsson Expires: September 6, 2019 Ericsson
E. Wahlstroem E. Wahlstroem
S. Erdtman S. Erdtman
Spotify AB Spotify AB
H. Tschofenig H. Tschofenig
Arm Ltd. Arm Ltd.
February 14, 2019 March 5, 2019
Authentication and Authorization for Constrained Environments (ACE) Authentication and Authorization for Constrained Environments (ACE)
using the OAuth 2.0 Framework (ACE-OAuth) using the OAuth 2.0 Framework (ACE-OAuth)
draft-ietf-ace-oauth-authz-21 draft-ietf-ace-oauth-authz-22
Abstract Abstract
This specification defines a framework for authentication and This specification defines a framework for authentication and
authorization in Internet of Things (IoT) environments called ACE- authorization in Internet of Things (IoT) environments called ACE-
OAuth. The framework is based on a set of building blocks including OAuth. The framework is based on a set of building blocks including
OAuth 2.0 and CoAP, thus making a well-known and widely used OAuth 2.0 and CoAP, thus making a well-known and widely used
authorization solution suitable for IoT devices. Existing authorization solution suitable for IoT devices. Existing
specifications are used where possible, but where the constraints of specifications are used where possible, but where the constraints of
IoT devices require it, extensions are added and profiles are IoT devices require it, extensions are added and profiles are
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 18, 2019. This Internet-Draft will expire on September 6, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 33 skipping to change at page 2, line 33
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. OAuth 2.0 . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. OAuth 2.0 . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. CoAP . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. CoAP . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4. Protocol Interactions . . . . . . . . . . . . . . . . . . . . 11 4. Protocol Interactions . . . . . . . . . . . . . . . . . . . . 11
5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Discovering Authorization Servers . . . . . . . . . . . . 16 5.1. Discovering Authorization Servers . . . . . . . . . . . . 16
5.1.1. Unauthorized Resource Request Message . . . . . . . . 16 5.1.1. Unauthorized Resource Request Message . . . . . . . . 16
5.1.2. AS Request Creation Hints . . . . . . . . . . . . . . 17 5.1.2. AS Request Creation Hints . . . . . . . . . . . . . . 17
5.2. Authorization Grants . . . . . . . . . . . . . . . . . . 19 5.2. Authorization Grants . . . . . . . . . . . . . . . . . . 19
5.3. Client Credentials . . . . . . . . . . . . . . . . . . . 19 5.3. Client Credentials . . . . . . . . . . . . . . . . . . . 20
5.4. AS Authentication . . . . . . . . . . . . . . . . . . . . 20 5.4. AS Authentication . . . . . . . . . . . . . . . . . . . . 20
5.5. The Authorization Endpoint . . . . . . . . . . . . . . . 20 5.5. The Authorization Endpoint . . . . . . . . . . . . . . . 20
5.6. The Token Endpoint . . . . . . . . . . . . . . . . . . . 20 5.6. The Token Endpoint . . . . . . . . . . . . . . . . . . . 20
5.6.1. Client-to-AS Request . . . . . . . . . . . . . . . . 21 5.6.1. Client-to-AS Request . . . . . . . . . . . . . . . . 21
5.6.2. AS-to-Client Response . . . . . . . . . . . . . . . . 24 5.6.2. AS-to-Client Response . . . . . . . . . . . . . . . . 24
5.6.3. Error Response . . . . . . . . . . . . . . . . . . . 26 5.6.3. Error Response . . . . . . . . . . . . . . . . . . . 26
5.6.4. Request and Response Parameters . . . . . . . . . . . 27 5.6.4. Request and Response Parameters . . . . . . . . . . . 27
5.6.4.1. Grant Type . . . . . . . . . . . . . . . . . . . 27 5.6.4.1. Grant Type . . . . . . . . . . . . . . . . . . . 27
5.6.4.2. Token Type . . . . . . . . . . . . . . . . . . . 28 5.6.4.2. Token Type . . . . . . . . . . . . . . . . . . . 28
5.6.4.3. Profile . . . . . . . . . . . . . . . . . . . . . 28 5.6.4.3. Profile . . . . . . . . . . . . . . . . . . . . . 28
skipping to change at page 3, line 8 skipping to change at page 3, line 8
5.7.2. Introspection Response . . . . . . . . . . . . . . . 31 5.7.2. Introspection Response . . . . . . . . . . . . . . . 31
5.7.3. Error Response . . . . . . . . . . . . . . . . . . . 32 5.7.3. Error Response . . . . . . . . . . . . . . . . . . . 32
5.7.4. Mapping Introspection parameters to CBOR . . . . . . 33 5.7.4. Mapping Introspection parameters to CBOR . . . . . . 33
5.8. The Access Token . . . . . . . . . . . . . . . . . . . . 33 5.8. The Access Token . . . . . . . . . . . . . . . . . . . . 33
5.8.1. The Authorization Information Endpoint . . . . . . . 34 5.8.1. The Authorization Information Endpoint . . . . . . . 34
5.8.1.1. Verifying an Access Token . . . . . . . . . . . . 35 5.8.1.1. Verifying an Access Token . . . . . . . . . . . . 35
5.8.1.2. Protecting the Authorization Information 5.8.1.2. Protecting the Authorization Information
Endpoint . . . . . . . . . . . . . . . . . . . . 37 Endpoint . . . . . . . . . . . . . . . . . . . . 37
5.8.2. Client Requests to the RS . . . . . . . . . . . . . . 37 5.8.2. Client Requests to the RS . . . . . . . . . . . . . . 37
5.8.3. Token Expiration . . . . . . . . . . . . . . . . . . 38 5.8.3. Token Expiration . . . . . . . . . . . . . . . . . . 38
5.8.4. Key Expriation . . . . . . . . . . . . . . . . . . . 39 5.8.4. Key Expiration . . . . . . . . . . . . . . . . . . . 39
6. Security Considerations . . . . . . . . . . . . . . . . . . . 39 6. Security Considerations . . . . . . . . . . . . . . . . . . . 39
6.1. Unprotected AS Request Creation Hints . . . . . . . . . . 41 6.1. Unprotected AS Request Creation Hints . . . . . . . . . . 41
6.2. Minimal security requirements for communication . 41 6.2. Minimal security requirements for communication . 41
6.3. Use of Nonces for Replay Protection . . . . . . . . . . . 42 6.3. Use of Nonces for Replay Protection . . . . . . . . . . . 42
6.4. Combining profiles . . . . . . . . . . . . . . . . . . . 42 6.4. Combining profiles . . . . . . . . . . . . . . . . . . . 42
6.5. Unprotected Information . . . . . . . . . . . . . . . . . 42 6.5. Unprotected Information . . . . . . . . . . . . . . . . . 42
6.6. Identifying audiences . . . . . . . . . . . . . . . . . . 43 6.6. Identifying audiences . . . . . . . . . . . . . . . . . . 43
6.7. Denial of service against or with Introspection . . 44 6.7. Denial of service against or with Introspection . . 44
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 44 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 44
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45
8.1. ACE Authorization Server Request Creation Hints . . . . . 45 8.1. ACE Authorization Server Request Creation Hints . . . . . 45
8.2. OAuth Extensions Error Registration . . . . . . . . . . . 46 8.2. OAuth Extensions Error Registration . . . . . . . . . . . 46
8.3. OAuth Error Code CBOR Mappings Registry . . . . . . . . . 46 8.3. OAuth Error Code CBOR Mappings Registry . . . . . . . . . 46
8.4. OAuth Grant Type CBOR Mappings . . . . . . . . . . . . . 46 8.4. OAuth Grant Type CBOR Mappings . . . . . . . . . . . . . 47
8.5. OAuth Access Token Types . . . . . . . . . . . . . . . . 47 8.5. OAuth Access Token Types . . . . . . . . . . . . . . . . 47
8.6. OAuth Access Token Type CBOR Mappings . . . . . . . . . . 47 8.6. OAuth Access Token Type CBOR Mappings . . . . . . . . . . 47
8.6.1. Initial Registry Contents . . . . . . . . . . . . . . 48 8.6.1. Initial Registry Contents . . . . . . . . . . . . . . 48
8.7. ACE Profile Registry . . . . . . . . . . . . . . . . . . 48 8.7. ACE Profile Registry . . . . . . . . . . . . . . . . . . 48
8.8. OAuth Parameter Registration . . . . . . . . . . . . . . 49 8.8. OAuth Parameter Registration . . . . . . . . . . . . . . 49
8.9. OAuth Parameters CBOR Mappings Registry . . . . . . . . . 49 8.9. OAuth Parameters CBOR Mappings Registry . . . . . . . . . 49
8.10. OAuth Introspection Response Parameter Registration . . . 49 8.10. OAuth Introspection Response Parameter Registration . . . 49
8.11. OAuth Token Introspection Response CBOR Mappings Registry 50 8.11. OAuth Token Introspection Response CBOR Mappings Registry 50
8.12. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 50 8.12. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 50
8.13. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 51 8.13. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 51
8.14. Media Type Registrations . . . . . . . . . . . . . . . . 52 8.14. Media Type Registrations . . . . . . . . . . . . . . . . 51
8.15. CoAP Content-Format Registry . . . . . . . . . . . . . . 53 8.15. CoAP Content-Format Registry . . . . . . . . . . . . . . 52
8.16. Expert Review Instructions . . . . . . . . . . . . . . . 53 8.16. Expert Review Instructions . . . . . . . . . . . . . . . 53
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 54 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 54
10.1. Normative References . . . . . . . . . . . . . . . . . . 54 10.1. Normative References . . . . . . . . . . . . . . . . . . 54
10.2. Informative References . . . . . . . . . . . . . . . . . 56 10.2. Informative References . . . . . . . . . . . . . . . . . 56
Appendix A. Design Justification . . . . . . . . . . . . . . . . 59 Appendix A. Design Justification . . . . . . . . . . . . . . . . 59
Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 62 Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 62
Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 64 Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 64
Appendix D. Assumptions on AS knowledge about C and RS . . . . . 65 Appendix D. Assumptions on AS knowledge about C and RS . . . . . 65
Appendix E. Deployment Examples . . . . . . . . . . . . . . . . 66 Appendix E. Deployment Examples . . . . . . . . . . . . . . . . 65
E.1. Local Token Validation . . . . . . . . . . . . . . . . . 66 E.1. Local Token Validation . . . . . . . . . . . . . . . . . 66
E.2. Introspection Aided Token Validation . . . . . . . . . . 70 E.2. Introspection Aided Token Validation . . . . . . . . . . 70
Appendix F. Document Updates . . . . . . . . . . . . . . . . . . 74 Appendix F. Document Updates . . . . . . . . . . . . . . . . . . 74
F.1. Verion -20 to 21 . . . . . . . . . . . . . . . . . . . . 74 F.1. Version -21 to 22 . . . . . . . . . . . . . . . . . . . . 74
F.2. Verion -19 to 20 . . . . . . . . . . . . . . . . . . . . 74 F.2. Version -20 to 21 . . . . . . . . . . . . . . . . . . . . 74
F.3. Version -18 to -19 . . . . . . . . . . . . . . . . . . . 74 F.3. Version -19 to 20 . . . . . . . . . . . . . . . . . . . . 74
F.4. Version -17 to -18 . . . . . . . . . . . . . . . . . . . 75 F.4. Version -18 to -19 . . . . . . . . . . . . . . . . . . . 75
F.5. Version -16 to -17 . . . . . . . . . . . . . . . . . . . 75 F.5. Version -17 to -18 . . . . . . . . . . . . . . . . . . . 75
F.6. Version -15 to -16 . . . . . . . . . . . . . . . . . . . 75 F.6. Version -16 to -17 . . . . . . . . . . . . . . . . . . . 75
F.7. Version -14 to -15 . . . . . . . . . . . . . . . . . . . 75 F.7. Version -15 to -16 . . . . . . . . . . . . . . . . . . . 76
F.8. Version -13 to -14 . . . . . . . . . . . . . . . . . . . 76 F.8. Version -14 to -15 . . . . . . . . . . . . . . . . . . . 76
F.9. Version -12 to -13 . . . . . . . . . . . . . . . . . . . 76 F.9. Version -13 to -14 . . . . . . . . . . . . . . . . . . . 76
F.10. Version -11 to -12 . . . . . . . . . . . . . . . . . . . 76 F.10. Version -12 to -13 . . . . . . . . . . . . . . . . . . . 76
F.11. Version -10 to -11 . . . . . . . . . . . . . . . . . . . 76 F.11. Version -11 to -12 . . . . . . . . . . . . . . . . . . . 76
F.12. Version -09 to -10 . . . . . . . . . . . . . . . . . . . 76 F.12. Version -10 to -11 . . . . . . . . . . . . . . . . . . . 77
F.13. Version -08 to -09 . . . . . . . . . . . . . . . . . . . 77 F.13. Version -09 to -10 . . . . . . . . . . . . . . . . . . . 77
F.14. Version -07 to -08 . . . . . . . . . . . . . . . . . . . 77 F.14. Version -08 to -09 . . . . . . . . . . . . . . . . . . . 77
F.15. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 77 F.15. Version -07 to -08 . . . . . . . . . . . . . . . . . . . 77
F.16. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 78 F.16. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 78
F.17. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 78 F.17. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 78
F.18. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 78 F.18. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 78
F.19. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 78 F.19. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 78
F.20. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 79 F.20. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 78
F.21. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 79 F.21. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 79
F.22. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 79
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 80
1. Introduction 1. Introduction
Authorization is the process for granting approval to an entity to Authorization is the process for granting approval to an entity to
access a resource [RFC4949]. The authorization task itself can best access a resource [RFC4949]. The authorization task itself can best
be described as granting access to a requesting client, for a be described as granting access to a requesting client, for a
resource hosted on a device, the resource server (RS). This exchange resource hosted on a device, the resource server (RS). This exchange
is mediated by one or multiple authorization servers (AS). Managing is mediated by one or multiple authorization servers (AS). Managing
authorization for a large number of devices and users can be a authorization for a large number of devices and users can be a
skipping to change at page 6, line 49 skipping to change at page 6, line 49
format COSE [RFC8152], which enables application layer security as an format COSE [RFC8152], which enables application layer security as an
alternative or complement to transport layer security (DTLS [RFC6347] alternative or complement to transport layer security (DTLS [RFC6347]
or TLS [RFC8446]). COSE is used to secure self-contained tokens such or TLS [RFC8446]). COSE is used to secure self-contained tokens such
as proof-of-possession (PoP) tokens, which is an extension to the as proof-of-possession (PoP) tokens, which is an extension to the
OAuth tokens. The default token format is defined in CBOR web token OAuth tokens. The default token format is defined in CBOR web token
(CWT) [RFC8392]. Application layer security for CoAP using COSE can (CWT) [RFC8392]. Application layer security for CoAP using COSE can
be provided with OSCORE [I-D.ietf-core-object-security]. be provided with OSCORE [I-D.ietf-core-object-security].
With the building blocks listed above, solutions satisfying various With the building blocks listed above, solutions satisfying various
IoT device and network constraints are possible. A list of IoT device and network constraints are possible. A list of
constraints is described in detail in RFC 7228 [RFC7228] and a constraints is described in detail in [RFC7228] and a description of
description of how the building blocks mentioned above relate to the how the building blocks mentioned above relate to the various
various constraints can be found in Appendix A. constraints can be found in Appendix A.
Luckily, not every IoT device suffers from all constraints. The ACE Luckily, not every IoT device suffers from all constraints. The ACE
framework nevertheless takes all these aspects into account and framework nevertheless takes all these aspects into account and
allows several different deployment variants to co-exist, rather than allows several different deployment variants to co-exist, rather than
mandating a one-size-fits-all solution. It is important to cover the mandating a one-size-fits-all solution. It is important to cover the
wide range of possible interworking use cases and the different wide range of possible interworking use cases and the different
requirements from a security point of view. Once IoT deployments requirements from a security point of view. Once IoT deployments
mature, popular deployment variants will be documented in the form of mature, popular deployment variants will be documented in the form of
ACE profiles. ACE profiles.
skipping to change at page 11, line 29 skipping to change at page 11, line 29
from an AS using the token endpoint and subsequently presents the from an AS using the token endpoint and subsequently presents the
access token to a RS to gain access to a protected resource. In most access token to a RS to gain access to a protected resource. In most
deployments the RS can process the access token locally, however in deployments the RS can process the access token locally, however in
some cases the RS may present it to the AS via the introspection some cases the RS may present it to the AS via the introspection
endpoint to get fresh information. These interactions are shown in endpoint to get fresh information. These interactions are shown in
Figure 1. An overview of various OAuth concepts is provided in Figure 1. An overview of various OAuth concepts is provided in
Section 3.1. Section 3.1.
The OAuth 2.0 framework defines a number of "protocol flows" via The OAuth 2.0 framework defines a number of "protocol flows" via
grant types, which have been extended further with extensions to grant types, which have been extended further with extensions to
OAuth 2.0 (such as RFC 7521 [RFC7521] and OAuth 2.0 (such as [RFC7521] and [I-D.ietf-oauth-device-flow]). What
[I-D.ietf-oauth-device-flow]). What grant types works best depends grant types works best depends on the usage scenario and [RFC7744]
on the usage scenario and RFC 7744 [RFC7744] describes many different describes many different IoT use cases but there are two preferred
IoT use cases but there are two preferred grant types, namely the grant types, namely the Authorization Code Grant (described in
Authorization Code Grant (described in Section 4.1 of [RFC7521]) and Section 4.1 of [RFC7521]) and the Client Credentials Grant (described
the Client Credentials Grant (described in Section 4.4 of [RFC7521]). in Section 4.4 of [RFC7521]). The Authorization Code Grant is a good
The Authorization Code Grant is a good fit for use with apps running fit for use with apps running on smart phones and tablets that
on smart phones and tablets that request access to IoT devices, a request access to IoT devices, a common scenario in the smart home
common scenario in the smart home environment, where users need to go environment, where users need to go through an authentication and
through an authentication and authorization phase (at least during authorization phase (at least during the initial setup phase). The
the initial setup phase). The native apps guidelines described in native apps guidelines described in [RFC8252] are applicable to this
[RFC8252] are applicable to this use case. The Client Credential use case. The Client Credential Grant is a good fit for use with IoT
Grant is a good fit for use with IoT devices where the OAuth client devices where the OAuth client itself is constrained. In such a
itself is constrained. In such a case, the resource owner has pre- case, the resource owner has pre-arranged access rights for the
arranged access rights for the client with the authorization server, client with the authorization server, which is often accomplished
which is often accomplished using a commissioning tool. using a commissioning tool.
The consent of the resource owner, for giving a client access to a The consent of the resource owner, for giving a client access to a
protected resource, can be provided dynamically as in the traditional protected resource, can be provided dynamically as in the traditional
OAuth flows, or it could be pre-configured by the resource owner as OAuth flows, or it could be pre-configured by the resource owner as
authorization policies at the AS, which the AS evaluates when a token authorization policies at the AS, which the AS evaluates when a token
request arrives. The resource owner and the requesting party (i.e., request arrives. The resource owner and the requesting party (i.e.,
client owner) are not shown in Figure 1. client owner) are not shown in Figure 1.
This framework supports a wide variety of communication security This framework supports a wide variety of communication security
mechanisms between the ACE entities, such as client, AS, and RS. It mechanisms between the ACE entities, such as client, AS, and RS. It
skipping to change at page 18, line 33 skipping to change at page 18, line 33
be transformed to "coaps://as.example.com/token". It is assumed that be transformed to "coaps://as.example.com/token". It is assumed that
the client can determine the correct schema part on its own depending the client can determine the correct schema part on its own depending
on the way it communicates with the AS. on the way it communicates with the AS.
Figure 3 shows an example for an AS Request Creation Hints message Figure 3 shows an example for an AS Request Creation Hints message
payload using CBOR [RFC7049] diagnostic notation, using the parameter payload using CBOR [RFC7049] diagnostic notation, using the parameter
names instead of the CBOR keys for better human readability. names instead of the CBOR keys for better human readability.
4.01 Unauthorized 4.01 Unauthorized
Content-Format: application/ace+cbor Content-Format: application/ace+cbor
{AS: "coaps://as.example.com/token", {"AS" : "coaps://as.example.com/token",
audience: "coaps://rs.example.com", "nonce" : h'e0a156bb3f',
nonce: h'e0a156bb3f', "scope" : "rTempC",
scope: "rTempC" "audience" : "coaps://rs.example.com"
} }
Figure 3: AS Request Creation Hints payload example Figure 3: AS Request Creation Hints payload example
In this example, the attribute AS points the receiver of this message In this example, the attribute AS points the receiver of this message
to the URI "coaps://as.example.com/token" to request access to the URI "coaps://as.example.com/token" to request access
permissions. The originator of the AS Request Creation Hints payload permissions. The originator of the AS Request Creation Hints payload
(i.e., RS) uses a local clock that is loosely synchronized with a (i.e., RS) uses a local clock that is loosely synchronized with a
time scale common between RS and AS (e.g., wall clock time). time scale common between RS and AS (e.g., wall clock time).
Therefore, it has included a parameter "nonce" for replay attack Therefore, it has included a parameter "nonce" for replay attack
prevention. prevention.
Figure 4 illustrates the mandatory to use binary encoding of the Figure 4 illustrates the mandatory to use binary encoding of the
message payload shown in Figure 3. message payload shown in Figure 3.
a2 # map(2) a4 # map(4)
00 # unsigned(0) (=AS) 00 # unsigned(0) (=AS)
78 1c # text(28) 78 1c # text(28)
636f6170733a2f2f61732e657861 636f6170733a2f2f61732e657861
6d706c652e636f6d2f746f6b656e # "coaps://as.example.com/token" 6d706c652e636f6d2f746f6b656e # "coaps://as.example.com/token"
05 # unsigned(5) (=nonce) 05 # unsigned(5) (=nonce)
45 # bytes(5) 45 # bytes(5)
e0a156bb3f e0a156bb3f # "\xE0\xA1V\xBB?"
09 # unsigned(9) (=scope)
66 # text(6)
7254656d7043 # "rTempC"
12 # unsigned(18) (=audience)
76 # text(22)
636f6170733a2f2f72732e657861
6d706c652e636f6d # "coaps://rs.example.com"
Figure 4: AS Request Creation Hints example encoded in CBOR Figure 4: AS Request Creation Hints example encoded in CBOR
5.2. Authorization Grants 5.2. Authorization Grants
To request an access token, the client obtains authorization from the To request an access token, the client obtains authorization from the
resource owner or uses its client credentials as grant. The resource owner or uses its client credentials as grant. The
authorization is expressed in the form of an authorization grant. authorization is expressed in the form of an authorization grant.
The OAuth framework [RFC6749] defines four grant types. The grant The OAuth framework [RFC6749] defines four grant types. The grant
skipping to change at page 19, line 38 skipping to change at page 19, line 45
The grant type is selected depending on the use case. In cases where The grant type is selected depending on the use case. In cases where
the client acts on behalf of the resource owner, authorization code the client acts on behalf of the resource owner, authorization code
grant is recommended. If the client acts on behalf of the resource grant is recommended. If the client acts on behalf of the resource
owner, but does not have any display or very limited interaction owner, but does not have any display or very limited interaction
possibilities it is recommended to use the device code grant defined possibilities it is recommended to use the device code grant defined
in [I-D.ietf-oauth-device-flow]. In cases where the client does not in [I-D.ietf-oauth-device-flow]. In cases where the client does not
act on behalf of the resource owner, client credentials grant is act on behalf of the resource owner, client credentials grant is
recommended. recommended.
For details on the different grant types, see the OAuth 2.0 framework For details on the different grant types, see section 1.3 of
[RFC6749]. The OAuth 2.0 framework provides an extension mechanism [RFC6749]. The OAuth 2.0 framework provides an extension mechanism
for defining additional grant types so profiles of this framework MAY for defining additional grant types so profiles of this framework MAY
define additional grant types, if needed. define additional grant types, if needed.
5.3. Client Credentials 5.3. Client Credentials
Authentication of the client is mandatory independent of the grant Authentication of the client is mandatory independent of the grant
type when requesting the access token from the token endpoint. In type when requesting the access token from the token endpoint. In
the case of client credentials grant type, the authentication and the case of client credentials grant type, the authentication and
grant coincide. grant coincide.
Client registration and provisioning of client credentials to the Client registration and provisioning of client credentials to the
client is out of scope for this specification. client is out of scope for this specification.
The OAuth framework [RFC6749] defines one client credential type, The OAuth framework defines one client credential type in section
client id and client secret. [I-D.erdtman-ace-rpcc] adds raw-public- 2.3.1 of [RFC6749]: client id and client secret.
key and pre-shared-key to the client credentials types. Profiles of [I-D.erdtman-ace-rpcc] adds raw-public-key and pre-shared-key to the
this framework MAY extend with additional client credentials client client credentials types. Profiles of this framework MAY extend with
certificates. additional client credentials client certificates.
5.4. AS Authentication 5.4. AS Authentication
Client credential does not, by default, authenticate the AS that the Client credential does not, by default, authenticate the AS that the
client connects to. In classic OAuth, the AS is authenticated with a client connects to. In classic OAuth, the AS is authenticated with a
TLS server certificate. TLS server certificate.
Profiles of this framework MUST specify how clients authenticate the Profiles of this framework MUST specify how clients authenticate the
AS and how communication security is implemented, otherwise server AS and how communication security is implemented, otherwise server
side TLS certificates, as defined by OAuth 2.0, are required. side TLS certificates, as defined by OAuth 2.0, are required.
5.5. The Authorization Endpoint 5.5. The Authorization Endpoint
The authorization endpoint is used to interact with the resource The authorization endpoint is used to interact with the resource
owner and obtain an authorization grant in certain grant flows. owner and obtain an authorization grant in certain grant flows.
Since it requires the use of a user agent (i.e., browser), it is not Since it requires the use of a user agent (i.e., browser), it is not
expected that these types of grant flow will be used by constrained expected that these types of grant flow will be used by constrained
clients. This endpoint is therefore out of scope for this clients. This endpoint is therefore out of scope for this
specification. Implementations should use the definition and specification. Implementations should use the definition and
recommendations of [RFC6749] and [RFC6819]. recommendations of section 3.1 of [RFC6749] and of section 4.2 of
[RFC6819].
If clients involved cannot support HTTP and TLS, profiles MAY define If clients involved cannot support HTTP and TLS, profiles MAY define
mappings for the authorization endpoint. mappings for the authorization endpoint.
5.6. The Token Endpoint 5.6. The Token Endpoint
In standard OAuth 2.0, the AS provides the token endpoint for In standard OAuth 2.0, the AS provides the token endpoint for
submitting access token requests. This framework extends the submitting access token requests. This framework extends the
functionality of the token endpoint, giving the AS the possibility to functionality of the token endpoint, giving the AS the possibility to
help the client and RS to establish shared keys or to exchange their help the client and RS to establish shared keys or to exchange their
skipping to change at page 21, line 24 skipping to change at page 21, line 33
The figures of this section use CBOR diagnostic notation without the The figures of this section use CBOR diagnostic notation without the
integer abbreviations for the parameters or their values for integer abbreviations for the parameters or their values for
illustrative purposes. Note that implementations MUST use the illustrative purposes. Note that implementations MUST use the
integer abbreviations and the binary CBOR encoding, if the CBOR integer abbreviations and the binary CBOR encoding, if the CBOR
encoding is used. encoding is used.
5.6.1. Client-to-AS Request 5.6.1. Client-to-AS Request
The client sends a POST request to the token endpoint at the AS. The The client sends a POST request to the token endpoint at the AS. The
profile MUST specify how the communication is protected. The content profile MUST specify how the communication is protected. The content
of the request consists of the parameters specified in Section 4 of of the request consists of the parameters specified in the relevant
the OAuth 2.0 specification [RFC6749] with the exception of the subsection of section 4 of the OAuth 2.0 specification [RFC6749],
"grant_type" parameter, which is OPTIONAL in the context of this depending on the grant type. The parameter "grant_type" is an
framework (as opposed to REQUIRED in RFC6749). If that parameter is exception, as it is OPTIONAL in the context of this framework (as
missing, the default value "client_credentials" is implied. opposed to REQUIRED in RFC6749). If that parameter is missing, the
default value "client_credentials" is implied.
Furthermore the "audience" parameter from Furthermore the "audience" parameter from
[I-D.ietf-oauth-token-exchange] can be used to request an access [I-D.ietf-oauth-token-exchange] can be used to request an access
token bound to a specific audience. token bound to a specific audience.
In addition to these parameters, a client MUST be able to use the In addition to these parameters, a client MUST be able to use the
parameters from [I-D.ietf-ace-oauth-params] in an access token parameters from [I-D.ietf-ace-oauth-params] in an access token
request to the token endpoint and the AS MUST be able to process request to the token endpoint and the AS MUST be able to process
these additional parameters. these additional parameters.
If CBOR is used then this parameter MUST be encoded as a CBOR map. If CBOR is used then this parameter MUST be encoded as a CBOR map.
The "scope" parameter can be formatted as specified in [RFC6749] and The "scope" parameter can be formatted as specified in section 3.3 of
additionally as a byte string, in order to allow compact encoding of [RFC6749] and additionally as a byte string, in order to allow
complex scopes. compact encoding of complex scopes.
When HTTP is used as a transport then the client makes a request to When HTTP is used as a transport then the client makes a request to
the token endpoint by sending the parameters using the "application/ the token endpoint by sending the parameters using the "application/
x-www-form-urlencoded" format with a character encoding of UTF-8 in x-www-form-urlencoded" format with a character encoding of UTF-8 in
the HTTP request entity-body, as defined in RFC 6749. the HTTP request entity-body, as defined in section 3.2 of [RFC6749].
The following examples illustrate different types of requests for The following examples illustrate different types of requests for
proof-of-possession tokens. proof-of-possession tokens.
Figure 5 shows a request for a token with a symmetric proof-of- Figure 5 shows a request for a token with a symmetric proof-of-
possession key. The content is displayed in CBOR diagnostic possession key. The content is displayed in CBOR diagnostic
notation, without abbreviations for better readability. notation, without abbreviations for better readability.
Header: POST (Code=0.02) Header: POST (Code=0.02)
Uri-Host: "as.example.com" Uri-Host: "as.example.com"
skipping to change at page 28, line 18 skipping to change at page 28, line 18
| password | 0 | RFC6749 | | password | 0 | RFC6749 |
| authorization_code | 1 | RFC6749 | | authorization_code | 1 | RFC6749 |
| client_credentials | 2 | RFC6749 | | client_credentials | 2 | RFC6749 |
| refresh_token | 3 | RFC6749 | | refresh_token | 3 | RFC6749 |
\--------------------+------------+------------------------/ \--------------------+------------+------------------------/
Figure 11: CBOR abbreviations for common grant types Figure 11: CBOR abbreviations for common grant types
5.6.4.2. Token Type 5.6.4.2. Token Type
The "token_type" parameter, defined in [RFC6749], allows the AS to The "token_type" parameter, defined in section 5.1 of [RFC6749],
indicate to the client which type of access token it is receiving allows the AS to indicate to the client which type of access token it
(e.g., a bearer token). is receiving (e.g., a bearer token).
This document registers the new value "pop" for the OAuth Access This document registers the new value "pop" for the OAuth Access
Token Types registry, specifying a proof-of-possession token. How Token Types registry, specifying a proof-of-possession token. How
the proof-of-possession by the client to the RS is performed MUST be the proof-of-possession by the client to the RS is performed MUST be
specified by the profiles. specified by the profiles.
The values in the "token_type" parameter MUST be CBOR text strings, The values in the "token_type" parameter MUST be CBOR text strings,
if a CBOR encoding is used. if a CBOR encoding is used.
In this framework the "pop" value for the "token_type" parameter is In this framework the "pop" value for the "token_type" parameter is
skipping to change at page 29, line 50 skipping to change at page 29, line 50
| profile | 39 | unsigned integer | | profile | 39 | unsigned integer |
\-------------------+----------+---------------------/ \-------------------+----------+---------------------/
Figure 12: CBOR mappings used in token requests Figure 12: CBOR mappings used in token requests
5.7. The Introspection Endpoint 5.7. The Introspection Endpoint
Token introspection [RFC7662] can be OPTIONALLY provided by the AS, Token introspection [RFC7662] can be OPTIONALLY provided by the AS,
and is then used by the RS and potentially the client to query the AS and is then used by the RS and potentially the client to query the AS
for metadata about a given token, e.g., validity or scope. Analogous for metadata about a given token, e.g., validity or scope. Analogous
to the protocol defined in RFC 7662 [RFC7662] for HTTP and JSON, this to the protocol defined in [RFC7662] for HTTP and JSON, this section
section defines adaptations to more constrained environments using defines adaptations to more constrained environments using CBOR and
CBOR and leaving the choice of the application protocol to the leaving the choice of the application protocol to the profile.
profile.
Communication between the requesting entity and the introspection Communication between the requesting entity and the introspection
endpoint at the AS MUST be integrity protected and encrypted. The endpoint at the AS MUST be integrity protected and encrypted. The
communication security protocol MUST also provide a binding between communication security protocol MUST also provide a binding between
requests and responses. Furthermore the two interacting parties MUST requests and responses. Furthermore the two interacting parties MUST
perform mutual authentication. Finally the AS SHOULD verify that the perform mutual authentication. Finally the AS SHOULD verify that the
requesting entity has the right to access introspection information requesting entity has the right to access introspection information
about the provided token. Profiles of this framework that support about the provided token. Profiles of this framework that support
introspection MUST specify how authentication and communication introspection MUST specify how authentication and communication
security between the requesting entity and the AS is implemented. security between the requesting entity and the AS is implemented.
skipping to change at page 30, line 43 skipping to change at page 30, line 41
map with a "token" entry containing either the access token or a map with a "token" entry containing either the access token or a
reference to the token (e.g., the cti). Further optional parameters reference to the token (e.g., the cti). Further optional parameters
representing additional context that is known by the requesting representing additional context that is known by the requesting
entity to aid the AS in its response MAY be included. entity to aid the AS in its response MAY be included.
For CoAP-based interaction, all messages MUST use the content type For CoAP-based interaction, all messages MUST use the content type
"application/ace+cbor", while for HTTP-based interactions the "application/ace+cbor", while for HTTP-based interactions the
equivalent media type "application/ace+cbor" MUST be used. equivalent media type "application/ace+cbor" MUST be used.
The same parameters are required and optional as in Section 2.1 of The same parameters are required and optional as in Section 2.1 of
RFC 7662 [RFC7662]. [RFC7662].
For example, Figure 13 shows a RS calling the token introspection For example, Figure 13 shows a RS calling the token introspection
endpoint at the AS to query about an OAuth 2.0 proof-of-possession endpoint at the AS to query about an OAuth 2.0 proof-of-possession
token. Note that object security based on OSCORE token. Note that object security based on OSCORE
[I-D.ietf-core-object-security] is assumed in this example, therefore [I-D.ietf-core-object-security] is assumed in this example, therefore
the Content-Format is "application/oscore". Figure 14 shows the the Content-Format is "application/oscore". Figure 14 shows the
decoded payload. decoded payload.
Header: POST (Code=0.02) Header: POST (Code=0.02)
Uri-Host: "as.example.com" Uri-Host: "as.example.com"
skipping to change at page 31, line 32 skipping to change at page 31, line 32
5.7.2. Introspection Response 5.7.2. Introspection Response
If the introspection request is authorized and successfully If the introspection request is authorized and successfully
processed, the AS sends a response with the response code equivalent processed, the AS sends a response with the response code equivalent
to the CoAP code 2.01 (Created). If the introspection request was to the CoAP code 2.01 (Created). If the introspection request was
invalid, not authorized or couldn't be processed the AS returns an invalid, not authorized or couldn't be processed the AS returns an
error response as described in Section 5.7.3. error response as described in Section 5.7.3.
In a successful response, the AS encodes the response parameters in a In a successful response, the AS encodes the response parameters in a
map including with the same required and optional parameters as in map including with the same required and optional parameters as in
Section 2.2 of RFC 7662 [RFC7662] with the following addition: Section 2.2 of [RFC7662] with the following addition:
profile OPTIONAL. This indicates the profile that the RS MUST use profile OPTIONAL. This indicates the profile that the RS MUST use
with the client. See Section 5.6.4.3 for more details on the with the client. See Section 5.6.4.3 for more details on the
formatting of this parameter. formatting of this parameter.
Furthermore [I-D.ietf-ace-oauth-params] defines more parameters that Furthermore [I-D.ietf-ace-oauth-params] defines more parameters that
the AS MUST be able to use when responding to a request to the the AS MUST be able to use when responding to a request to the
introspection endpoint. introspection endpoint.
For example, Figure 15 shows an AS response to the introspection For example, Figure 15 shows an AS response to the introspection
skipping to change at page 32, line 36 skipping to change at page 32, line 36
equivalent to the ones for HTTP-based interactions as defined in equivalent to the ones for HTTP-based interactions as defined in
Section 2.3 of [RFC7662], with the following differences: Section 2.3 of [RFC7662], with the following differences:
o If content is sent and CBOR is used the payload MUST be encoded as o If content is sent and CBOR is used the payload MUST be encoded as
a CBOR map and the Content-Format "application/ace+cbor" MUST be a CBOR map and the Content-Format "application/ace+cbor" MUST be
used. used.
o If the credentials used by the requesting entity (usually the RS) o If the credentials used by the requesting entity (usually the RS)
are invalid the AS MUST respond with the response code equivalent are invalid the AS MUST respond with the response code equivalent
to the CoAP code 4.01 (Unauthorized) and use the required and to the CoAP code 4.01 (Unauthorized) and use the required and
optional parameters from Section 5.2 in RFC 6749 [RFC6749]. optional parameters from Section 5.2 in [RFC6749].
o If the requesting entity does not have the right to perform this o If the requesting entity does not have the right to perform this
introspection request, the AS MUST respond with a response code introspection request, the AS MUST respond with a response code
equivalent to the CoAP code 4.03 (Forbidden). In this case no equivalent to the CoAP code 4.03 (Forbidden). In this case no
payload is returned. payload is returned.
o The parameters "error", "error_description" and "error_uri" MUST o The parameters "error", "error_description" and "error_uri" MUST
be abbreviated using the codes specified in Figure 12. be abbreviated using the codes specified in Figure 12.
o The error codes MUST be abbreviated using the codes specified in o The error codes MUST be abbreviated using the codes specified in
skipping to change at page 36, line 23 skipping to change at page 36, line 23
and, in case of an interaction via the authz-info endpoint, return and, in case of an interaction via the authz-info endpoint, return
an error message with a response code equivalent to the CoAP code an error message with a response code equivalent to the CoAP code
4.00 (Bad Request). 4.00 (Bad Request).
Next, the RS MUST verify claims, if present, contained in the access Next, the RS MUST verify claims, if present, contained in the access
token. Errors are returned when claim checks fail, in the order of token. Errors are returned when claim checks fail, in the order of
priority of this list: priority of this list:
iss The issuer claim must identify an AS that has the authority to iss The issuer claim must identify an AS that has the authority to
issue access tokens for the receiving RS. If that is not the case issue access tokens for the receiving RS. If that is not the case
the RS MUST respond with a response code equivalent to the CoAP the RS MUST discard the token. If this was an interaction with
code 4.01 (Unauthorized). authz-info, the RS MUST also respond with a response code
equivalent to the CoAP code 4.01 (Unauthorized).
exp The expiration date must be in the future. If that is not the exp The expiration date must be in the future. If that is not the
case the RS MUST respond with a response code equivalent to the case the RS MUST discard the token. If this was an interaction
CoAP code 4.01 (Unauthorized). Note that the RS has to terminate with authz-info the RS MUST also respond with a response code
access rights to the protected resources at the time when the equivalent to the CoAP code 4.01 (Unauthorized). Note that the RS
tokens expire. has to terminate access rights to the protected resources at the
time when the tokens expire.
aud The audience claim must refer to an audience that the RS aud The audience claim must refer to an audience that the RS
identifies with. If that is not the case the RS MUST respond with identifies with. If that is not the case the RS MUST discard the
a response code equivalent to the CoAP code 4.03 (Forbidden). token. If this was an interaction with authz-info, the RS MUST
also respond with a response code equivalent to the CoAP code 4.03
(Forbidden).
scope The RS must recognize value of the scope claim. If that is scope The RS must recognize value of the scope claim. If that is
not the case the RS MUST respond with a response code equivalent not the case the RS MUST discard the token. If this was an
to the CoAP code 4.00 (Bad Request). The RS MAY provide interaction with authz-info, the RS MUST also respond with a
additional information in the error response, to clarify what went response code equivalent to the CoAP code 4.00 (Bad Request). The
wrong. RS MAY provide additional information in the error response, to
clarify what went wrong.
If the access token contains any other claims that the RS cannot If the access token contains any other claims that the RS cannot
process the RS MUST respond with a response code equivalent to the process the RS MUST discard the token. If this was an interaction
CoAP code 4.00 (Bad Request). The RS MAY provide additional detail with authz-info, the RS MUST also respond with a response code
in the error response to clarify which claim couldn't be processed. equivalent to the CoAP code 4.00 (Bad Request). The RS MAY provide
additional detail in the error response to clarify which claim
couldn't be processed.
Note that the Subject (sub) claim cannot always be verified when the Note that the Subject (sub) claim cannot always be verified when the
token is submitted to the RS since the client may not have token is submitted to the RS since the client may not have
authenticated yet. Also note that a counter for the expires_in (exi) authenticated yet. Also note that a counter for the expires_in (exi)
claim MUST be initialized when the RS first verifies this token. claim MUST be initialized when the RS first verifies this token.
Also note that profiles of this framework may define access token
transport mechanisms that do not allow for error responses.
Therefore the error messages specified here only apply if the token
was POSTed to the authz-info endpoint.
When sending error responses, the RS MAY use the error codes from When sending error responses, the RS MAY use the error codes from
Section 3.1 of [RFC6750], to provide additional details to the Section 3.1 of [RFC6750], to provide additional details to the
client. client.
5.8.1.2. Protecting the Authorization Information Endpoint 5.8.1.2. Protecting the Authorization Information Endpoint
As this framework can be used in RESTful environments, it is As this framework can be used in RESTful environments, it is
important to make sure that attackers cannot perform unauthorized important to make sure that attackers cannot perform unauthorized
requests on the auth-info endpoints, other than submitting access requests on the auth-info endpoints, other than submitting access
tokens. tokens.
skipping to change at page 39, line 5 skipping to change at page 39, line 13
in some regular intervals, so that the can AS provide the RS with in some regular intervals, so that the can AS provide the RS with
a list of expired tokens. The drawback of this mitigation is that a list of expired tokens. The drawback of this mitigation is that
the RS might as well use the communication with the AS to the RS might as well use the communication with the AS to
synchronize its internal clock. synchronize its internal clock.
If a token that authorizes a long running request such as a CoAP If a token that authorizes a long running request such as a CoAP
Observe [RFC7641] expires, the RS MUST send an error response with Observe [RFC7641] expires, the RS MUST send an error response with
the response code equivalent to the CoAP code 4.01 (Unauthorized) to the response code equivalent to the CoAP code 4.01 (Unauthorized) to
the client and then terminate processing the long running request. the client and then terminate processing the long running request.
5.8.4. Key Expriation 5.8.4. Key Expiration
The AS provides the client with key material that the RS uses. This The AS provides the client with key material that the RS uses. This
can either be a common symmetric pop-key, or an asymmetric key used can either be a common symmetric pop-key, or an asymmetric key used
by the RS to authenticate towards the client. Since there is no by the RS to authenticate towards the client. Since there is no
metadata associated to those keys, the client has no way of knowing metadata associated to those keys, the client has no way of knowing
if these keys are still valid. This may lead to situations where the if these keys are still valid. This may lead to situations where the
client sends requests containing sensitive information to the RS client sends requests containing sensitive information to the RS
using a key that is expired and possibly in the hands of an attacker, using a key that is expired and possibly in the hands of an attacker,
or accepts responses from the RS that are not properly protected and or accepts responses from the RS that are not properly protected and
could possibly have been forged by an attacker. could possibly have been forged by an attacker.
skipping to change at page 45, line 23 skipping to change at page 45, line 35
detailed information may be included with an error response to detailed information may be included with an error response to
provide C with sufficient information to react on that particular provide C with sufficient information to react on that particular
error. error.
8. IANA Considerations 8. IANA Considerations
8.1. ACE Authorization Server Request Creation Hints 8.1. ACE Authorization Server Request Creation Hints
This specification establishes the IANA "ACE Authorization Server This specification establishes the IANA "ACE Authorization Server
Request Creation Hints" registry. The registry has been created to Request Creation Hints" registry. The registry has been created to
use the "Expert Review Required" registration procedure [RFC8126]. use the "Expert Review" registration procedure [RFC8126]. It should
It should be noted that, in addition to the expert review, some be noted that, in addition to the expert review, some portions of the
portions of the registry require a specification, potentially a registry require a specification, potentially a Standards Track RFC,
Standards Track RFC, be supplied as well. be supplied as well.
The columns of the registry are: The columns of the registry are:
Name The name of the parameter Name The name of the parameter
CBOR Key CBOR map key for the parameter. Different ranges of values CBOR Key CBOR map key for the parameter. Different ranges of values
use different registration policies [RFC8126]. Integer values use different registration policies [RFC8126]. Integer values
from -256 to 255 are designated as Standards Action. Integer from -256 to 255 are designated as Standards Action. Integer
values from -65536 to -257 and from 256 to 65535 are designated as values from -65536 to -257 and from 256 to 65535 are designated as
Specification Required. Integer values greater than 65535 are Specification Required. Integer values greater than 65535 are
skipping to change at page 46, line 11 skipping to change at page 46, line 20
This registry will be initially populated by the values in Figure 2. This registry will be initially populated by the values in Figure 2.
The Reference column for all of these entries will be this document. The Reference column for all of these entries will be this document.
8.2. OAuth Extensions Error Registration 8.2. OAuth Extensions Error Registration
This specification registers the following error values in the OAuth This specification registers the following error values in the OAuth
Extensions Error registry defined in [RFC6749]. Extensions Error registry defined in [RFC6749].
o Error name: "unsupported_pop_key" o Error name: "unsupported_pop_key"
o Error usage location: AS token endpoint error response o Error usage location: token error response
o Related protocol extension: The ACE framework [this document] o Related protocol extension: The ACE framework [this document]
o Change Controller: IESG o Change Controller: IESG
o Specification document(s): Section 5.6.3 of [this document] o Specification document(s): Section 5.6.3 of [this document]
o Error name: "incompatible_profiles" o Error name: "incompatible_profiles"
o Error usage location: AS token endpoint error response o Error usage location: token error response
o Related protocol extension: The ACE framework [this document] o Related protocol extension: The ACE framework [this document]
o Change Controller: IESG o Change Controller: IESG
o Specification document(s): Section 5.6.3 of [this document] o Specification document(s): Section 5.6.3 of [this document]
8.3. OAuth Error Code CBOR Mappings Registry 8.3. OAuth Error Code CBOR Mappings Registry
This specification establishes the IANA "OAuth Error Code CBOR This specification establishes the IANA "OAuth Error Code CBOR
Mappings" registry. The registry has been created to use the "Expert Mappings" registry. The registry has been created to use the "Expert
Review Required" registration procedure [RFC8126]. It should be Review" registration procedure [RFC8126], except for the value range
noted that, in addition to the expert review, some portions of the designated for private use.
registry require a specification, potentially a Standards Track RFC,
be supplied as well.
The columns of the registry are: The columns of the registry are:
Name The OAuth Error Code name, refers to the name in Section 5.2. Name The OAuth Error Code name, refers to the name in Section 5.2.
of [RFC6749], e.g., "invalid_request". of [RFC6749], e.g., "invalid_request".
CBOR Value CBOR abbreviation for this error code. Different ranges CBOR Value CBOR abbreviation for this error code. Integer values
of values use different registration policies [RFC8126]. Integer less than -65536 are marked as "Private Use", all other values use
values from -256 to 255 are designated as Standards Action. the registration policy "Expert Review" [RFC8126].
Integer values from -65536 to -257 and from 256 to 65535 are
designated as Specification Required. Integer values greater than
65535 are designated as Expert Review. Integer values less than
-65536 are marked as Private Use.
Reference This contains a pointer to the public specification of the Reference This contains a pointer to the public specification of the
grant type abbreviation, if one exists. grant type abbreviation, if one exists.
This registry will be initially populated by the values in Figure 10. This registry will be initially populated by the values in Figure 10.
The Reference column for all of these entries will be this document. The Reference column for all of these entries will be this document.
8.4. OAuth Grant Type CBOR Mappings 8.4. OAuth Grant Type CBOR Mappings
This specification establishes the IANA "OAuth Grant Type CBOR This specification establishes the IANA "OAuth Grant Type CBOR
Mappings" registry. The registry has been created to use the "Expert Mappings" registry. The registry has been created to use the "Expert
Review Required" registration procedure [RFC8126]. It should be Review" registration procedure [RFC8126], except for the value range
noted that, in addition to the expert review, some portions of the designated for private use.
registry require a specification, potentially a Standards Track RFC,
be supplied as well.
The columns of this registry are: The columns of this registry are:
Name The name of the grant type as specified in Section 1.3 of Name The name of the grant type as specified in Section 1.3 of
[RFC6749]. [RFC6749].
CBOR Value CBOR abbreviation for this grant type. Different ranges CBOR Value CBOR abbreviation for this grant type. Integer values
of values use different registration policies [RFC8126]. Integer less than -65536 are marked as "Private Use", all other values use
values from -256 to 255 are designated as Standards Action. the registration policy "Expert Review" [RFC8126].
Integer values from -65536 to -257 and from 256 to 65535 are
designated as Specification Required. Integer values greater than
65535 are designated as Expert Review. Integer values less than
-65536 are marked as Private Use.
Reference This contains a pointer to the public specification of the Reference This contains a pointer to the public specification of the
grant type abbreviation, if one exists. grant type abbreviation, if one exists.
Original Specification This contains a pointer to the public Original Specification This contains a pointer to the public
specification of the grant type, if one exists. specification of the grant type, if one exists.
This registry will be initially populated by the values in Figure 11. This registry will be initially populated by the values in Figure 11.
The Reference column for all of these entries will be this document. The Reference column for all of these entries will be this document.
8.5. OAuth Access Token Types 8.5. OAuth Access Token Types
This section registers the following new token type in the "OAuth This section registers the following new token type in the "OAuth
Access Token Types" registry [IANA.OAuthAccessTokenTypes]. Access Token Types" registry [IANA.OAuthAccessTokenTypes].
o Name: "PoP" o Type name: "PoP"
o Additional Token Endpoint Response Parameters: "cnf", "rs_cnf" see
section 3.3 of [I-D.ietf-ace-oauth-params].
o HTTP Authentication Scheme(s): N/A
o Change Controller: IETF o Change Controller: IETF
o Reference: [this document] o Specification document(s): [this document]
8.6. OAuth Access Token Type CBOR Mappings 8.6. OAuth Access Token Type CBOR Mappings
This specification established the IANA "OAuth Access Token Type CBOR This specification established the IANA "OAuth Access Token Type CBOR
Mappings" registry. The registry has been created to use the "Expert Mappings" registry. The registry has been created to use the "Expert
Review Required" registration procedure [RFC8126]. It should be Review" registration procedure [RFC8126], except for the value range
noted that, in addition to the expert review, some portions of the designated for private use.
registry require a specification, potentially a Standards Track RFC,
be supplied as well.
The columns of this registry are: The columns of this registry are:
Name The name of token type as registered in the OAuth Access Token Name The name of token type as registered in the OAuth Access Token
Types registry, e.g., "Bearer". Types registry, e.g., "Bearer".
CBOR Value CBOR abbreviation for this token type. Different ranges CBOR Value CBOR abbreviation for this token type. Integer values
of values use different registration policies [RFC8126]. Integer less than -65536 are marked as "Private Use", all other values use
values from -256 to 255 are designated as Standards Action. the registration policy "Expert Review" [RFC8126].
Integer values from -65536 to -257 and from 256 to 65535 are
designated as Specification Required. Integer values greater than
65535 are designated as Expert Review. Integer values less than
-65536 are marked as Private Use.
Reference This contains a pointer to the public specification of the Reference This contains a pointer to the public specification of the
OAuth token type abbreviation, if one exists. OAuth token type abbreviation, if one exists.
Original Specification This contains a pointer to the public Original Specification This contains a pointer to the public
specification of the grant type, if one exists. specification of the grant type, if one exists.
8.6.1. Initial Registry Contents 8.6.1. Initial Registry Contents
o Name: "Bearer" o Name: "Bearer"
o Value: 1 o Value: 1
o Reference: [this document] o Reference: [this document]
o Original Specification: [RFC6749] o Original Specification: [RFC6749]
o Name: "pop" o Name: "pop"
o Value: 2 o Value: 2
o Reference: [this document] o Reference: [this document]
o Original Specification: [this document] o Original Specification: [this document]
8.7. ACE Profile Registry 8.7. ACE Profile Registry
This specification establishes the IANA "ACE Profile" registry. The This specification establishes the IANA "ACE Profile" registry. The
registry has been created to use the "Expert Review Required" registry has been created to use the "Expert Review" registration
registration procedure [RFC8126]. It should be noted that, in procedure [RFC8126]. It should be noted that, in addition to the
addition to the expert review, some portions of the registry require expert review, some portions of the registry require a specification,
a specification, potentially a Standards Track RFC, be supplied as potentially a Standards Track RFC, be supplied as well.
well.
The columns of this registry are: The columns of this registry are:
Name The name of the profile, to be used as value of the profile Name The name of the profile, to be used as value of the profile
attribute. attribute.
Description Text giving an overview of the profile and the context Description Text giving an overview of the profile and the context
it is developed for. it is developed for.
CBOR Value CBOR abbreviation for this profile name. Different CBOR Value CBOR abbreviation for this profile name. Different
ranges of values use different registration policies [RFC8126]. ranges of values use different registration policies [RFC8126].
Integer values from -256 to 255 are designated as Standards Integer values from -256 to 255 are designated as Standards
Action. Integer values from -65536 to -257 and from 256 to 65535 Action. Integer values from -65536 to -257 and from 256 to 65535
are designated as Specification Required. Integer values greater are designated as Specification Required. Integer values greater
than 65535 are designated as Expert Review. Integer values less than 65535 are designated as "Expert Review". Integer values less
than -65536 are marked as Private Use. than -65536 are marked as Private Use.
Reference This contains a pointer to the public specification of the Reference This contains a pointer to the public specification of the
profile abbreviation, if one exists. profile abbreviation, if one exists.
This registry will be initially empty and will be populated by the This registry will be initially empty and will be populated by the
registrations from the ACE framework profiles. registrations from the ACE framework profiles.
8.8. OAuth Parameter Registration 8.8. OAuth Parameter Registration
This specification registers the following parameter in the "OAuth This specification registers the following parameter in the "OAuth
skipping to change at page 49, line 19 skipping to change at page 49, line 19
o Name: "profile" o Name: "profile"
o Parameter Usage Location: token response o Parameter Usage Location: token response
o Change Controller: IESG o Change Controller: IESG
o Reference: Section 5.6.4.3 of [this document] o Reference: Section 5.6.4.3 of [this document]
8.9. OAuth Parameters CBOR Mappings Registry 8.9. OAuth Parameters CBOR Mappings Registry
This specification establishes the IANA "OAuth Parameters CBOR This specification establishes the IANA "OAuth Parameters CBOR
Mappings" registry. The registry has been created to use the "Expert Mappings" registry. The registry has been created to use the "Expert
Review Required" registration procedure [RFC8126]. It should be Review" registration procedure [RFC8126], except for the value range
noted that, in addition to the expert review, some portions of the designated for private use.
registry require a specification, potentially a Standards Track RFC,
be supplied as well.
The columns of this registry are: The columns of this registry are:
Name The OAuth Parameter name, refers to the name in the OAuth Name The OAuth Parameter name, refers to the name in the OAuth
parameter registry, e.g., "client_id". parameter registry, e.g., "client_id".
CBOR Key CBOR map key for this parameter. Different ranges of CBOR Key CBOR map key for this parameter. Integer values less than
values use different registration policies [RFC8126]. Integer -65536 are marked as "Private Use", all other values use the
values from -256 to 255 are designated as Standards Action. registration policy "Expert Review" [RFC8126].
Integer values from -65536 to -257 and from 256 to 65535 are
designated as Specification Required. Integer values greater than
65535 are designated as Expert Review. Integer values less than
-65536 are marked as Private Use.
Value Type The allowable CBOR data types for values of this Value Type The allowable CBOR data types for values of this
parameter. parameter.
Reference This contains a pointer to the public specification of the Reference This contains a pointer to the public specification of the
parameter abbreviation, if one exists. parameter abbreviation, if one exists.
This registry will be initially populated by the values in Figure 12. This registry will be initially populated by the values in Figure 12.
The Reference column for all of these entries will be this document. The Reference column for all of these entries will be this document.
Note that the mappings of parameters corresponding to claim names Note that the mappings of parameters corresponding to claim names
intentionally coincide with the CWT claim name mappings from intentionally coincide with the CWT claim name mappings from
skipping to change at page 50, line 15 skipping to change at page 50, line 9
o Name: "profile" o Name: "profile"
o Description: The communication and communication security profile o Description: The communication and communication security profile
used between client and RS, as defined in ACE profiles. used between client and RS, as defined in ACE profiles.
o Change Controller: IESG o Change Controller: IESG
o Reference: Section 5.7.2 of [this document] o Reference: Section 5.7.2 of [this document]
8.11. OAuth Token Introspection Response CBOR Mappings Registry 8.11. OAuth Token Introspection Response CBOR Mappings Registry
This specification establishes the IANA "OAuth Token Introspection This specification establishes the IANA "OAuth Token Introspection
Response CBOR Mappings" registry. The registry has been created to Response CBOR Mappings" registry. The registry has been created to
use the "Expert Review Required" registration procedure [RFC8126]. use the "Expert Review" registration procedure [RFC8126], except for
It should be noted that, in addition to the expert review, some the value range designated for private use.
portions of the registry require a specification, potentially a
Standards Track RFC, be supplied as well.
The columns of this registry are: The columns of this registry are:
Name The OAuth Parameter name, refers to the name in the OAuth Name The OAuth Parameter name, refers to the name in the OAuth
parameter registry, e.g., "client_id". parameter registry, e.g., "client_id".
CBOR Key CBOR map key for this parameter. Different ranges of CBOR Key CBOR map key for this parameter. Integer values less than
values use different registration policies [RFC8126]. Integer -65536 are marked as "Private Use", all other values use the
values from -256 to 255 are designated as Standards Action. registration policy "Expert Review" [RFC8126].
Integer values from -65536 to -257 and from 256 to 65535 are
designated as Specification Required. Integer values greater than
65535 are designated as Expert Review. Integer values less than
-65536 are marked as Private Use.
Value Type The allowable CBOR data types for values of this Value Type The allowable CBOR data types for values of this
parameter. parameter.
Reference This contains a pointer to the public specification of the Reference This contains a pointer to the public specification of the
grant type abbreviation, if one exists. grant type abbreviation, if one exists.
This registry will be initially populated by the values in Figure 16. This registry will be initially populated by the values in Figure 16.
The Reference column for all of these entries will be this document. The Reference column for all of these entries will be this document.
Note that the mappings of parameters corresponding to claim names Note that the mappings of parameters corresponding to claim names
intentionally coincide with the CWT claim name mappings from intentionally coincide with the CWT claim name mappings from
skipping to change at page 54, line 4 skipping to change at page 53, line 39
needs to have sufficient information to identify what the point is needs to have sufficient information to identify what the point is
being used for. being used for.
o Experts should take into account the expected usage of fields when o Experts should take into account the expected usage of fields when
approving point assignment. The fact that there is a range for approving point assignment. The fact that there is a range for
standards track documents does not mean that a standards track standards track documents does not mean that a standards track
document cannot have points assigned outside of that range. The document cannot have points assigned outside of that range. The
length of the encoded value should be weighed against how many length of the encoded value should be weighed against how many
code points of that length are left, the size of device it will be code points of that length are left, the size of device it will be
used on, and the number of code points left that encode to that used on, and the number of code points left that encode to that
size. size.
o Since a high degree of overlap is expected between these o Since a high degree of overlap is expected between these
registries and the contents of the OAuth parameters registries and the contents of the OAuth parameters
[IANA.OAuthParameters] registries, experts should require new [IANA.OAuthParameters] registries, experts should require new
registrations to maintain a reasonable level of alignment with registrations to maintain alignment with parameters from OAuth
parameters from OAuth that have comparable functionality. that have comparable functionality. Deviation from this alignment
should only be allowed if there are functional differences, that
are motivated by the use case and that cannot be easily or
efficiently addressed by comparable OAuth parameters.
9. Acknowledgments 9. Acknowledgments
This document is a product of the ACE working group of the IETF. This document is a product of the ACE working group of the IETF.
Thanks to Eve Maler for her contributions to the use of OAuth 2.0 and Thanks to Eve Maler for her contributions to the use of OAuth 2.0 and
UMA in IoT scenarios, Robert Taylor for his discussion input, and UMA in IoT scenarios, Robert Taylor for his discussion input, and
Malisa Vucinic for his input on the predecessors of this proposal. Malisa Vucinic for his input on the predecessors of this proposal.
Thanks to the authors of draft-ietf-oauth-pop-key-distribution, from Thanks to the authors of draft-ietf-oauth-pop-key-distribution, from
skipping to change at page 54, line 42 skipping to change at page 54, line 32
the CelticPlus project CyberWI, with funding from Vinnova. the CelticPlus project CyberWI, with funding from Vinnova.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-ace-cwt-proof-of-possession] [I-D.ietf-ace-cwt-proof-of-possession]
Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
Tschofenig, "Proof-of-Possession Key Semantics for CBOR Tschofenig, "Proof-of-Possession Key Semantics for CBOR
Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of- Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of-
possession-05 (work in progress), November 2018. possession-06 (work in progress), February 2019.
[I-D.ietf-ace-oauth-params] [I-D.ietf-ace-oauth-params]
Seitz, L., "Additional OAuth Parameters for Authorization Seitz, L., "Additional OAuth Parameters for Authorization
in Constrained Environments (ACE)", draft-ietf-ace-oauth- in Constrained Environments (ACE)", draft-ietf-ace-oauth-
params-04 (work in progress), February 2019. params-04 (work in progress), February 2019.
[I-D.ietf-oauth-token-exchange] [I-D.ietf-oauth-token-exchange]
Jones, M., Nadalin, A., Campbell, B., Bradley, J., and C. Jones, M., Nadalin, A., Campbell, B., Bradley, J., and C.
Mortimore, "OAuth 2.0 Token Exchange", draft-ietf-oauth- Mortimore, "OAuth 2.0 Token Exchange", draft-ietf-oauth-
token-exchange-16 (work in progress), October 2018. token-exchange-16 (work in progress), October 2018.
skipping to change at page 59, line 5 skipping to change at page 58, line 49
[RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
Authorization Server Metadata", RFC 8414, Authorization Server Metadata", RFC 8414,
DOI 10.17487/RFC8414, June 2018, DOI 10.17487/RFC8414, June 2018,
<https://www.rfc-editor.org/info/rfc8414>. <https://www.rfc-editor.org/info/rfc8414>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC8516] Keraenen, A., ""Too Many Requests" Response Code for the [RFC8516] Keranen, A., ""Too Many Requests" Response Code for the
Constrained Application Protocol", RFC 8516, Constrained Application Protocol", RFC 8516,
DOI 10.17487/RFC8516, January 2019, DOI 10.17487/RFC8516, January 2019,
<https://www.rfc-editor.org/info/rfc8516>. <https://www.rfc-editor.org/info/rfc8516>.
Appendix A. Design Justification Appendix A. Design Justification
This section provides further insight into the design decisions of This section provides further insight into the design decisions of
the solution documented in this document. Section 3 lists several the solution documented in this document. Section 3 lists several
building blocks and briefly summarizes their importance. The building blocks and briefly summarizes their importance. The
justification for offering some of those building blocks, as opposed justification for offering some of those building blocks, as opposed
skipping to change at page 74, line 32 skipping to change at page 74, line 32
F: |<--------+ Header: 2.04 Changed F: |<--------+ Header: 2.04 Changed
| 2.04 | Payload: <new state for the lock> | 2.04 | Payload: <new state for the lock>
| | | |
Figure 26: Resource request and response protected by OSCORE Figure 26: Resource request and response protected by OSCORE
Appendix F. Document Updates Appendix F. Document Updates
RFC EDITOR: PLEASE REMOVE THIS SECTION. RFC EDITOR: PLEASE REMOVE THIS SECTION.
F.1. Verion -20 to 21 F.1. Version -21 to 22
o Provided section numbers in references to OAuth RFC.
o Updated IANA mapping registries to only use "Private Use" and
"Expert Review".
o Made error messages optional for RS at token submission since it
may not be able to send them depending on the profile.
o Corrected errors in examples.
F.2. Version -20 to 21
o Added text about expiration of RS keys. o Added text about expiration of RS keys.
F.2. Verion -19 to 20 F.3. Version -19 to 20
o Replaced "req_aud" with "audience" from the OAuth token exchange o Replaced "req_aud" with "audience" from the OAuth token exchange
draft. draft.
o Updated examples to remove unnecessary elements. o Updated examples to remove unnecessary elements.
F.3. Version -18 to -19 F.4. Version -18 to -19
o Added definition of "Authorization Information". o Added definition of "Authorization Information".
o Explicitly state that ACE allows encoding refresh tokens in binary o Explicitly state that ACE allows encoding refresh tokens in binary
format in addition to strings. format in addition to strings.
o Renamed "AS Information" to "AS Request Creation Hints" and added o Renamed "AS Information" to "AS Request Creation Hints" and added
the possibility to specify req_aud and scope as hints. the possibility to specify req_aud and scope as hints.
o Added the "kid" parameter to AS Request Creation Hints. o Added the "kid" parameter to AS Request Creation Hints.
o Added security considerations about the integrity protection of o Added security considerations about the integrity protection of
tokens with multi-RS audiences. tokens with multi-RS audiences.
o Renamed IANA registries mapping OAuth parameters to reflect the o Renamed IANA registries mapping OAuth parameters to reflect the
mapped registry. mapped registry.
o Added JWT claim names to CWT claim registrations. o Added JWT claim names to CWT claim registrations.
o Added expert review instructions. o Added expert review instructions.
o Updated references to TLS from 1.2 to 1.3. o Updated references to TLS from 1.2 to 1.3.
F.4. Version -17 to -18 F.5. Version -17 to -18
o Added OSCORE options in examples involving OSCORE. o Added OSCORE options in examples involving OSCORE.
o Removed requirement for the client to send application/cwt, since o Removed requirement for the client to send application/cwt, since
the client has no way to know. the client has no way to know.
o Clarified verification of tokens by the RS. o Clarified verification of tokens by the RS.
o Added exi claim CWT registration. o Added exi claim CWT registration.
F.5. Version -16 to -17 F.6. Version -16 to -17
o Added references to (D)TLS 1.3. o Added references to (D)TLS 1.3.
o Added requirement that responses are bound to requests. o Added requirement that responses are bound to requests.
o Specify that grant_type is OPTIONAL in C2AS requests (as opposed o Specify that grant_type is OPTIONAL in C2AS requests (as opposed
to REQUIRED in OAuth). to REQUIRED in OAuth).
o Replaced examples with hypothetical COSE profile with OSCORE. o Replaced examples with hypothetical COSE profile with OSCORE.
o Added requirement for content type application/ace+cbor in error o Added requirement for content type application/ace+cbor in error
responses for token and introspection requests and responses. responses for token and introspection requests and responses.
o Reworked abbreviation space for claims, request and response o Reworked abbreviation space for claims, request and response
parameters. parameters.
skipping to change at page 75, line 41 skipping to change at page 76, line 5
info resource. info resource.
o Added section that specifies how the RS verifies an access token. o Added section that specifies how the RS verifies an access token.
o Added section on the protection of the authz-info endpoint. o Added section on the protection of the authz-info endpoint.
o Removed the expiration mechanism based on sequence numbers. o Removed the expiration mechanism based on sequence numbers.
o Added reference to RFC7662 security considerations. o Added reference to RFC7662 security considerations.
o Added considerations on minimal security requirements for o Added considerations on minimal security requirements for
communication. communication.
o Added security considerations on unprotected information sent to o Added security considerations on unprotected information sent to
authz-info and in the error responses. authz-info and in the error responses.
F.6. Version -15 to -16 F.7. Version -15 to -16
o Added text the RS using RFC6750 error codes. o Added text the RS using RFC6750 error codes.
o Defined an error code for incompatible token request parameters. o Defined an error code for incompatible token request parameters.
o Removed references to the actors draft. o Removed references to the actors draft.
o Fixed errors in examples. o Fixed errors in examples.
F.7. Version -14 to -15 F.8. Version -14 to -15
o Added text about refresh tokens. o Added text about refresh tokens.
o Added text about protection of credentials. o Added text about protection of credentials.
o Rephrased introspection so that other entities than RS can do it. o Rephrased introspection so that other entities than RS can do it.
o Editorial improvements. o Editorial improvements.
F.8. Version -13 to -14 F.9. Version -13 to -14
o Split out the 'aud', 'cnf' and 'rs_cnf' parameters to o Split out the 'aud', 'cnf' and 'rs_cnf' parameters to
[I-D.ietf-ace-oauth-params] [I-D.ietf-ace-oauth-params]
o Introduced the "application/ace+cbor" Content-Type. o Introduced the "application/ace+cbor" Content-Type.
o Added claim registrations from 'profile' and 'rs_cnf'. o Added claim registrations from 'profile' and 'rs_cnf'.
o Added note on schema part of AS Information Section 5.1.2 o Added note on schema part of AS Information Section 5.1.2
o Realigned the parameter abbreviations to push rarely used ones to o Realigned the parameter abbreviations to push rarely used ones to
the 2-byte encoding size of CBOR integers. the 2-byte encoding size of CBOR integers.
F.9. Version -12 to -13 F.10. Version -12 to -13
o Changed "Resource Information" to "Access Information" to avoid o Changed "Resource Information" to "Access Information" to avoid
confusion. confusion.
o Clarified section about AS discovery. o Clarified section about AS discovery.
o Editorial changes o Editorial changes
F.10. Version -11 to -12 F.11. Version -11 to -12
o Moved the Request error handling to a section of its own. o Moved the Request error handling to a section of its own.
o Require the use of the abbreviation for profile identifiers. o Require the use of the abbreviation for profile identifiers.
o Added rs_cnf parameter in the introspection response, to inform o Added rs_cnf parameter in the introspection response, to inform
RS' with several RPKs on which key to use. RS' with several RPKs on which key to use.
o Allowed use of rs_cnf as claim in the access token in order to o Allowed use of rs_cnf as claim in the access token in order to
inform an RS with several RPKs on which key to use. inform an RS with several RPKs on which key to use.
o Clarified that profiles must specify if/how error responses are o Clarified that profiles must specify if/how error responses are
protected. protected.
o Fixed label number range to align with COSE/CWT. o Fixed label number range to align with COSE/CWT.
o Clarified the requirements language in order to allow profiles to o Clarified the requirements language in order to allow profiles to
specify other payload formats than CBOR if they do not use CoAP. specify other payload formats than CBOR if they do not use CoAP.
F.11. Version -10 to -11 F.12. Version -10 to -11
o Fixed some CBOR data type errors. o Fixed some CBOR data type errors.
o Updated boilerplate text o Updated boilerplate text
F.12. Version -09 to -10 F.13. Version -09 to -10
o Removed CBOR major type numbers. o Removed CBOR major type numbers.
o Removed the client token design. o Removed the client token design.
o Rephrased to clarify that other protocols than CoAP can be used. o Rephrased to clarify that other protocols than CoAP can be used.
o Clarifications regarding the use of HTTP o Clarifications regarding the use of HTTP
F.13. Version -08 to -09 F.14. Version -08 to -09
o Allowed scope to be byte strings. o Allowed scope to be byte strings.
o Defined default names for endpoints. o Defined default names for endpoints.
o Refactored the IANA section for briefness and consistency. o Refactored the IANA section for briefness and consistency.
o Refactored tables that define IANA registry contents for o Refactored tables that define IANA registry contents for
consistency. consistency.
o Created IANA registry for CBOR mappings of error codes, grant o Created IANA registry for CBOR mappings of error codes, grant
types and Authorization Server Information. types and Authorization Server Information.
o Added references to other document sections defining IANA entries o Added references to other document sections defining IANA entries
in the IANA section. in the IANA section.
F.14. Version -07 to -08 F.15. Version -07 to -08
o Moved AS discovery from the DTLS profile to the framework, see o Moved AS discovery from the DTLS profile to the framework, see
Section 5.1. Section 5.1.
o Made the use of CBOR mandatory. If you use JSON you can use o Made the use of CBOR mandatory. If you use JSON you can use
vanilla OAuth. vanilla OAuth.
o Made it mandatory for profiles to specify C-AS security and RS-AS o Made it mandatory for profiles to specify C-AS security and RS-AS
security (the latter only if introspection is supported). security (the latter only if introspection is supported).
o Made the use of CBOR abbreviations mandatory. o Made the use of CBOR abbreviations mandatory.
o Added text to clarify the use of token references as an o Added text to clarify the use of token references as an
alternative to CWTs. alternative to CWTs.
skipping to change at page 77, line 41 skipping to change at page 78, line 4
discovery information, combining profiles and leakage through discovery information, combining profiles and leakage through
error responses. error responses.
o Added privacy considerations about leakage through unprotected AS o Added privacy considerations about leakage through unprotected AS
discovery. discovery.
o Added text that clarifies that introspection is optional. o Added text that clarifies that introspection is optional.
o Made profile parameter optional since it can be implicit. o Made profile parameter optional since it can be implicit.
o Clarified that CoAP is not mandatory and other protocols can be o Clarified that CoAP is not mandatory and other protocols can be
used. used.
o Clarified the design justification for specific features of the o Clarified the design justification for specific features of the
framework in appendix A. framework in appendix A.
o Clarified appendix E.2. o Clarified appendix E.2.
o Removed specification of the "cnf" claim for CBOR/COSE, and o Removed specification of the "cnf" claim for CBOR/COSE, and
replaced with references to [I-D.ietf-ace-cwt-proof-of-possession] replaced with references to [I-D.ietf-ace-cwt-proof-of-possession]
F.15. Version -06 to -07 F.16. Version -06 to -07
o Various clarifications added. o Various clarifications added.
o Fixed erroneous author email. o Fixed erroneous author email.
F.16. Version -05 to -06 F.17. Version -05 to -06
o Moved sections that define the ACE framework into a subsection of o Moved sections that define the ACE framework into a subsection of
the framework Section 5. the framework Section 5.
o Split section on client credentials and grant into two separate o Split section on client credentials and grant into two separate
sections, Section 5.2, and Section 5.3. sections, Section 5.2, and Section 5.3.
o Added Section 5.4 on AS authentication. o Added Section 5.4 on AS authentication.
o Added Section 5.5 on the Authorization endpoint. o Added Section 5.5 on the Authorization endpoint.
F.17. Version -04 to -05 F.18. Version -04 to -05
o Added RFC 2119 language to the specification of the required o Added RFC 2119 language to the specification of the required
behavior of profile specifications. behavior of profile specifications.
o Added Section 5.3 on the relation to the OAuth2 grant types. o Added Section 5.3 on the relation to the OAuth2 grant types.
o Added CBOR abbreviations for error and the error codes defined in o Added CBOR abbreviations for error and the error codes defined in
OAuth2. OAuth2.
o Added clarification about token expiration and long-running o Added clarification about token expiration and long-running
requests in Section 5.8.3 requests in Section 5.8.3
o Added security considerations about tokens with symmetric pop keys o Added security considerations about tokens with symmetric pop keys
valid for more than one RS. valid for more than one RS.
o Added privacy considerations section. o Added privacy considerations section.
o Added IANA registry mapping the confirmation types from RFC 7800 o Added IANA registry mapping the confirmation types from RFC 7800
to equivalent COSE types. to equivalent COSE types.
o Added appendix D, describing assumptions about what the AS knows o Added appendix D, describing assumptions about what the AS knows
about the client and the RS. about the client and the RS.
F.18. Version -03 to -04 F.19. Version -03 to -04
o Added a description of the terms "framework" and "profiles" as o Added a description of the terms "framework" and "profiles" as
used in this document. used in this document.
o Clarified protection of access tokens in section 3.1. o Clarified protection of access tokens in section 3.1.
o Clarified uses of the "cnf" parameter in section 6.4.5. o Clarified uses of the "cnf" parameter in section 6.4.5.
o Clarified intended use of Client Token in section 7.4. o Clarified intended use of Client Token in section 7.4.
F.19. Version -02 to -03 F.20. Version -02 to -03
o Removed references to draft-ietf-oauth-pop-key-distribution since o Removed references to draft-ietf-oauth-pop-key-distribution since
the status of this draft is unclear. the status of this draft is unclear.
o Copied and adapted security considerations from draft-ietf-oauth- o Copied and adapted security considerations from draft-ietf-oauth-
pop-key-distribution. pop-key-distribution.
o Renamed "client information" to "RS information" since it is o Renamed "client information" to "RS information" since it is
information about the RS. information about the RS.
o Clarified the requirements on profiles of this framework. o Clarified the requirements on profiles of this framework.
o Clarified the token endpoint protocol and removed negotiation of o Clarified the token endpoint protocol and removed negotiation of
"profile" and "alg" (section 6). "profile" and "alg" (section 6).
o Renumbered the abbreviations for claims and parameters to get a o Renumbered the abbreviations for claims and parameters to get a
consistent numbering across different endpoints. consistent numbering across different endpoints.
o Clarified the introspection endpoint. o Clarified the introspection endpoint.
skipping to change at page 79, line 4 skipping to change at page 79, line 15
o Copied and adapted security considerations from draft-ietf-oauth- o Copied and adapted security considerations from draft-ietf-oauth-
pop-key-distribution. pop-key-distribution.
o Renamed "client information" to "RS information" since it is o Renamed "client information" to "RS information" since it is
information about the RS. information about the RS.
o Clarified the requirements on profiles of this framework. o Clarified the requirements on profiles of this framework.
o Clarified the token endpoint protocol and removed negotiation of o Clarified the token endpoint protocol and removed negotiation of
"profile" and "alg" (section 6). "profile" and "alg" (section 6).
o Renumbered the abbreviations for claims and parameters to get a o Renumbered the abbreviations for claims and parameters to get a
consistent numbering across different endpoints. consistent numbering across different endpoints.
o Clarified the introspection endpoint. o Clarified the introspection endpoint.
o Renamed token, introspection and authz-info to "endpoint" instead o Renamed token, introspection and authz-info to "endpoint" instead
of "resource" to mirror the OAuth 2.0 terminology. of "resource" to mirror the OAuth 2.0 terminology.
o Updated the examples in the appendices. o Updated the examples in the appendices.
F.20. Version -01 to -02 F.21. Version -01 to -02
o Restructured to remove communication security parts. These shall o Restructured to remove communication security parts. These shall
now be defined in profiles. now be defined in profiles.
o Restructured section 5 to create new sections on the OAuth o Restructured section 5 to create new sections on the OAuth
endpoints token, introspection and authz-info. endpoints token, introspection and authz-info.
o Pulled in material from draft-ietf-oauth-pop-key-distribution in o Pulled in material from draft-ietf-oauth-pop-key-distribution in
order to define proof-of-possession key distribution. order to define proof-of-possession key distribution.
o Introduced the "cnf" parameter as defined in RFC7800 to reference o Introduced the "cnf" parameter as defined in RFC7800 to reference
or transport keys used for proof of possession. or transport keys used for proof of possession.
o Introduced the "client-token" to transport client information from o Introduced the "client-token" to transport client information from
the AS to the client via the RS in conjunction with introspection. the AS to the client via the RS in conjunction with introspection.
o Expanded the IANA section to define parameters for token request, o Expanded the IANA section to define parameters for token request,
introspection and CWT claims. introspection and CWT claims.
o Moved deployment scenarios to the appendix as examples. o Moved deployment scenarios to the appendix as examples.
F.21. Version -00 to -01 F.22. Version -00 to -01
o Changed 5.1. from "Communication Security Protocol" to "Client o Changed 5.1. from "Communication Security Protocol" to "Client
Information". Information".
o Major rewrite of 5.1 to clarify the information exchanged between o Major rewrite of 5.1 to clarify the information exchanged between
C and AS in the PoP access token request profile for IoT. C and AS in the PoP access token request profile for IoT.
* Allow the client to indicate preferences for the communication * Allow the client to indicate preferences for the communication
security protocol. security protocol.
* Defined the term "Client Information" for the additional * Defined the term "Client Information" for the additional
information returned to the client in addition to the access information returned to the client in addition to the access
 End of changes. 81 change blocks. 
203 lines changed or deleted 206 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/