draft-ietf-ace-oauth-authz-37.txt   draft-ietf-ace-oauth-authz-38.txt 
ACE Working Group L. Seitz ACE Working Group L. Seitz
Internet-Draft Combitech Internet-Draft Combitech
Intended status: Standards Track G. Selander Intended status: Standards Track G. Selander
Expires: August 8, 2021 Ericsson Expires: September 9, 2021 Ericsson
E. Wahlstroem E. Wahlstroem
S. Erdtman S. Erdtman
Spotify AB Spotify AB
H. Tschofenig H. Tschofenig
Arm Ltd. Arm Ltd.
February 4, 2021 March 8, 2021
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-37 draft-ietf-ace-oauth-authz-38
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 the Constrained Application Protocol (CoAP), thus OAuth 2.0 and the Constrained Application Protocol (CoAP), thus
transforming a well-known and widely used authorization solution into transforming a well-known and widely used authorization solution into
a form suitable for IoT devices. Existing specifications are used a form suitable for IoT devices. Existing specifications are used
where possible, but extensions are added and profiles are defined to where possible, but extensions are added and profiles are defined to
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 8, 2021. This Internet-Draft will expire on September 9, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 37 skipping to change at page 2, line 37
4. Protocol Interactions . . . . . . . . . . . . . . . . . . . . 11 4. Protocol Interactions . . . . . . . . . . . . . . . . . . . . 11
5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Discovering Authorization Servers . . . . . . . . . . . . 16 5.1. Discovering Authorization Servers . . . . . . . . . . . . 16
5.2. Unauthorized Resource Request Message . . . . . . . . . . 17 5.2. Unauthorized Resource Request Message . . . . . . . . . . 17
5.3. AS Request Creation Hints . . . . . . . . . . . . . . . . 17 5.3. AS Request Creation Hints . . . . . . . . . . . . . . . . 17
5.3.1. The Client-Nonce Parameter . . . . . . . . . . . . . 19 5.3.1. The Client-Nonce Parameter . . . . . . . . . . . . . 19
5.4. Authorization Grants . . . . . . . . . . . . . . . . . . 20 5.4. Authorization Grants . . . . . . . . . . . . . . . . . . 20
5.5. Client Credentials . . . . . . . . . . . . . . . . . . . 21 5.5. Client Credentials . . . . . . . . . . . . . . . . . . . 21
5.6. AS Authentication . . . . . . . . . . . . . . . . . . . . 21 5.6. AS Authentication . . . . . . . . . . . . . . . . . . . . 21
5.7. The Authorization Endpoint . . . . . . . . . . . . . . . 21 5.7. The Authorization Endpoint . . . . . . . . . . . . . . . 21
5.8. The Token Endpoint . . . . . . . . . . . . . . . . . . . 21 5.8. The Token Endpoint . . . . . . . . . . . . . . . . . . . 22
5.8.1. Client-to-AS Request . . . . . . . . . . . . . . . . 22 5.8.1. Client-to-AS Request . . . . . . . . . . . . . . . . 22
5.8.2. AS-to-Client Response . . . . . . . . . . . . . . . . 25 5.8.2. AS-to-Client Response . . . . . . . . . . . . . . . . 25
5.8.3. Error Response . . . . . . . . . . . . . . . . . . . 27 5.8.3. Error Response . . . . . . . . . . . . . . . . . . . 27
5.8.4. Request and Response Parameters . . . . . . . . . . . 28 5.8.4. Request and Response Parameters . . . . . . . . . . . 28
5.8.4.1. Grant Type . . . . . . . . . . . . . . . . . . . 28 5.8.4.1. Grant Type . . . . . . . . . . . . . . . . . . . 29
5.8.4.2. Token Type . . . . . . . . . . . . . . . . . . . 29 5.8.4.2. Token Type . . . . . . . . . . . . . . . . . . . 29
5.8.4.3. Profile . . . . . . . . . . . . . . . . . . . . . 29 5.8.4.3. Profile . . . . . . . . . . . . . . . . . . . . . 29
5.8.4.4. Client-Nonce . . . . . . . . . . . . . . . . . . 30 5.8.4.4. Client-Nonce . . . . . . . . . . . . . . . . . . 30
5.8.5. Mapping Parameters to CBOR . . . . . . . . . . . . . 30 5.8.5. Mapping Parameters to CBOR . . . . . . . . . . . . . 30
5.9. The Introspection Endpoint . . . . . . . . . . . . . . . 31 5.9. The Introspection Endpoint . . . . . . . . . . . . . . . 31
5.9.1. Introspection Request . . . . . . . . . . . . . . . . 32 5.9.1. Introspection Request . . . . . . . . . . . . . . . . 32
5.9.2. Introspection Response . . . . . . . . . . . . . . . 33 5.9.2. Introspection Response . . . . . . . . . . . . . . . 33
5.9.3. Error Response . . . . . . . . . . . . . . . . . . . 34 5.9.3. Error Response . . . . . . . . . . . . . . . . . . . 34
5.9.4. Mapping Introspection parameters to CBOR . . . . . . 35 5.9.4. Mapping Introspection parameters to CBOR . . . . . . 35
5.10. The Access Token . . . . . . . . . . . . . . . . . . . . 35 5.10. The Access Token . . . . . . . . . . . . . . . . . . . . 35
skipping to change at page 3, line 46 skipping to change at page 3, line 46
8.12. OAuth Token Introspection Response CBOR Mappings Registry 55 8.12. OAuth Token Introspection Response CBOR Mappings Registry 55
8.13. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 55 8.13. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 55
8.14. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 56 8.14. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 56
8.15. Media Type Registrations . . . . . . . . . . . . . . . . 57 8.15. Media Type Registrations . . . . . . . . . . . . . . . . 57
8.16. CoAP Content-Format Registry . . . . . . . . . . . . . . 57 8.16. CoAP Content-Format Registry . . . . . . . . . . . . . . 57
8.17. Expert Review Instructions . . . . . . . . . . . . . . . 58 8.17. Expert Review Instructions . . . . . . . . . . . . . . . 58
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 59 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 59
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 59 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 59
10.1. Normative References . . . . . . . . . . . . . . . . . . 59 10.1. Normative References . . . . . . . . . . . . . . . . . . 59
10.2. Informative References . . . . . . . . . . . . . . . . . 62 10.2. Informative References . . . . . . . . . . . . . . . . . 62
Appendix A. Design Justification . . . . . . . . . . . . . . . . 64 Appendix A. Design Justification . . . . . . . . . . . . . . . . 65
Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 68 Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 68
Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 70 Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 71
Appendix D. Assumptions on AS knowledge about C and RS . . . . . 71 Appendix D. Assumptions on AS knowledge about C and RS . . . . . 71
Appendix E. Deployment Examples . . . . . . . . . . . . . . . . 72 Appendix E. Deployment Examples . . . . . . . . . . . . . . . . 72
E.1. Local Token Validation . . . . . . . . . . . . . . . . . 72 E.1. Local Token Validation . . . . . . . . . . . . . . . . . 72
E.2. Introspection Aided Token Validation . . . . . . . . . . 76 E.2. Introspection Aided Token Validation . . . . . . . . . . 76
Appendix F. Document Updates . . . . . . . . . . . . . . . . . . 80 Appendix F. Document Updates . . . . . . . . . . . . . . . . . . 80
F.1. Version -21 to 22 . . . . . . . . . . . . . . . . . . . . 81 F.1. Version -21 to 22 . . . . . . . . . . . . . . . . . . . . 81
F.2. Version -20 to 21 . . . . . . . . . . . . . . . . . . . . 81 F.2. Version -20 to 21 . . . . . . . . . . . . . . . . . . . . 81
F.3. Version -19 to 20 . . . . . . . . . . . . . . . . . . . . 81 F.3. Version -19 to 20 . . . . . . . . . . . . . . . . . . . . 81
F.4. Version -18 to -19 . . . . . . . . . . . . . . . . . . . 81 F.4. Version -18 to -19 . . . . . . . . . . . . . . . . . . . 81
F.5. Version -17 to -18 . . . . . . . . . . . . . . . . . . . 81 F.5. Version -17 to -18 . . . . . . . . . . . . . . . . . . . 81
skipping to change at page 6, line 47 skipping to change at page 6, line 47
protocols are not prohibited from being supported in the future, such protocols are not prohibited from being supported in the future, such
as HTTP/2 [RFC7540], Message Queuing Telemetry Transport (MQTT) as HTTP/2 [RFC7540], Message Queuing Telemetry Transport (MQTT)
[MQTT5.0], Bluetooth Low Energy (BLE) [BLE] and QUIC [MQTT5.0], Bluetooth Low Energy (BLE) [BLE] and QUIC
[I-D.ietf-quic-transport]. Note that this document specifies [I-D.ietf-quic-transport]. Note that this document specifies
protocol exchanges in terms of RESTful verbs such as GET and POST. protocol exchanges in terms of RESTful verbs such as GET and POST.
Future profiles using protocols that do not support these verbs MUST Future profiles using protocols that do not support these verbs MUST
specify how the corresponding protocol messages are transmitted specify how the corresponding protocol messages are transmitted
instead. instead.
A third building block is the Concise Binary Object Representation A third building block is the Concise Binary Object Representation
(CBOR) [RFC7049], for encodings where JSON [RFC8259] is not (CBOR) [RFC8949], for encodings where JSON [RFC8259] is not
sufficiently compact. CBOR is a binary encoding designed for small sufficiently compact. CBOR is a binary encoding designed for small
code and message size, which may be used for encoding of self code and message size, which may be used for encoding of self
contained tokens, and also for encoding payloads transferred in contained tokens, and also for encoding payloads transferred in
protocol messages. protocol messages.
A fourth building block is CBOR Object Signing and Encryption (COSE) A fourth building block is CBOR Object Signing and Encryption (COSE)
[RFC8152], which enables object-level layer security as an [RFC8152], which enables object-level layer security as an
alternative or complement to transport layer security (DTLS [RFC6347] alternative or complement to transport layer security (DTLS [RFC6347]
or TLS [RFC8446]). COSE is used to secure self-contained tokens such or TLS [RFC8446]). COSE is used to secure self-contained tokens such
as proof-of-possession (PoP) tokens, which are an extension to the as proof-of-possession (PoP) tokens, which are an extension to the
skipping to change at page 16, line 13 skipping to change at page 16, line 13
communications named above are encrypted, integrity protected and communications named above are encrypted, integrity protected and
protected against message replay. It is also REQUIRED that the protected against message replay. It is also REQUIRED that the
communicating endpoints perform mutual authentication. Furthermore communicating endpoints perform mutual authentication. Furthermore
it MUST be assured that responses are bound to the requests in the it MUST be assured that responses are bound to the requests in the
sense that the receiver of a response can be certain that the sense that the receiver of a response can be certain that the
response actually belongs to a certain request. Note that setting up response actually belongs to a certain request. Note that setting up
such a secure communication may require some unprotected messages to such a secure communication may require some unprotected messages to
be exchanged first (e.g. sending the token from the client to the be exchanged first (e.g. sending the token from the client to the
RS). RS).
Profiles MUST specify a communication security protocol that provides Profiles MUST specify a communication security protocol between
the features required above. client and RS that provides the features required above. Profiles
MUST specify a communication security protocol RECOMMENDED to be used
between client and AS that provides the features required above.
Profiles MUST specify for introspection a communication security
protocol RECOMMENDED to be used between RS and AS that provides the
features required above. These recommendations enable
interoperability between different implementations without the need
to define a new profile if the communication between C and AS, or
between RS and AS, is protected with a different security protocol
complying with the security requirements above.
In OAuth 2.0 the communication with the Token and the Introspection In OAuth 2.0 the communication with the Token and the Introspection
endpoints at the AS is assumed to be via HTTP and may use Uri-query endpoints at the AS is assumed to be via HTTP and may use Uri-query
parameters. When profiles of this framework use CoAP instead, it is parameters. When profiles of this framework use CoAP instead, it is
REQUIRED to use of the following alternative instead of Uri-query REQUIRED to use of the following alternative instead of Uri-query
parameters: The sender (client or RS) encodes the parameters of its parameters: The sender (client or RS) encodes the parameters of its
request as a CBOR map and submits that map as the payload of the POST request as a CBOR map and submits that map as the payload of the POST
request. request.
Profiles that use CBOR encoding of protocol message parameters at the Profiles that use CBOR encoding of protocol message parameters at the
outermost encoding layer MUST use the media format 'application/ outermost encoding layer MUST use the media format 'application/
ace+cbor'. If CoAP is used for communication, the Content-Format ace+cbor'. If CoAP is used for communication, the Content-Format
MUST be abbreviated with the ID: 19 (see Section 8.16). MUST be abbreviated with the ID: 19 (see Section 8.16).
The OAuth 2.0 AS uses a JSON structure in the payload of its The OAuth 2.0 AS uses a JSON structure in the payload of its
responses both to client and RS. If CoAP is used, it is REQUIRED to responses both to client and RS. If CoAP is used, it is REQUIRED to
use CBOR [RFC7049] instead of JSON. Depending on the profile, the use CBOR [RFC8949] instead of JSON. Depending on the profile, the
CBOR payload MAY be enclosed in a non-CBOR cryptographic wrapper. CBOR payload MAY be enclosed in a non-CBOR cryptographic wrapper.
5.1. Discovering Authorization Servers 5.1. Discovering Authorization Servers
C must discover the AS in charge of RS to determine where to request C must discover the AS in charge of RS to determine where to request
the access token. To do so, C must 1. find out the AS URI to which the access token. To do so, C must 1. find out the AS URI to which
the token request message must be sent and 2. MUST validate that the the token request message must be sent and 2. MUST validate that the
AS with this URI is authorized to provide access tokens for this RS. AS with this URI is authorized to provide access tokens for this RS.
In order to determine the AS URI, C MAY send an initial Unauthorized In order to determine the AS URI, C MAY send an initial Unauthorized
skipping to change at page 18, line 39 skipping to change at page 18, line 44
Figure 2: AS Request Creation Hints 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 Request Creation Hints message Figure 3 shows an example for an AS Request Creation Hints message
payload using CBOR [RFC7049] diagnostic notation, using the parameter payload using CBOR [RFC8949] diagnostic notation, using the parameter
names instead of the CBOR keys for better human readability. names instead of the CBOR keys for better human readability.
4.01 Unauthorized 4.01 Unauthorized
Content-Format: application/ace+cbor Content-Format: application/ace+cbor
Payload : Payload :
{ {
"AS" : "coaps://as.example.com/token", "AS" : "coaps://as.example.com/token",
"audience" : "coaps://rs.example.com" "audience" : "coaps://rs.example.com"
"scope" : "rTempC", "scope" : "rTempC",
"cnonce" : h'e0a156bb3f' "cnonce" : h'e0a156bb3f'
skipping to change at page 43, line 43 skipping to change at page 43, line 43
further standardization work that is out of scope for this document. further standardization work that is out of scope for this document.
6.2. Communication Security 6.2. Communication Security
Communication with the authorization server MUST use confidentiality Communication with the authorization server MUST use confidentiality
protection. This step is extremely important since the client or the protection. This step is extremely important since the client or the
RS may obtain the proof-of-possession key from the authorization RS may obtain the proof-of-possession key from the authorization
server for use with a specific access token. Not using server for use with a specific access token. Not using
confidentiality protection exposes this secret (and the access token) confidentiality protection exposes this secret (and the access token)
to an eavesdropper thereby completely negating proof-of-possession to an eavesdropper thereby completely negating proof-of-possession
security. Profiles MUST specify how communication security according security. The requirements for communication security of profiles
to the requirements in Section 5 is provided. are specified in Section 5.
Additional protection for the access token can be applied by Additional protection for the access token can be applied by
encrypting it, for example encryption of CWTs is specified in encrypting it, for example encryption of CWTs is specified in
Section 5.1 of [RFC8392]. Such additional protection can be Section 5.1 of [RFC8392]. Such additional protection can be
necessary if the token is later transferred over an insecure necessary if the token is later transferred over an insecure
connection (e.g. when it is sent to the authz-info endpoint). connection (e.g. when it is sent to the authz-info endpoint).
Developers MUST ensure that the ephemeral credentials (i.e., the Developers MUST ensure that the ephemeral credentials (i.e., the
private key or the session key) are not leaked to third parties. An private key or the session key) are not leaked to third parties. An
adversary in possession of the ephemeral credentials bound to the adversary in possession of the ephemeral credentials bound to the
skipping to change at page 60, line 39 skipping to change at page 60, line 39
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/info/rfc4949>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012, RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>. <https://www.rfc-editor.org/info/rfc6749>.
[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
Framework: Bearer Token Usage", RFC 6750, Framework: Bearer Token Usage", RFC 6750,
skipping to change at page 61, line 20 skipping to change at page 61, line 15
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013, RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/info/rfc6838>. <https://www.rfc-editor.org/info/rfc6838>.
[RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B.,
Keranen, A., and P. Hallam-Baker, "Naming Things with Keranen, A., and P. Hallam-Baker, "Naming Things with
Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013,
<https://www.rfc-editor.org/info/rfc6920>. <https://www.rfc-editor.org/info/rfc6920>.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <https://www.rfc-editor.org/info/rfc7049>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014, DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>. <https://www.rfc-editor.org/info/rfc7252>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>. <https://www.rfc-editor.org/info/rfc7519>.
[RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection",
skipping to change at page 62, line 15 skipping to change at page 62, line 10
[RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., [RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J.,
and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693,
DOI 10.17487/RFC8693, January 2020, DOI 10.17487/RFC8693, January 2020,
<https://www.rfc-editor.org/info/rfc8693>. <https://www.rfc-editor.org/info/rfc8693>.
[RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. [RFC8747] 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)", RFC 8747, DOI 10.17487/RFC8747, March Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March
2020, <https://www.rfc-editor.org/info/rfc8747>. 2020, <https://www.rfc-editor.org/info/rfc8747>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
10.2. Informative References 10.2. Informative References
[BLE] Bluetooth SIG, "Bluetooth Core Specification v5.1", [BLE] Bluetooth SIG, "Bluetooth Core Specification v5.1",
Section 4.4, January 2019, Section 4.4, January 2019,
<https://www.bluetooth.com/specifications/bluetooth-core- <https://www.bluetooth.com/specifications/bluetooth-core-
specification/>. specification/>.
[I-D.erdtman-ace-rpcc] [I-D.erdtman-ace-rpcc]
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-
skipping to change at page 63, line 5 skipping to change at page 63, line 5
"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), August 2010. Communications and Networks (ICCCN), August 2010.
[MQTT5.0] Banks, A., Briggs, E., Borgendale, K., and R. Gupta, "MQTT [MQTT5.0] Banks, A., Briggs, E., Borgendale, K., and R. Gupta, "MQTT
Version 5.0", OASIS Standard, March 2019, Version 5.0", OASIS Standard, March 2019,
<https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt- <https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-
v5.0.html>. v5.0.html>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/info/rfc4949>.
[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, DOI 10.17487/RFC6819, January 2013,
<https://www.rfc-editor.org/info/rfc6819>. <https://www.rfc-editor.org/info/rfc6819>.
[RFC7009] Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth [RFC7009] Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth
skipping to change at page 66, line 36 skipping to change at page 66, line 46
not limited to them. Other protocols such as HTTP, or even not limited to them. Other protocols such as HTTP, or even
protocols such as Bluetooth Smart communication that do not protocols such as Bluetooth Smart communication that do not
necessarily use IP, could also be used. The latter raises the necessarily use IP, could also be used. The latter raises the
need for application layer security over the various interfaces. need for application layer security over the various interfaces.
In the light of these constraints we have made the following design In the light of these constraints we have made the following design
decisions: decisions:
CBOR, COSE, CWT: CBOR, COSE, CWT:
This framework RECOMMENDS the use of CBOR [RFC7049] as data This framework RECOMMENDS the use of CBOR [RFC8949] as data
format. Where CBOR data needs to be protected, the use of COSE format. Where CBOR data needs to be protected, the use of COSE
[RFC8152] is RECOMMENDED. Furthermore, where self-contained [RFC8152] is RECOMMENDED. Furthermore, where self-contained
tokens are needed, this framework RECOMMENDS the use of CWT tokens are needed, this framework RECOMMENDS the use of CWT
[RFC8392]. These measures aim at reducing the size of messages [RFC8392]. These measures aim at reducing the size of messages
sent over the wire, the RAM size of data objects that need to be sent over the wire, the RAM size of data objects that need to be
kept in memory and the size of libraries that devices need to kept in memory and the size of libraries that devices need to
support. support.
CoAP: CoAP:
 End of changes. 18 change blocks. 
24 lines changed or deleted 34 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/