< draft-ietf-ace-oauth-authz-18.txt   draft-ietf-ace-oauth-authz-19.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: July 21, 2019 Ericsson Expires: August 4, 2019 Ericsson
E. Wahlstroem E. Wahlstroem
S. Erdtman S. Erdtman
Spotify AB Spotify AB
H. Tschofenig H. Tschofenig
Arm Ltd. Arm Ltd.
January 17, 2019 January 31, 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-18 draft-ietf-ace-oauth-authz-19
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 July 21, 2019. This Internet-Draft will expire on August 4, 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 27 skipping to change at page 2, line 27
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . . . . . 10 4. Protocol Interactions . . . . . . . . . . . . . . . . . . . . 11
5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Discovering Authorization Servers . . . . . . . . . . . . 15 5.1. Discovering Authorization Servers . . . . . . . . . . . . 16
5.1.1. Unauthorized Resource Request Message . . . . . . . . 15 5.1.1. Unauthorized Resource Request Message . . . . . . . . 16
5.1.2. AS Information . . . . . . . . . . . . . . . . . . . 16 5.1.2. AS Request Creation Hints . . . . . . . . . . . . . . 16
5.2. Authorization Grants . . . . . . . . . . . . . . . . . . 17 5.2. Authorization Grants . . . . . . . . . . . . . . . . . . 18
5.3. Client Credentials . . . . . . . . . . . . . . . . . . . 18 5.3. Client Credentials . . . . . . . . . . . . . . . . . . . 19
5.4. AS Authentication . . . . . . . . . . . . . . . . . . . . 18 5.4. AS Authentication . . . . . . . . . . . . . . . . . . . . 19
5.5. The Authorization Endpoint . . . . . . . . . . . . . . . 19 5.5. The Authorization Endpoint . . . . . . . . . . . . . . . 19
5.6. The Token Endpoint . . . . . . . . . . . . . . . . . . . 19 5.6. The Token Endpoint . . . . . . . . . . . . . . . . . . . 20
5.6.1. Client-to-AS Request . . . . . . . . . . . . . . . . 20 5.6.1. Client-to-AS Request . . . . . . . . . . . . . . . . 20
5.6.2. AS-to-Client Response . . . . . . . . . . . . . . . . 22 5.6.2. AS-to-Client Response . . . . . . . . . . . . . . . . 23
5.6.3. Error Response . . . . . . . . . . . . . . . . . . . 24 5.6.3. Error Response . . . . . . . . . . . . . . . . . . . 25
5.6.4. Request and Response Parameters . . . . . . . . . . . 25 5.6.4. Request and Response Parameters . . . . . . . . . . . 26
5.6.4.1. Grant Type . . . . . . . . . . . . . . . . . . . 25 5.6.4.1. Grant Type . . . . . . . . . . . . . . . . . . . 26
5.6.4.2. Token Type . . . . . . . . . . . . . . . . . . . 26 5.6.4.2. Token Type . . . . . . . . . . . . . . . . . . . 27
5.6.4.3. Profile . . . . . . . . . . . . . . . . . . . . . 26 5.6.4.3. Profile . . . . . . . . . . . . . . . . . . . . . 27
5.6.5. Mapping Parameters to CBOR . . . . . . . . . . . . . 27 5.6.5. Mapping Parameters to CBOR . . . . . . . . . . . . . 28
5.7. The Introspection Endpoint . . . . . . . . . . . . . . . 27 5.7. The Introspection Endpoint . . . . . . . . . . . . . . . 28
5.7.1. Introspection Request . . . . . . . . . . . . . . . . 28 5.7.1. Introspection Request . . . . . . . . . . . . . . . . 29
5.7.2. Introspection Response . . . . . . . . . . . . . . . 29 5.7.2. Introspection Response . . . . . . . . . . . . . . . 30
5.7.3. Error Response . . . . . . . . . . . . . . . . . . . 30 5.7.3. Error Response . . . . . . . . . . . . . . . . . . . 31
5.7.4. Mapping Introspection parameters to CBOR . . . . . . 31 5.7.4. Mapping Introspection parameters to CBOR . . . . . . 32
5.8. The Access Token . . . . . . . . . . . . . . . . . . . . 31 5.8. The Access Token . . . . . . . . . . . . . . . . . . . . 32
5.8.1. The Authorization Information Endpoint . . . . . . . 32 5.8.1. The Authorization Information Endpoint . . . . . . . 33
5.8.1.1. Verifying an Access Token . . . . . . . . . . . . 33 5.8.1.1. Verifying an Access Token . . . . . . . . . . . . 34
5.8.1.2. Protecting the Authzorization Information 5.8.1.2. Protecting the Authorization Information
Endpoint . . . . . . . . . . . . . . . . . . . . 35 Endpoint . . . . . . . . . . . . . . . . . . . . 36
5.8.2. Client Requests to the RS . . . . . . . . . . . . . . 35 5.8.2. Client Requests to the RS . . . . . . . . . . . . . . 36
5.8.3. Token Expiration . . . . . . . . . . . . . . . . . . 36 5.8.3. Token Expiration . . . . . . . . . . . . . . . . . . 37
6. Security Considerations . . . . . . . . . . . . . . . . . . . 36 6. Security Considerations . . . . . . . . . . . . . . . . . . . 37
6.1. Unprotected AS Information . . . . . . . . . . . . . . . 38 6.1. Unprotected AS Request Creation Hints . . . . . . . . . . 39
6.2. Minimal security requirements for communication . 38 6.2. Minimal security requirements for communication . 39
6.3. Use of Nonces for Replay Protection . . . . . . . . . . . 39 6.3. Use of Nonces for Replay Protection . . . . . . . . . . . 40
6.4. Combining profiles . . . . . . . . . . . . . . . . . . . 39 6.4. Combining profiles . . . . . . . . . . . . . . . . . . . 40
6.5. Unprotected Information . . . . . . . . . . . . . . . . . 39 6.5. Unprotected Information . . . . . . . . . . . . . . . . . 40
6.6. Denial of service against or with Introspection . . 40 6.6. Denial of service against or with Introspection . . 41
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 40 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 41
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
8.1. Authorization Server Information . . . . . . . . . . . . 41 8.1. ACE Authorization Server Request Creation Hints . . . . . 42
8.2. OAuth Extensions Error Registration . . . . . . . . . . . 42 8.2. OAuth Extensions Error Registration . . . . . . . . . . . 43
8.3. OAuth Error Code CBOR Mappings Registry . . . . . . . . . 42 8.3. OAuth Error Code CBOR Mappings Registry . . . . . . . . . 43
8.4. OAuth Grant Type CBOR Mappings . . . . . . . . . . . . . 43 8.4. OAuth Grant Type CBOR Mappings . . . . . . . . . . . . . 44
8.5. OAuth Access Token Types . . . . . . . . . . . . . . . . 43 8.5. OAuth Access Token Types . . . . . . . . . . . . . . . . 44
8.6. OAuth Token Type CBOR Mappings . . . . . . . . . . . . . 43 8.6. OAuth Access Token Type CBOR Mappings . . . . . . . . . . 44
8.6.1. Initial Registry Contents . . . . . . . . . . . . . . 44 8.6.1. Initial Registry Contents . . . . . . . . . . . . . . 45
8.7. ACE Profile Registry . . . . . . . . . . . . . . . . . . 44 8.7. ACE Profile Registry . . . . . . . . . . . . . . . . . . 45
8.8. OAuth Parameter Registration . . . . . . . . . . . . . . 45 8.8. OAuth Parameter Registration . . . . . . . . . . . . . . 46
8.9. Token Endpoint CBOR Mappings Registry . . . . . . . . . . 45 8.9. OAuth Parameters CBOR Mappings Registry . . . . . . . . . 46
8.10. OAuth Introspection Response Parameter Registration . . . 46 8.10. OAuth Introspection Response Parameter Registration . . . 47
8.11. Introspection Endpoint CBOR Mappings Registry . . . . . . 46 8.11. OAuth Token Introspection Response CBOR Mappings Registry 47
8.12. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 47 8.12. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 48
8.13. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 47 8.13. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 48
8.14. Media Type Registrations . . . . . . . . . . . . . . . . 48 8.14. Media Type Registrations . . . . . . . . . . . . . . . . 49
8.15. CoAP Content-Format Registry . . . . . . . . . . . . . . 49 8.15. CoAP Content-Format Registry . . . . . . . . . . . . . . 50
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 49 8.16. Expert Review Instructions . . . . . . . . . . . . . . . 50
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 51
10.1. Normative References . . . . . . . . . . . . . . . . . . 50 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 51
10.2. Informative References . . . . . . . . . . . . . . . . . 52 10.1. Normative References . . . . . . . . . . . . . . . . . . 51
Appendix A. Design Justification . . . . . . . . . . . . . . . . 54 10.2. Informative References . . . . . . . . . . . . . . . . . 53
Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 58 Appendix A. Design Justification . . . . . . . . . . . . . . . . 56
Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 60 Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 59
Appendix D. Assumptions on AS knowledge about C and RS . . . . . 60 Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 62
Appendix E. Deployment Examples . . . . . . . . . . . . . . . . 61 Appendix D. Assumptions on AS knowledge about C and RS . . . . . 62
E.1. Local Token Validation . . . . . . . . . . . . . . . . . 61 Appendix E. Deployment Examples . . . . . . . . . . . . . . . . 63
E.2. Introspection Aided Token Validation . . . . . . . . . . 65 E.1. Local Token Validation . . . . . . . . . . . . . . . . . 63
Appendix F. Document Updates . . . . . . . . . . . . . . . . . . 69 E.2. Introspection Aided Token Validation . . . . . . . . . . 67
F.1. Version -17 to -18 . . . . . . . . . . . . . . . . . . . 69 Appendix F. Document Updates . . . . . . . . . . . . . . . . . . 71
F.2. Version -16 to -17 . . . . . . . . . . . . . . . . . . . 69 F.1. Version -18 to -19 . . . . . . . . . . . . . . . . . . . 71
F.3. Version -15 to -16 . . . . . . . . . . . . . . . . . . . 70 F.2. Version -17 to -18 . . . . . . . . . . . . . . . . . . . 71
F.4. Version -14 to -15 . . . . . . . . . . . . . . . . . . . 70 F.3. Version -16 to -17 . . . . . . . . . . . . . . . . . . . 72
F.5. Version -13 to -14 . . . . . . . . . . . . . . . . . . . 70 F.4. Version -15 to -16 . . . . . . . . . . . . . . . . . . . 72
F.6. Version -12 to -13 . . . . . . . . . . . . . . . . . . . 70 F.5. Version -14 to -15 . . . . . . . . . . . . . . . . . . . 72
F.7. Version -11 to -12 . . . . . . . . . . . . . . . . . . . 70 F.6. Version -13 to -14 . . . . . . . . . . . . . . . . . . . 72
F.8. Version -10 to -11 . . . . . . . . . . . . . . . . . . . 71 F.7. Version -12 to -13 . . . . . . . . . . . . . . . . . . . 73
F.9. Version -09 to -10 . . . . . . . . . . . . . . . . . . . 71 F.8. Version -11 to -12 . . . . . . . . . . . . . . . . . . . 73
F.10. Version -08 to -09 . . . . . . . . . . . . . . . . . . . 71 F.9. Version -10 to -11 . . . . . . . . . . . . . . . . . . . 73
F.11. Version -07 to -08 . . . . . . . . . . . . . . . . . . . 71 F.10. Version -09 to -10 . . . . . . . . . . . . . . . . . . . 73
F.12. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 72 F.11. Version -08 to -09 . . . . . . . . . . . . . . . . . . . 73
F.13. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 72 F.12. Version -07 to -08 . . . . . . . . . . . . . . . . . . . 74
F.14. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 72 F.13. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 74
F.15. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 72 F.14. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 74
F.16. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 73 F.15. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 74
F.17. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 73 F.16. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 75
F.18. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 73 F.17. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 75
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 74 F.18. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 75
F.19. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 76
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 76
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
complex task. complex task.
skipping to change at page 6, line 5 skipping to change at page 6, line 5
The specifications in this document is called the "framework" or "ACE The specifications in this document is called the "framework" or "ACE
framework". When referring to "profiles of this framework" it refers framework". When referring to "profiles of this framework" it refers
to additional specifications that define the use of this to additional specifications that define the use of this
specification with concrete transport, and communication security specification with concrete transport, and communication security
protocols (e.g., CoAP over DTLS). protocols (e.g., CoAP over DTLS).
We use the term "Access Information" for parameters other than the We use the term "Access Information" for parameters other than the
access token provided to the client by the AS to enable it to access access token provided to the client by the AS to enable it to access
the RS (e.g. public key of the RS, profile supported by RS). the RS (e.g. public key of the RS, profile supported by RS).
We use the term "Authorization Information" to denote all
information, including the claims of relevant access tokens, that an
RS uses to determine whether an access request should be granted.
3. Overview 3. Overview
This specification defines the ACE framework for authorization in the This specification defines the ACE framework for authorization in the
Internet of Things environment. It consists of a set of building Internet of Things environment. It consists of a set of building
blocks. blocks.
The basic block is the OAuth 2.0 [RFC6749] framework, which enjoys The basic block is the OAuth 2.0 [RFC6749] framework, which enjoys
widespread deployment. Many IoT devices can support OAuth 2.0 widespread deployment. Many IoT devices can support OAuth 2.0
without any additional extensions, but for certain constrained without any additional extensions, but for certain constrained
settings additional profiling is needed. settings additional profiling is needed.
skipping to change at page 6, line 33 skipping to change at page 6, line 37
A third building block is CBOR [RFC7049], for encodings where JSON A third building block is CBOR [RFC7049], for encodings where JSON
[RFC8259] is not sufficiently compact. CBOR is a binary encoding [RFC8259] is not sufficiently compact. CBOR is a binary encoding
designed for small code and message size, which may be used for designed for small code and message size, which may be used for
encoding of self contained tokens, and also for encoding payload encoding of self contained tokens, and also for encoding payload
transferred in protocol messages. transferred in protocol messages.
A fourth building block is the compact CBOR-based secure message A fourth building block is the compact CBOR-based secure message
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 [RFC5246]). 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 RFC 7228 [RFC7228] and a
description of how the building blocks mentioned above relate to the description of how the building blocks mentioned above relate to the
various constraints can be found in Appendix A. various constraints can be found in Appendix A.
skipping to change at page 8, line 10 skipping to change at page 8, line 15
the resource owner). Issuing a refresh token is optional at the the resource owner). Issuing a refresh token is optional at the
discretion of the authorization server. If the authorization discretion of the authorization server. If the authorization
server issues a refresh token, it is included when issuing an server issues a refresh token, it is included when issuing an
access token (i.e., step (B) in Figure 1). access token (i.e., step (B) in Figure 1).
A refresh token in OAuth 2.0 is a string representing the A refresh token in OAuth 2.0 is a string representing the
authorization granted to the client by the resource owner. The authorization granted to the client by the resource owner. The
string is usually opaque to the client. The token denotes an string is usually opaque to the client. The token denotes an
identifier used to retrieve the authorization information. Unlike identifier used to retrieve the authorization information. Unlike
access tokens, refresh tokens are intended for use only with access tokens, refresh tokens are intended for use only with
authorization servers and are never sent to resource servers. authorization servers and are never sent to resource servers. In
this framework, refresh tokens are encoded in binary instead of
strings, if used.
Proof of Possession Tokens: Proof of Possession Tokens:
An access token may be bound to a cryptographic key, which is then An access token may be bound to a cryptographic key, which is then
used by an RS to authenticate requests from a client. Such tokens used by an RS to authenticate requests from a client. Such tokens
are called proof-of-possession access tokens (or PoP access are called proof-of-possession access tokens (or PoP access
tokens). tokens).
The proof-of-possession (PoP) security concept assumes that the AS The proof-of-possession (PoP) security concept assumes that the AS
acts as a trusted third party that binds keys to access tokens. acts as a trusted third party that binds keys to access tokens.
These so called PoP keys are then used by the client to These so called PoP keys are then used by the client to
demonstrate the possession of the secret to the RS when accessing demonstrate the possession of the secret to the RS when accessing
skipping to change at page 10, line 23 skipping to change at page 10, line 32
While HTTP uses headers and query strings to convey additional While HTTP uses headers and query strings to convey additional
information about a request, CoAP encodes such information into information about a request, CoAP encodes such information into
header parameters called 'options'. header parameters called 'options'.
CoAP supports application-layer fragmentation of the CoAP payloads CoAP supports application-layer fragmentation of the CoAP payloads
through blockwise transfers [RFC7959]. However, blockwise transfer through blockwise transfers [RFC7959]. However, blockwise transfer
does not increase the size limits of CoAP options, therefore data does not increase the size limits of CoAP options, therefore data
encoded in options has to be kept small. encoded in options has to be kept small.
Transport layer security for CoAP can be provided by DTLS or TLS Transport layer security for CoAP can be provided by DTLS or TLS
[RFC6347][RFC5246][RFC8446] [I-D.ietf-tls-dtls13]. CoAP defines a [RFC6347][RFC8446] [I-D.ietf-tls-dtls13]. CoAP defines a number of
number of proxy operations that require transport layer security to proxy operations that require transport layer security to be
be terminated at the proxy. One approach for protecting CoAP terminated at the proxy. One approach for protecting CoAP
communication end-to-end through proxies, and also to support communication end-to-end through proxies, and also to support
security for CoAP over a different transport in a uniform way, is to security for CoAP over a different transport in a uniform way, is to
provide security at the application layer using an object-based provide security at the application layer using an object-based
security mechanism such as COSE [RFC8152]. security mechanism such as COSE [RFC8152].
One application of COSE is OSCORE [I-D.ietf-core-object-security], One application of COSE is OSCORE [I-D.ietf-core-object-security],
which provides end-to-end confidentiality, integrity and replay which provides end-to-end confidentiality, integrity and replay
protection, and a secure binding between CoAP request and response protection, and a secure binding between CoAP request and response
messages. In OSCORE, the CoAP messages are wrapped in COSE objects messages. In OSCORE, the CoAP messages are wrapped in COSE objects
and sent using CoAP. and sent using CoAP.
skipping to change at page 16, line 4 skipping to change at page 16, line 20
to C. to C.
Instead of the initial Unauthorized Resource Request message, other Instead of the initial Unauthorized Resource Request message, other
discovery methods may be used, or the client may be pre-provisioned discovery methods may be used, or the client may be pre-provisioned
with the address of the AS. with the address of the AS.
5.1.1. Unauthorized Resource Request Message 5.1.1. Unauthorized Resource Request Message
The optional Unauthorized Resource Request message is a request for a The optional Unauthorized Resource Request message is a request for a
resource hosted by RS for which no proper authorization is granted. resource hosted by RS for which no proper authorization is granted.
RS MUST treat any request for a protected resource as Unauthorized RS MUST treat any request for a protected resource as Unauthorized
Resource Request message when any of the following holds: Resource Request message when any of the following holds:
o The request has been received on an unprotected channel. o The request has been received on an unprotected channel.
o RS has no valid access token for the sender of the request o RS has no valid access token for the sender of the request
regarding the requested action on that resource. regarding the requested action on that resource.
o RS has a valid access token for the sender of the request, but o RS has a valid access token for the sender of the request, but
this does not allow the requested action on the requested this does not allow the requested action on the requested
resource. resource.
Note: These conditions ensure that RS can handle requests Note: These conditions ensure that RS can handle requests
autonomously once access was granted and a secure channel has been autonomously once access was granted and a secure channel has been
established between C and RS. The authz-info endpoint MUST NOT be established between C and RS. The authz-info endpoint MUST NOT be
protected as specified above, in order to allow clients to upload protected as specified above, in order to allow clients to upload
access tokens to RS (cf. Section 5.8.1). access tokens to RS (cf. Section 5.8.1).
Unauthorized Resource Request messages MUST be denied with a client Unauthorized Resource Request messages MUST be denied with a client
error response. In this response, the Resource Server SHOULD provide error response. In this response, the Resource Server SHOULD provide
proper AS Information to enable the Client to request an access token proper AS Request Creation Hints to enable the Client to request an
from RS's AS as described in Section 5.1.2. access token from RS's AS as described in Section 5.1.2.
The handling of all client requests (including unauthorized ones) by The handling of all client requests (including unauthorized ones) by
the RS is described in Section 5.8.2. the RS is described in Section 5.8.2.
5.1.2. AS Information 5.1.2. AS Request Creation Hints
The AS Information is sent by RS as a response to an Unauthorized The AS Request Creation Hints message is sent by RS as a response to
Resource Request message (see Section 5.1.1) to point the sender of an Unauthorized Resource Request message (see Section 5.1.1) to help
the Unauthorized Resource Request message to RS's AS. The AS the sender of the Unauthorized Resource Request message in acquiring
information is a set of attributes containing an absolute URI (see a valid access token. The AS Request Creation Hints message is CBOR
Section 4.3 of [RFC3986]) that specifies the AS in charge of RS. map, with a MANDATORY element "AS" specifying an absolute URI (see
Section 4.3 of [RFC3986]) that identifies the AS in charge of RS.
The message MAY also contain a nonce generated by RS to ensure The message can also contain the following OPTIONAL parameters:
freshness in case that the RS and AS do not have synchronized clocks.
Figure 2 summarizes the parameters that may be part of the AS o A "req_aud" element containing a suggested audience that the
Information. client should request towards the AS.
o A "kid" element containing the key identifier of a key used in an
existing security association between the client and the RS. The
RS expects the client to request an access token bound to this
key, in order to avoid having to re-establish the security
association.
o A "nonce" element containing a nonce generated by RS to ensure
freshness in case that the RS and AS do not have synchronized
clocks.
o A "scope" element containing the suggested scope that the client
should request towards the AS.
/-------+----------+-------------\ Figure 2 summarizes the parameters that may be part of the AS Request
| Name | CBOR Key | Value Type | Creation Hints.
|-------+----------+-------------|
| AS | 0 | text string |
| nonce | 5 | byte string |
\-------+----------+-------------/
Figure 2: AS Information parameters /-----------+----------+---------------------\
| Name | CBOR Key | Value Type |
|-----------+----------+---------------------|
| AS | 0 | text string |
| req_aud | 3 | text string |
| kid | 4 | byte string |
| nonce | 5 | byte string |
| scope | 9 | text or byte string |
\-----------+----------+---------------------/
Figure 2: AS Request Creation Hints
Note that the schema part of the AS parameter may need to be adapted Note that the schema part of the AS parameter may need to be adapted
to the security protocol that is used between the client and the AS. to the security protocol that is used between the client and the AS.
Thus the example AS value "coap://as.example.com/token" might need to Thus the example AS value "coap://as.example.com/token" might need to
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 Information message payload using Figure 3 shows an example for an AS Request Creation Hints message
CBOR [RFC7049] diagnostic notation, using the parameter names instead payload using CBOR [RFC7049] diagnostic notation, using the parameter
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",
nonce: h'e0a156bb3f'} req_aud: "coaps://rs.example.com",
nonce: h'e0a156bb3f',
scope: "rTempC"
}
Figure 3: AS Information 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 Information payload (i.e., RS) permissions. The originator of the AS Request Creation Hints payload
uses a local clock that is loosely synchronized with a time scale (i.e., RS) uses a local clock that is loosely synchronized with a
common between RS and AS (e.g., wall clock time). Therefore, it has time scale common between RS and AS (e.g., wall clock time).
included a parameter "nonce" for replay attack prevention. Therefore, it has included a parameter "nonce" for replay attack
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) a2 # map(2)
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
Figure 4: AS Information 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
types can be split up into two groups, those granted on behalf of the types can be split up into two groups, those granted on behalf of the
resource owner (password, authorization code, implicit) and those for resource owner (password, authorization code, implicit) and those for
skipping to change at page 21, line 20 skipping to change at page 22, line 11
the audience is implicitly known by both client and AS. Furthermore the audience is implicitly known by both client and AS. Furthermore
note that this example uses the "req_cnf" parameter from note that this example uses the "req_cnf" parameter from
[I-D.ietf-ace-oauth-params]. [I-D.ietf-ace-oauth-params].
Header: POST (Code=0.02) Header: POST (Code=0.02)
Uri-Host: "as.example.com" Uri-Host: "as.example.com"
Uri-Path: "token" Uri-Path: "token"
OSCORE: 0x19, 0x05, 0x05, 0x44, 0x61, 0x6c, 0x65, 0x6b OSCORE: 0x19, 0x05, 0x05, 0x44, 0x61, 0x6c, 0x65, 0x6b
Content-Format: "application/oscore" Content-Format: "application/oscore"
Payload: Payload:
0x44025d1 ... (full payload ommitted for brevity) ... 68b3825e 0x44025d1 ... (full payload omitted for brevity) ... 68b3825e
) )
Decrypted payload: Decrypted payload:
{ {
"grant_type" : "client_credentials", "grant_type" : "client_credentials",
"client_id" : "myclient", "client_id" : "myclient",
"req_cnf" : { "req_cnf" : {
"COSE_Key" : { "COSE_Key" : {
"kty" : "EC", "kty" : "EC",
"kid" : h'11', "kid" : h'11',
skipping to change at page 35, line 5 skipping to change at page 36, line 5
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.
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 Authzorization 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.
Specifically it SHOULD NOT be possible to perform GET, DELETE or PUT Specifically it SHOULD NOT be possible to perform GET, DELETE or PUT
on the authz-info endpoint and on it's children (if any). on the authz-info endpoint and on it's children (if any).
The POST method SHOULD NOT be allowed on children of the authz-info The POST method SHOULD NOT be allowed on children of the authz-info
endpoint. endpoint.
The RS SHOULD implement rate limiting measures to mitigate attacks The RS SHOULD implement rate limiting measures to mitigate attacks
aiming to overload the processing capacity of the RS by repeatedly aiming to overload the processing capacity of the RS by repeatedly
submitting tokens. For CoAP-based communication the RS could use the submitting tokens. For CoAP-based communication the RS could use the
mechanisms from [I-D.ietf-core-too-many-reqs] to indicate that it is mechanisms from [RFC8516] to indicate that it is overloaded.
overloaded.
5.8.2. Client Requests to the RS 5.8.2. Client Requests to the RS
If an RS receives a request from a client, and the target resource If an RS receives a request from a client, and the target resource
requires authorization, the RS MUST first verify that it has an requires authorization, the RS MUST first verify that it has an
access token that authorizes this request, and that the client has access token that authorizes this request, and that the client has
performed the proof-of-possession for that token. performed the proof-of-possession for that token.
The response code MUST be 4.01 (Unauthorized) in case the client has The response code MUST be 4.01 (Unauthorized) in case the client has
not performed the proof-of-possession, or if RS has no valid access not performed the proof-of-possession, or if RS has no valid access
skipping to change at page 37, line 19 skipping to change at page 38, line 19
digest (MAC) or an Authenticated Encryption with Associated Data digest (MAC) or an Authenticated Encryption with Associated Data
(AEAD) algorithm. Consequently, the token integrity protection MUST (AEAD) algorithm. Consequently, the token integrity protection MUST
be applied to prevent the token from being modified, particularly be applied to prevent the token from being modified, particularly
since it contains a reference to the symmetric key or the asymmetric since it contains a reference to the symmetric key or the asymmetric
key. If the access token contains the symmetric key, this symmetric key. If the access token contains the symmetric key, this symmetric
key MUST be encrypted by the authorization server so that only the key MUST be encrypted by the authorization server so that only the
resource server can decrypt it. Note that using an AEAD algorithm is resource server can decrypt it. Note that using an AEAD algorithm is
preferable over using a MAC unless the message needs to be publicly preferable over using a MAC unless the message needs to be publicly
readable. readable.
If the token is intended for multiple recipients (i.e. an audience
that is a group), integrity protection of the token with a symmetric
key is not sufficient, since any of the recipients could modify the
token undetected by the other recipients. Therefore a token with a
multi-recipient audience MUST be protected with an asymmetric
signature.
It is important for the authorization server to include the identity It is important for the authorization server to include the identity
of the intended recipient (the audience), typically a single resource of the intended recipient (the audience), typically a single resource
server (or a list of resource servers), in the token. Using a single server (or a list of resource servers), in the token. Using a single
shared secret with multiple resource servers to simplify key shared secret with multiple resource servers to simplify key
management is NOT RECOMMENDED since the benefit from using the proof- management is NOT RECOMMENDED since the benefit from using the proof-
of-possession concept is significantly reduced. of-possession concept is significantly reduced.
The authorization server MUST offer confidentiality protection for The authorization server MUST offer confidentiality protection for
any interactions with the client. This step is extremely important any interactions with the client. This step is extremely important
since the client may obtain the proof-of-possession key from the since the client may obtain the proof-of-possession key from the
skipping to change at page 38, line 8 skipping to change at page 39, line 15
If clients are capable of doing so, they should frequently request If clients are capable of doing so, they should frequently request
fresh access tokens, as this allows the AS to keep the lifetime of fresh access tokens, as this allows the AS to keep the lifetime of
the tokens short. This allows the AS to use shorter proof-of- the tokens short. This allows the AS to use shorter proof-of-
possession key sizes, which translate to a performance benefit for possession key sizes, which translate to a performance benefit for
the client and for the resource server. Shorter keys also lead to the client and for the resource server. Shorter keys also lead to
shorter messages (particularly with asymmetric keying material). shorter messages (particularly with asymmetric keying material).
When authorization servers bind symmetric keys to access tokens, they When authorization servers bind symmetric keys to access tokens, they
SHOULD scope these access tokens to a specific permission. SHOULD scope these access tokens to a specific permission.
6.1. Unprotected AS Information 6.1. Unprotected AS Request Creation Hints
Initially, no secure channel exists to protect the communication Initially, no secure channel exists to protect the communication
between C and RS. Thus, C cannot determine if the AS information between C and RS. Thus, C cannot determine if the AS Request
contained in an unprotected response from RS to an unauthorized Creation Hints contained in an unprotected response from RS to an
request (see Section 5.1.2) is authentic. It is therefore advisable unauthorized request (see Section 5.1.2) are authentic. It is
to provide C with a (possibly hard-coded) list of trustworthy therefore advisable to provide C with a (possibly hard-coded) list of
authorization servers. AS information responses referring to a URI trustworthy authorization servers. AS Request Creation Hints
not listed there would be ignored. referring to a URI not listed there would be ignored.
6.2. Minimal security requirements for communication 6.2. Minimal security requirements for communication
This section summarizes the minimal requirements for the This section summarizes the minimal requirements for the
communication security of the different protocol interactions. communication security of the different protocol interactions.
C-AS All communication between the client and the Authorization C-AS All communication between the client and the Authorization
Server MUST be encrypted, integrity and replay protected. Server MUST be encrypted, integrity and replay protected.
Furthermore responses from the AS to the client MUST be bound to Furthermore responses from the AS to the client MUST be bound to
the client's request to avoid attacks where the attacker swaps the the client's request to avoid attacks where the attacker swaps the
skipping to change at page 39, line 19 skipping to change at page 40, line 27
or received a symmetric proof-of-possession key bound to the or received a symmetric proof-of-possession key bound to the
access token from the AS. The RS must have learned either the access token from the AS. The RS must have learned either the
client's public key or a shared symmetric key from the claims in client's public key or a shared symmetric key from the claims in
the token or an introspection request. Since ACE does not provide the token or an introspection request. Since ACE does not provide
profile negotiation between C and RS, the client MUST have learned profile negotiation between C and RS, the client MUST have learned
what profile the RS supports (e.g. from the AS or pre-configured) what profile the RS supports (e.g. from the AS or pre-configured)
and initiate the communication accordingly. and initiate the communication accordingly.
6.3. Use of Nonces for Replay Protection 6.3. Use of Nonces for Replay Protection
The RS may add a nonce to the AS Information message sent as a The RS may add a nonce to the AS Request Creation Hints message sent
response to an unauthorized request to ensure freshness of an Access as a response to an unauthorized request to ensure freshness of an
Token subsequently presented to RS. While a time-stamp of some Access Token subsequently presented to RS. While a time-stamp of
granularity would be sufficient to protect against replay attacks, some granularity would be sufficient to protect against replay
using randomized nonce is preferred to prevent disclosure of attacks, using randomized nonce is preferred to prevent disclosure of
information about RS's internal clock characteristics. information about RS's internal clock characteristics.
6.4. Combining profiles 6.4. Combining profiles
There may be use cases were different profiles of this framework are There may be use cases were different profiles of this framework are
combined. For example, an MQTT-TLS profile is used between the combined. For example, an MQTT-TLS profile is used between the
client and the RS in combination with a CoAP-DTLS profile for client and the RS in combination with a CoAP-DTLS profile for
interactions between the client and the AS. Ideally, profiles should interactions between the client and the AS. Ideally, profiles should
be designed in a way that the security of system should not depend on be designed in a way that the security of system should not depend on
the specific security mechanisms used in individual protocol the specific security mechanisms used in individual protocol
skipping to change at page 40, line 28 skipping to change at page 41, line 34
6.6. Denial of service against or with Introspection 6.6. Denial of service against or with Introspection
The optional introspection mechanism provided by OAuth and supported The optional introspection mechanism provided by OAuth and supported
in the ACE framework allows for two types of attacks that need to be in the ACE framework allows for two types of attacks that need to be
considered by implementers. considered by implementers.
First an attacker could perform a denial of service attack against First an attacker could perform a denial of service attack against
the introspection endpoint at the AS in order to prevent validation the introspection endpoint at the AS in order to prevent validation
of access tokens. To mitigate this attack, an RS that is configured of access tokens. To mitigate this attack, an RS that is configured
to use introspection MUST NOT allow access based on a token for which to use introspection MUST NOT allow access based on a token for which
it couln't reach the introspection endpoint. it couldn't reach the introspection endpoint.
Second an attacker could use the fact that an RS performs Second an attacker could use the fact that an RS performs
introspection to perform a denial of service attack against that RS introspection to perform a denial of service attack against that RS
by repeatedly sending tokens to its authz-info endpoint that require by repeatedly sending tokens to its authz-info endpoint that require
an introspection call. RS can mitigate such attacks by implementing an introspection call. RS can mitigate such attacks by implementing
a rate limit on how many introspection requests they perform in a a rate limit on how many introspection requests they perform in a
given time intervall and rejecting incoming requests to authz-info given time interval and rejecting incoming requests to authz-info for
for a certain amount of time, when that rate limit has been reached. a certain amount of time, when that rate limit has been reached.
7. Privacy Considerations 7. Privacy Considerations
Implementers and users should be aware of the privacy implications of Implementers and users should be aware of the privacy implications of
the different possible deployments of this framework. the different possible deployments of this framework.
The AS is in a very central position and can potentially learn The AS is in a very central position and can potentially learn
sensitive information about the clients requesting access tokens. If sensitive information about the clients requesting access tokens. If
the client credentials grant is used, the AS can track what kind of the client credentials grant is used, the AS can track what kind of
access the client intends to perform. With other grants this can be access the client intends to perform. With other grants this can be
skipping to change at page 41, line 31 skipping to change at page 42, line 35
Section 5.1.2) may disclose information about RS and/or its existing Section 5.1.2) may disclose information about RS and/or its existing
relationship with C. It is advisable to include as little relationship with C. It is advisable to include as little
information as possible in an unencrypted response. Means of information as possible in an unencrypted response. Means of
encrypting communication between C and RS already exist, more encrypting communication between C and RS already exist, more
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. Authorization Server Information 8.1. ACE Authorization Server Request Creation Hints
This specification establishes the IANA "ACE Authorization Server This specification establishes the IANA "ACE Authorization Server
Information" registry. The registry has been created to use the Request Creation Hints" registry. The registry has been created to
"Expert Review Required" registration procedure [RFC8126]. It should use the "Expert Review Required" registration procedure [RFC8126].
be noted that, in addition to the expert review, some portions of the It should be noted that, in addition to the expert review, some
registry require a specification, potentially a Standards Track RFC, portions of the registry require a specification, potentially a
be supplied as well. Standards Track RFC, 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
designated as Expert Review. Integer values less than -65536 are designated as Expert Review. Integer values less than -65536 are
skipping to change at page 43, line 42 skipping to change at page 44, line 48
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 Name: "PoP"
o Change Controller: IETF o Change Controller: IETF
o Reference: [this document] o Reference: [this document]
8.6. OAuth Token Type CBOR Mappings 8.6. OAuth Access Token Type CBOR Mappings
This specification established the IANA "Token Type CBOR Mappings" This specification established the IANA "OAuth Access Token Type CBOR
registry. The registry has been created to use the "Expert Review Mappings" registry. The registry has been created to use the "Expert
Required" registration procedure [RFC8126]. It should be noted that, Review Required" registration procedure [RFC8126]. It should be
in addition to the expert review, some portions of the registry noted that, in addition to the expert review, some portions of the
require a specification, potentially a Standards Track RFC, be registry require a specification, potentially a Standards Track RFC,
supplied as well. 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. Different ranges
of values use different registration policies [RFC8126]. Integer of values use different registration policies [RFC8126]. Integer
values from -256 to 255 are designated as Standards Action. values from -256 to 255 are designated as Standards Action.
Integer values from -65536 to -257 and from 256 to 65535 are Integer values from -65536 to -257 and from 256 to 65535 are
designated as Specification Required. Integer values greater than designated as Specification Required. Integer values greater than
skipping to change at page 44, line 46 skipping to change at page 46, line 4
addition to the expert review, some portions of the registry require addition to the expert review, some portions of the registry require
a specification, potentially a Standards Track RFC, be supplied as a specification, 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
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
Parameters" registry [IANA.OAuthParameters]: Parameters" registry [IANA.OAuthParameters]:
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. Token Endpoint CBOR Mappings Registry 8.9. OAuth Parameters CBOR Mappings Registry
This specification establishes the IANA "Token Endpoint 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 Required" registration procedure [RFC8126]. It should be
noted that, in addition to the expert review, some portions of the noted that, in addition to the expert review, some portions of the
registry require a specification, potentially a Standards Track RFC, registry require a specification, potentially a Standards Track RFC,
be supplied as well. 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".
skipping to change at page 46, line 17 skipping to change at page 47, line 24
This specification registers the following parameter in the OAuth This specification registers the following parameter in the OAuth
Token Introspection Response registry Token Introspection Response registry
[IANA.TokenIntrospectionResponse]. [IANA.TokenIntrospectionResponse].
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. Introspection Endpoint CBOR Mappings Registry 8.11. OAuth Token Introspection Response CBOR Mappings Registry
This specification establishes the IANA "Introspection Endpoint CBOR This specification establishes the IANA "OAuth Token Introspection
Mappings" registry. The registry has been created to use the "Expert Response CBOR Mappings" registry. The registry has been created to
Review Required" registration procedure [RFC8126]. It should be use the "Expert Review Required" registration procedure [RFC8126].
noted that, in addition to the expert review, some portions of the It should be noted that, in addition to the expert review, some
registry require a specification, potentially a Standards Track RFC, portions of the registry require a specification, potentially a
be supplied as well. 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. 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. values from -256 to 255 are designated as Standards Action.
Integer values from -65536 to -257 and from 256 to 65535 are Integer values from -65536 to -257 and from 256 to 65535 are
designated as Specification Required. Integer values greater than designated as Specification Required. Integer values greater than
skipping to change at page 47, line 39 skipping to change at page 48, line 43
o Reference: Section 5.8.3 of [this document] o Reference: Section 5.8.3 of [this document]
8.13. CBOR Web Token Claims 8.13. CBOR Web Token Claims
This specification registers the following new claims in the "CBOR This specification registers the following new claims in the "CBOR
Web Token (CWT) Claims" registry [IANA.CborWebTokenClaims]. Web Token (CWT) Claims" registry [IANA.CborWebTokenClaims].
o Claim Name: "scope" o Claim Name: "scope"
o Claim Description: The scope of an access token as defined in o Claim Description: The scope of an access token as defined in
[RFC6749]. [RFC6749].
o JWT Claim Name: N/A o JWT Claim Name: scope
o Claim Key: TBD (suggested: 9) o Claim Key: TBD (suggested: 9)
o Claim Value Type(s): byte string or text string o Claim Value Type(s): byte string or text string
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 5.8 of [this document] o Specification Document(s): Section 5.8 of [this document]
o Claim Name: "profile" o Claim Name: "profile"
o Claim Description: The profile a token is supposed to be used o Claim Description: The profile a token is supposed to be used
with. with.
o JWT Claim Name: N/A o JWT Claim Name: profile
o Claim Key: TBD (suggested: 39) o Claim Key: TBD (suggested: 39)
o Claim Value Type(s): integer o Claim Value Type(s): integer
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 5.8 of [this document] o Specification Document(s): Section 5.8 of [this document]
o Claim Name: "exi" o Claim Name: "exi"
o Claim Description: The expiration time of a token measured from o Claim Description: The expiration time of a token measured from
when it was received at the RS in seconds. when it was received at the RS in seconds.
o JWT Claim Name: N/A o JWT Claim Name: exi
o Claim Key: TBD (suggested: 41) o Claim Key: TBD (suggested: 41)
o Claim Value Type(s): integer o Claim Value Type(s): integer
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 5.8 of [this document] o Specification Document(s): Section 5.8 of [this document]
8.14. Media Type Registrations 8.14. Media Type Registrations
This specification registers the 'application/ace+cbor' media type This specification registers the 'application/ace+cbor' media type
for messages of the protocols defined in this document carrying for messages of the protocols defined in this document carrying
parameters encoded in CBOR. This registration follows the procedures parameters encoded in CBOR. This registration follows the procedures
skipping to change at page 49, line 25 skipping to change at page 50, line 30
Content-Formats" registry: Content-Formats" registry:
Media Type: application/ace+cbor Media Type: application/ace+cbor
Encoding Encoding
ID: 19 ID: 19
Reference: [this document] Reference: [this document]
8.16. Expert Review Instructions
All of the IANA registries established in this document are defined
as expert review. This section gives some general guidelines for
what the experts should be looking for, but they are being designated
as experts for a reason, so they should be given substantial
latitude.
Expert reviewers should take into consideration the following points:
o Point squatting should be discouraged. Reviewers are encouraged
to get sufficient information for registration requests to ensure
that the usage is not going to duplicate one that is already
registered, and that the point is likely to be used in
deployments. The zones tagged as private use are intended for
testing purposes and closed environments; code points in other
ranges should not be assigned for testing.
o Specifications are required for the standards track range of point
assignment. Specifications should exist for specification
required ranges, but early assignment before a specification is
available is considered to be permissible. Specifications are
needed for the first-come, first-serve range if they are expected
to be used outside of closed environments in an interoperable way.
When specifications are not provided, the description provided
needs to have sufficient information to identify what the point is
being used for.
o Experts should take into account the expected usage of fields when
approving point assignment. The fact that there is a range for
standards track documents does not mean that a standards track
document cannot have points assigned outside of that range. The
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
used on, and the number of code points left that encode to that
size.
o Since a high degree of overlap is expected between these
registries and the contents of the OAuth parameters
[IANA.OAuthParameters] registries, experts should require new
registrations to maintain a reasonable level of alignment with
parameters from OAuth that have comparable functionality.
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
where large parts of the security considerations where copied. where large parts of the security considerations where copied.
skipping to change at page 50, line 18 skipping to change at page 52, line 14
[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-05 (work in progress), November 2018.
[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-01 (work in progress), November 2018. params-03 (work in progress), January 2019.
[IANA.CborWebTokenClaims] [IANA.CborWebTokenClaims]
IANA, "CBOR Web Token (CWT) Claims", IANA, "CBOR Web Token (CWT) Claims",
<https://www.iana.org/assignments/cwt/cwt.xhtml#claims- <https://www.iana.org/assignments/cwt/cwt.xhtml#claims-
registry>. registry>.
[IANA.JsonWebTokenClaims] [IANA.JsonWebTokenClaims]
IANA, "JSON Web Token Claims", IANA, "JSON Web Token Claims",
<https://www.iana.org/assignments/jwt/jwt.xhtml#claims>. <https://www.iana.org/assignments/jwt/jwt.xhtml#claims>.
skipping to change at page 52, line 18 skipping to change at page 54, line 11
Seitz, L. and S. Erdtman, "Raw-Public-Key and Pre-Shared- Seitz, L. and S. Erdtman, "Raw-Public-Key and Pre-Shared-
Key as OAuth client credentials", draft-erdtman-ace- Key as OAuth client credentials", draft-erdtman-ace-
rpcc-02 (work in progress), October 2017. rpcc-02 (work in progress), October 2017.
[I-D.ietf-core-object-security] [I-D.ietf-core-object-security]
Selander, G., Mattsson, J., Palombini, F., and L. Seitz, Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments "Object Security for Constrained RESTful Environments
(OSCORE)", draft-ietf-core-object-security-15 (work in (OSCORE)", draft-ietf-core-object-security-15 (work in
progress), August 2018. progress), August 2018.
[I-D.ietf-core-too-many-reqs]
Keranen, A., "Too Many Requests Response Code for the
Constrained Application Protocol", draft-ietf-core-too-
many-reqs-06 (work in progress), November 2018.
[I-D.ietf-oauth-device-flow] [I-D.ietf-oauth-device-flow]
Denniss, W., Bradley, J., Jones, M., and H. Tschofenig, Denniss, W., Bradley, J., Jones, M., and H. Tschofenig,
"OAuth 2.0 Device Flow for Browserless and Input "OAuth 2.0 Device Flow for Browserless and Input
Constrained Devices", draft-ietf-oauth-device-flow-13 Constrained Devices", draft-ietf-oauth-device-flow-14
(work in progress), October 2018. (work in progress), January 2019.
[I-D.ietf-tls-dtls13] [I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version Datagram Transport Layer Security (DTLS) Protocol Version
1.3", draft-ietf-tls-dtls13-30 (work in progress), 1.3", draft-ietf-tls-dtls13-30 (work in progress),
November 2018. November 2018.
[Margi10impact] [Margi10impact]
Margi, C., de Oliveira, B., de Sousa, G., Simplicio Jr, Margi, C., de Oliveira, B., de Sousa, G., Simplicio Jr,
M., Barreto, P., Carvalho, T., Naeslund, M., and R. Gold, M., Barreto, P., Carvalho, T., Naeslund, M., and R. Gold,
"Impact of Operating Systems on Wireless Sensor Networks "Impact of Operating Systems on Wireless Sensor Networks
(Security) Applications and Testbeds", Proceedings of (Security) Applications and Testbeds", Proceedings of
the 19th International Conference on Computer the 19th International Conference on Computer
Communications and Networks (ICCCN), 2010 August. Communications and Networks (ICCCN), 2010 August.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/info/rfc4949>. <https://www.rfc-editor.org/info/rfc4949>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, <https://www.rfc-
editor.org/info/rfc5246>.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
<https://www.rfc-editor.org/info/rfc6690>. <https://www.rfc-editor.org/info/rfc6690>.
[RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 [RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0
Threat Model and Security Considerations", RFC 6819, Threat Model and Security Considerations", RFC 6819,
DOI 10.17487/RFC6819, January 2013, <https://www.rfc- DOI 10.17487/RFC6819, January 2013, <https://www.rfc-
editor.org/info/rfc6819>. editor.org/info/rfc6819>.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
skipping to change at page 54, line 28 skipping to change at page 56, line 9
[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, <https://www.rfc- DOI 10.17487/RFC8414, June 2018, <https://www.rfc-
editor.org/info/rfc8414>. 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] Keranen, A., ""Too Many Requests"
Response Code for the Constrained Application Protocol",
RFC 8516, DOI 10.17487/RFC8516, January 2019,
<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
to using OAuth 2.0 as is, is given below. to using OAuth 2.0 as is, is given below.
Common IoT constraints are: Common IoT constraints are:
skipping to change at page 69, line 32 skipping to change at page 71, 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. Version -17 to -18 F.1. Version -18 to -19
o Added definition of "Authorization Information".
o Explicitly state that ACE allows encoding refresh tokens in binary
format in addition to strings.
o Renamed "AS Information" to "AS Request Creation Hints" and added
the possibility to specify req_aud and scope as hints.
o Added the "kid" parameter to AS Request Creation Hints.
o Added security considerations about the integrity protection of
tokens with multi-RS audiences.
o Renamed IANA registries mapping OAuth parameters to reflect the
mapped registry.
o Added JWT claim names to CWT claim registrations.
o Added expert review instructions.
o Updated references to TLS from 1.2 to 1.3.
F.2. 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.2. Version -16 to -17 F.3. 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 70, line 4 skipping to change at page 72, line 21
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.
o Added text that the RS may indicate that it is busy at the authz- o Added text that the RS may indicate that it is busy at the authz-
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.3. Version -15 to -16 F.4. 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.4. Version -14 to -15 F.5. 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.5. Version -13 to -14 F.6. 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.6. Version -12 to -13 F.7. 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.7. Version -11 to -12 F.8. 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.8. Version -10 to -11 F.9. 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.9. Version -09 to -10 F.10. 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.10. Version -08 to -09 F.11. 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.11. Version -07 to -08 F.12. 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 72, line 4 skipping to change at page 74, line 23
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.
o Added text to clarify that introspection must not be delayed, in o Added text to clarify that introspection must not be delayed, in
case the RS has to return a client token. case the RS has to return a client token.
o Added security considerations about leakage through unprotected AS o Added security considerations about leakage through unprotected AS
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.12. Version -06 to -07 F.13. Version -06 to -07
o Various clarifications added. o Various clarifications added.
o Fixed erroneous author email. o Fixed erroneous author email.
F.13. Version -05 to -06 F.14. 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.14. Version -04 to -05 F.15. 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.15. Version -03 to -04 F.16. 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.16. Version -02 to -03 F.17. 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.
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.17. Version -01 to -02 F.18. 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.18. Version -00 to -01 F.19. 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. 79 change blocks. 
201 lines changed or deleted 290 lines changed or added

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