< draft-ietf-ace-oauth-authz-17.txt   draft-ietf-ace-oauth-authz-18.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: May 30, 2019 Ericsson Expires: July 21, 2019 Ericsson
E. Wahlstroem E. Wahlstroem
S. Erdtman S. Erdtman
Spotify AB Spotify AB
H. Tschofenig H. Tschofenig
Arm Ltd. Arm Ltd.
November 26, 2018 January 17, 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-17 draft-ietf-ace-oauth-authz-18
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 May 30, 2019. This Internet-Draft will expire on July 21, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. OAuth 2.0 . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. OAuth 2.0 . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. CoAP . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. CoAP . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4. Protocol Interactions . . . . . . . . . . . . . . . . . . . . 10 4. Protocol Interactions . . . . . . . . . . . . . . . . . . . . 10
5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Discovering Authorization Servers . . . . . . . . . . . . 15 5.1. Discovering Authorization Servers . . . . . . . . . . . . 15
5.1.1. Unauthorized Resource Request Message . . . . . . . . 15 5.1.1. Unauthorized Resource Request Message . . . . . . . . 15
5.1.2. AS Information . . . . . . . . . . . . . . . . . . . 16 5.1.2. AS Information . . . . . . . . . . . . . . . . . . . 16
5.2. Authorization Grants . . . . . . . . . . . . . . . . . . 17 5.2. Authorization Grants . . . . . . . . . . . . . . . . . . 17
5.3. Client Credentials . . . . . . . . . . . . . . . . . . . 18 5.3. Client Credentials . . . . . . . . . . . . . . . . . . . 18
5.4. AS Authentication . . . . . . . . . . . . . . . . . . . . 18 5.4. AS Authentication . . . . . . . . . . . . . . . . . . . . 18
5.5. The Authorization Endpoint . . . . . . . . . . . . . . . 19 5.5. The Authorization Endpoint . . . . . . . . . . . . . . . 19
skipping to change at page 3, line 5 skipping to change at page 3, line 5
5.6.5. Mapping Parameters to CBOR . . . . . . . . . . . . . 27 5.6.5. Mapping Parameters to CBOR . . . . . . . . . . . . . 27
5.7. The Introspection Endpoint . . . . . . . . . . . . . . . 27 5.7. The Introspection Endpoint . . . . . . . . . . . . . . . 27
5.7.1. Introspection Request . . . . . . . . . . . . . . . . 28 5.7.1. Introspection Request . . . . . . . . . . . . . . . . 28
5.7.2. Introspection Response . . . . . . . . . . . . . . . 29 5.7.2. Introspection Response . . . . . . . . . . . . . . . 29
5.7.3. Error Response . . . . . . . . . . . . . . . . . . . 30 5.7.3. Error Response . . . . . . . . . . . . . . . . . . . 30
5.7.4. Mapping Introspection parameters to CBOR . . . . . . 31 5.7.4. Mapping Introspection parameters to CBOR . . . . . . 31
5.8. The Access Token . . . . . . . . . . . . . . . . . . . . 31 5.8. The Access Token . . . . . . . . . . . . . . . . . . . . 31
5.8.1. The Authorization Information Endpoint . . . . . . . 32 5.8.1. The Authorization Information Endpoint . . . . . . . 32
5.8.1.1. Verifying an Access Token . . . . . . . . . . . . 33 5.8.1.1. Verifying an Access Token . . . . . . . . . . . . 33
5.8.1.2. Protecting the Authzorization Information 5.8.1.2. Protecting the Authzorization Information
Endpoint . . . . . . . . . . . . . . . . . . . . 34 Endpoint . . . . . . . . . . . . . . . . . . . . 35
5.8.2. Client Requests to the RS . . . . . . . . . . . . . . 34 5.8.2. Client Requests to the RS . . . . . . . . . . . . . . 35
5.8.3. Token Expiration . . . . . . . . . . . . . . . . . . 35 5.8.3. Token Expiration . . . . . . . . . . . . . . . . . . 36
6. Security Considerations . . . . . . . . . . . . . . . . . . . 36 6. Security Considerations . . . . . . . . . . . . . . . . . . . 36
6.1. Unprotected AS Information . . . . . . . . . . . . . . . 37 6.1. Unprotected AS Information . . . . . . . . . . . . . . . 38
6.2. Minimal security requirements for communication . 37 6.2. Minimal security requirements for communication . 38
6.3. Use of Nonces for Replay Protection . . . . . . . . . . . 38 6.3. Use of Nonces for Replay Protection . . . . . . . . . . . 39
6.4. Combining profiles . . . . . . . . . . . . . . . . . . . 39 6.4. Combining profiles . . . . . . . . . . . . . . . . . . . 39
6.5. Unprotected Information . . . . . . . . . . . . . . . . . 39 6.5. Unprotected Information . . . . . . . . . . . . . . . . . 39
6.6. Denial of service against or with Introspection . . 39 6.6. Denial of service against or with Introspection . . 40
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 40 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 40
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
8.1. Authorization Server Information . . . . . . . . . . . . 41 8.1. Authorization Server Information . . . . . . . . . . . . 41
8.2. OAuth Extensions Error Registration . . . . . . . . . . . 41 8.2. OAuth Extensions Error Registration . . . . . . . . . . . 42
8.3. OAuth Error Code CBOR Mappings Registry . . . . . . . . . 42 8.3. OAuth Error Code CBOR Mappings Registry . . . . . . . . . 42
8.4. OAuth Grant Type CBOR Mappings . . . . . . . . . . . . . 42 8.4. OAuth Grant Type CBOR Mappings . . . . . . . . . . . . . 43
8.5. OAuth Access Token Types . . . . . . . . . . . . . . . . 43 8.5. OAuth Access Token Types . . . . . . . . . . . . . . . . 43
8.6. OAuth Token Type CBOR Mappings . . . . . . . . . . . . . 43 8.6. OAuth Token Type CBOR Mappings . . . . . . . . . . . . . 43
8.6.1. Initial Registry Contents . . . . . . . . . . . . . . 43 8.6.1. Initial Registry Contents . . . . . . . . . . . . . . 44
8.7. ACE Profile Registry . . . . . . . . . . . . . . . . . . 44 8.7. ACE Profile Registry . . . . . . . . . . . . . . . . . . 44
8.8. OAuth Parameter Registration . . . . . . . . . . . . . . 44 8.8. OAuth Parameter Registration . . . . . . . . . . . . . . 45
8.9. Token Endpoint CBOR Mappings Registry . . . . . . . . . . 44 8.9. Token Endpoint CBOR Mappings Registry . . . . . . . . . . 45
8.10. OAuth Introspection Response Parameter Registration . . . 45 8.10. OAuth Introspection Response Parameter Registration . . . 46
8.11. Introspection Endpoint CBOR Mappings Registry . . . . . . 45 8.11. Introspection Endpoint CBOR Mappings Registry . . . . . . 46
8.12. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 46 8.12. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 47
8.13. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 47 8.13. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 47
8.14. Media Type Registrations . . . . . . . . . . . . . . . . 47 8.14. Media Type Registrations . . . . . . . . . . . . . . . . 48
8.15. CoAP Content-Format Registry . . . . . . . . . . . . . . 48 8.15. CoAP Content-Format Registry . . . . . . . . . . . . . . 49
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 49
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 49 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 50
10.1. Normative References . . . . . . . . . . . . . . . . . . 49 10.1. Normative References . . . . . . . . . . . . . . . . . . 50
10.2. Informative References . . . . . . . . . . . . . . . . . 51 10.2. Informative References . . . . . . . . . . . . . . . . . 52
Appendix A. Design Justification . . . . . . . . . . . . . . . . 53 Appendix A. Design Justification . . . . . . . . . . . . . . . . 54
Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 57 Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 58
Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 59 Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 60
Appendix D. Assumptions on AS knowledge about C and RS . . . . . 60 Appendix D. Assumptions on AS knowledge about C and RS . . . . . 60
Appendix E. Deployment Examples . . . . . . . . . . . . . . . . 60 Appendix E. Deployment Examples . . . . . . . . . . . . . . . . 61
E.1. Local Token Validation . . . . . . . . . . . . . . . . . 61 E.1. Local Token Validation . . . . . . . . . . . . . . . . . 61
E.2. Introspection Aided Token Validation . . . . . . . . . . 65 E.2. Introspection Aided Token Validation . . . . . . . . . . 65
Appendix F. Document Updates . . . . . . . . . . . . . . . . . . 69 Appendix F. Document Updates . . . . . . . . . . . . . . . . . . 69
F.1. Version -15 to -16 . . . . . . . . . . . . . . . . . . . 69 F.1. Version -17 to -18 . . . . . . . . . . . . . . . . . . . 69
F.2. Version -14 to -15 . . . . . . . . . . . . . . . . . . . 69 F.2. Version -16 to -17 . . . . . . . . . . . . . . . . . . . 69
F.3. Version -13 to -14 . . . . . . . . . . . . . . . . . . . 69 F.3. Version -15 to -16 . . . . . . . . . . . . . . . . . . . 70
F.4. Version -12 to -13 . . . . . . . . . . . . . . . . . . . 70 F.4. Version -14 to -15 . . . . . . . . . . . . . . . . . . . 70
F.5. Version -11 to -12 . . . . . . . . . . . . . . . . . . . 70 F.5. Version -13 to -14 . . . . . . . . . . . . . . . . . . . 70
F.6. Version -10 to -11 . . . . . . . . . . . . . . . . . . . 70 F.6. Version -12 to -13 . . . . . . . . . . . . . . . . . . . 70
F.7. Version -09 to -10 . . . . . . . . . . . . . . . . . . . 70 F.7. Version -11 to -12 . . . . . . . . . . . . . . . . . . . 70
F.8. Version -08 to -09 . . . . . . . . . . . . . . . . . . . 70 F.8. Version -10 to -11 . . . . . . . . . . . . . . . . . . . 71
F.9. Version -07 to -08 . . . . . . . . . . . . . . . . . . . 71 F.9. Version -09 to -10 . . . . . . . . . . . . . . . . . . . 71
F.10. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 71 F.10. Version -08 to -09 . . . . . . . . . . . . . . . . . . . 71
F.11. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 71 F.11. Version -07 to -08 . . . . . . . . . . . . . . . . . . . 71
F.12. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 71 F.12. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 72
F.13. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 72 F.13. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 72
F.14. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 72 F.14. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 72
F.15. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 72 F.15. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 72
F.16. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 73 F.16. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 73
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 73 F.17. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 73
F.18. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 73
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 74
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 21, line 17 skipping to change at page 21, line 17
[I-D.ietf-core-object-security] is used to provide object-security, [I-D.ietf-core-object-security] is used to provide object-security,
therefore the Content-Format is "application/oscore" wrapping the therefore the Content-Format is "application/oscore" wrapping the
"application/ace+cbor" type content. Also note that in this example "application/ace+cbor" type content. Also note that in this example
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
Content-Format: "application/oscore" Content-Format: "application/oscore"
Payload: Payload:
0x44025d1 ... (full payload ommitted for brevity) ... 68b3825e 0x44025d1 ... (full payload ommitted 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" : {
skipping to change at page 29, line 8 skipping to change at page 29, line 8
For example, Figure 13 shows a RS calling the token introspection For example, Figure 13 shows a RS calling the token introspection
endpoint at the AS to query about an OAuth 2.0 proof-of-possession endpoint at the AS to query about an OAuth 2.0 proof-of-possession
token. Note that object security based on OSCORE token. Note that object security based on OSCORE
[I-D.ietf-core-object-security] is assumed in this example, therefore [I-D.ietf-core-object-security] is assumed in this example, therefore
the Content-Format is "application/oscore". Figure 14 shows the the Content-Format is "application/oscore". Figure 14 shows the
decoded payload. decoded payload.
Header: POST (Code=0.02) Header: POST (Code=0.02)
Uri-Host: "as.example.com" Uri-Host: "as.example.com"
Uri-Path: "introspect" Uri-Path: "introspect"
OSCORE: 0x09, 0x05, 0x25
Content-Format: "application/oscore" Content-Format: "application/oscore"
Payload: Payload:
... COSE content ... ... COSE content ...
Figure 13: Example introspection request. Figure 13: Example introspection request.
{ {
"token" : b64'7gj0dXJQ43U', "token" : b64'7gj0dXJQ43U',
"token_type_hint" : "pop" "token_type_hint" : "pop"
} }
skipping to change at page 29, line 43 skipping to change at page 29, line 44
profile OPTIONAL. This indicates the profile that the RS MUST use profile OPTIONAL. This indicates the profile that the RS MUST use
with the client. See Section 5.6.4.3 for more details on the with the client. See Section 5.6.4.3 for more details on the
formatting of this parameter. formatting of this parameter.
Furthermore [I-D.ietf-ace-oauth-params] defines more parameters that Furthermore [I-D.ietf-ace-oauth-params] defines more parameters that
the AS MUST be able to use when responding to a request to the the AS MUST be able to use when responding to a request to the
introspection endpoint. introspection endpoint.
For example, Figure 15 shows an AS response to the introspection For example, Figure 15 shows an AS response to the introspection
request in Figure 13. Note that this example contains the "cnf" request in Figure 13. Note that this example contains the "cnf"
parameter defined in [I-D.ietf-ace-oauth-params]/. parameter defined in [I-D.ietf-ace-oauth-params].
Header: Created Code=2.01) Header: Created Code=2.01)
Content-Format: "application/ace+cbor" Content-Format: "application/ace+cbor"
Payload: Payload:
{ {
"active" : true, "active" : true,
"scope" : "read", "scope" : "read",
"profile" : "coap_dtls", "profile" : "coap_dtls",
"cnf" : { "cnf" : {
"COSE_Key" : { "COSE_Key" : {
skipping to change at page 31, line 49 skipping to change at page 31, line 49
\-------------------+----------+-------------------------/ \-------------------+----------+-------------------------/
Figure 16: CBOR Mappings to Token Introspection Parameters. Figure 16: CBOR Mappings to Token Introspection Parameters.
5.8. The Access Token 5.8. The Access Token
This framework RECOMMENDS the use of CBOR web token (CWT) as This framework RECOMMENDS the use of CBOR web token (CWT) as
specified in [RFC8392]. specified in [RFC8392].
In order to facilitate offline processing of access tokens, this In order to facilitate offline processing of access tokens, this
draft uses the "cnf" claim from document uses the "cnf" claim from
[I-D.ietf-ace-cwt-proof-of-possession] and specifies the "scope" [I-D.ietf-ace-cwt-proof-of-possession] and specifies the "scope"
claim for both JSON and CBOR web tokens. claim for JWT- and CWT-encoded tokens.
The "scope" claim explicitly encodes the scope of a given access The "scope" claim explicitly encodes the scope of a given access
token. This claim follows the same encoding rules as defined in token. This claim follows the same encoding rules as defined in
Section 3.3 of [RFC6749], but in addition implementers MAY use byte Section 3.3 of [RFC6749], but in addition implementers MAY use byte
strings as scope values, to achieve compact encoding of large scope strings as scope values, to achieve compact encoding of large scope
elements. The meaning of a specific scope value is application elements. The meaning of a specific scope value is application
specific and expected to be known to the RS running that application. specific and expected to be known to the RS running that application.
If the AS needs to convey a hint to the RS about which profile it If the AS needs to convey a hint to the RS about which profile it
should use to communicate with the client, the AS MAY include a should use to communicate with the client, the AS MAY include a
skipping to change at page 32, line 36 skipping to change at page 32, line 36
framework MAY define other methods for token transport. framework MAY define other methods for token transport.
The method consists of an authz-info endpoint, implemented by the RS. The method consists of an authz-info endpoint, implemented by the RS.
A client using this method MUST make a POST request to the authz-info A client using this method MUST make a POST request to the authz-info
endpoint at the RS with the access token in the payload. The RS endpoint at the RS with the access token in the payload. The RS
receiving the token MUST verify the validity of the token. If the receiving the token MUST verify the validity of the token. If the
token is valid, the RS MUST respond to the POST request with 2.01 token is valid, the RS MUST respond to the POST request with 2.01
(Created). Section Section 5.8.1.1 outlines how an RS MUST proceed (Created). Section Section 5.8.1.1 outlines how an RS MUST proceed
to verify the validity of an access token. to verify the validity of an access token.
If the access token is a CWT and is sent via CoAP, the content format
"application/cwt" MUST be used. If a token is sent via HTTP the
equivalent media type "application/cwt" MUST be used.
The RS MUST be prepared to store at least one access token for future The RS MUST be prepared to store at least one access token for future
use. This is a difference to how access tokens are handled in OAuth use. This is a difference to how access tokens are handled in OAuth
2.0, where the access token is typically sent along with each 2.0, where the access token is typically sent along with each
request, and therefore not stored at the RS. request, and therefore not stored at the RS.
This specification RECOMMENDS that an RS stores only one token per This specification RECOMMENDS that an RS stores only one token per
proof-of-possession key, meaning that an additional token linked to proof-of-possession key, meaning that an additional token linked to
the same key will overwrite any exiting token at the RS. the same key will overwrite any existing token at the RS.
If the payload sent to the authz-info endpoint does not parse to a If the payload sent to the authz-info endpoint does not parse to a
token, the RS MUST respond with a response code equivalent to the token, the RS MUST respond with a response code equivalent to the
CoAP code 4.00 (Bad Request). CoAP code 4.00 (Bad Request).
The RS MAY make an introspection request to validate the token before The RS MAY make an introspection request to validate the token before
responding to the POST request to the authz-info endpoint. responding to the POST request to the authz-info endpoint.
Profiles MUST specify whether the authz-info endpoint is protected, Profiles MUST specify whether the authz-info endpoint is protected,
including whether error responses from this endpoint are protected. including whether error responses from this endpoint are protected.
skipping to change at page 33, line 28 skipping to change at page 33, line 25
A RS MAY use introspection on a token received through the authz-info A RS MAY use introspection on a token received through the authz-info
endpoint, e.g. if the token is an opaque reference. Some transport endpoint, e.g. if the token is an opaque reference. Some transport
protocols may provide a way to indicate that the RS is busy and the protocols may provide a way to indicate that the RS is busy and the
client should retry after an interval; this type of status update client should retry after an interval; this type of status update
would be appropriate while the RS is waiting for an introspection would be appropriate while the RS is waiting for an introspection
response. response.
5.8.1.1. Verifying an Access Token 5.8.1.1. Verifying an Access Token
When an RS receives an access token, it MUST verify it before storing When an RS receives an access token, it MUST verify it before storing
it. The verification is based on the claims of the token and its it. The details of token verification depends on various aspects,
cryptographic wrapper (if any), so the RS needs to retrieve those including the token encoding, the type of token, the security
claims. If the claims cannot be retrieved the RS MUST discard the protection applied to the token, and the claims. The token encoding
token and in case of an interaction via the authz-info endpoint, matters since the security wrapper differs between the token
return an error message with a response code equivalent to the CoAP encodings. For example, a CWT token uses COSE while a JWT token uses
code 4.00 (Bad Request). JOSE. The type of token also has an influence on the verification
procedure since tokens may be self-contained whereby token
verification may happen locally at the RS while a token-by-reference
requires further interaction with the authorization server, for
example using token introspection, to obtain the claims associated
with the token reference. Self-contained token MUST, at a minimum,
be integrity protected but they MAY also be encrypted.
Since the cryptographic wrapper of the token (e.g. a COSE message) For self-contained tokens the RS MUST process the security protection
could include encryption, it needs to be verified first, based on of the token first, as specified by the respective token format. For
shared cryptographic material with recognized AS. If this CWT the description can be found in [RFC8392] and for JWT the
verification fails, the RS MUST discard the token and if this was an relevant specification is [RFC7519]. This MUST include a
interaction with authz-info it MUST respond with a response code verification that security protection (and thus the token) was
equivalent to the CoAP code 4.01 (Unauthorized). generated by an AS that has the right to issue access tokens for this
RS.
The following claims MUST be checked if present, and errors returned In case the token is communicated by reference the RS needs to obtain
when a check fails, in the order of priority of this list: the claims first. When the RS uses token introspection the relevant
specification is [RFC7662] with CoAP transport specified in
Section 5.7.
Errors may happen during this initial processing stage:
o If token or claim verification fails, the RS MUST discard the
token and, if this was an interaction with authz-info, return an
error message with a response code equivalent to the CoAP code
4.01 (Unauthorized).
o If the claims cannot be obtained the RS MUST discard the token
and, in case of an interaction via the authz-info endpoint, return
an error message with a response code equivalent to the CoAP code
4.00 (Bad Request).
Next, the RS MUST verify claims, if present, contained in the access
token. Errors are returned when claim checks fail, in the order of
priority of this list:
iss The issuer claim must identify an AS that has the authority to iss The issuer claim must identify an AS that has the authority to
issue access tokens for the receiving RS. If that is not the case issue access tokens for the receiving RS. If that is not the case
the RS MUST respond with a response code equivalent to the CoAP the RS MUST respond with a response code equivalent to the CoAP
code 4.01 (Unauthorized). code 4.01 (Unauthorized).
exp The expiration date must be in the future. Note that this has exp The expiration date must be in the future. If that is not the
to be verified again at access time. If that is not the case the case the RS MUST respond with a response code equivalent to the
RS MUST respond with a response code equivalent to the CoAP code CoAP code 4.01 (Unauthorized). Note that the RS has to terminate
4.01 (Unauthorized). access rights to the protected resources at the time when the
tokens expire.
aud The audience claim must refer to an audience that the RS aud The audience claim must refer to an audience that the RS
identifies with. If that is not the case the RS MUST respond with identifies with. If that is not the case the RS MUST respond with
a response code equivalent to the CoAP code 4.03 (Forbidden). a response code equivalent to the CoAP code 4.03 (Forbidden).
scope The RS must recognize value of the scope claim. If that is scope The RS must recognize value of the scope claim. If that is
not the case the RS MUST respond with a response code equivalent not the case the RS MUST respond with a response code equivalent
to the CoAP code 4.00 (Bad Request). The RS MAY provide to the CoAP code 4.00 (Bad Request). The RS MAY provide
additional information in the error response, in order to clarify additional information in the error response, to clarify what went
what went wrong. wrong.
If the access token contains any other claims that the RS cannot If the access token contains any other claims that the RS cannot
process the RS MUST respond with a response code equivalent to the process the RS MUST respond with a response code equivalent to the
CoAP code 4.00 (Bad Request). The RS MAY provide additional detail CoAP code 4.00 (Bad Request). The RS MAY provide additional detail
in the error response to clarify which claim couldn't be processed. in the error response to clarify which claim couldn't be processed.
Note that the Subject (sub) claim cannot always be verified when the Note that the Subject (sub) claim cannot always be verified when the
token is submitted to the RS, since the client may not have token is submitted to the RS since the client may not have
authenticated yet. Also note that a counter for the expires_in (exi) authenticated yet. Also note that a counter for the expires_in (exi)
claim MUST be initialized when the RS first verifies this token. claim MUST be initialized when the RS first verifies this token.
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], in order to provide additional detail to Section 3.1 of [RFC6750], to provide additional details to the
the client. client.
5.8.1.2. Protecting the Authzorization Information Endpoint 5.8.1.2. Protecting the Authzorization 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).
skipping to change at page 47, line 27 skipping to change at page 48, line 4
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: N/A
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 Description: The expiration time of a token measured from
when it was received at the RS in seconds.
o JWT Claim Name: N/A
o Claim Key: TBD (suggested: 41)
o Claim Value Type(s): integer
o Change Controller: IESG
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
specified in [RFC6838]. specified in [RFC6838].
Type name: application Type name: application
skipping to change at page 49, line 30 skipping to change at page 50, line 18
[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-00 (work in progress), September 2018. params-01 (work in progress), November 2018.
[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 60, line 20 skipping to change at page 61, line 4
Appendix D. Assumptions on AS knowledge about C and RS Appendix D. Assumptions on AS knowledge about C and RS
This section lists the assumptions on what an AS should know about a This section lists the assumptions on what an AS should know about a
client and a RS in order to be able to respond to requests to the client and a RS in order to be able to respond to requests to the
token and introspection endpoints. How this information is token and introspection endpoints. How this information is
established is out of scope for this document. established is out of scope for this document.
o The identifier of the client or RS. o The identifier of the client or RS.
o The profiles that the client or RS supports. o The profiles that the client or RS supports.
o The scopes that the RS supports. o The scopes that the RS supports.
o The audiences that the RS identifies with. o The audiences that the RS identifies with.
o The key types (e.g., pre-shared symmetric key, raw public key, key o The key types (e.g., pre-shared symmetric key, raw public key, key
length, other key parameters) that the client or RS supports. length, other key parameters) that the client or RS supports.
o The types of access tokens the RS supports (e.g., CWT). o The types of access tokens the RS supports (e.g., CWT).
o If the RS supports CWTs, the COSE parameters for the crypto o If the RS supports CWTs, the COSE parameters for the crypto
wrapper (e.g., algorithm, key-wrap algorithm, key-length). wrapper (e.g., algorithm, key-wrap algorithm, key-length).
o The expiration time for access tokens issued to this RS (unless o The expiration time for access tokens issued to this RS (unless
the RS accepts a default time chosen by the AS). the RS accepts a default time chosen by the AS).
o The symmetric key shared between client or RS and AS (if any). o The symmetric key shared between client or RS and AS (if any).
o The raw public key of the client or RS (if any). o The raw public key of the client or RS (if any).
o Whether the RS has synchronized time (and thus is able to use the
'exp' claim) or not.
Appendix E. Deployment Examples Appendix E. Deployment Examples
There is a large variety of IoT deployments, as is indicated in There is a large variety of IoT deployments, as is indicated in
Appendix A, and this section highlights a few common variants. This Appendix A, and this section highlights a few common variants. This
section is not normative but illustrates how the framework can be section is not normative but illustrates how the framework can be
applied. applied.
For each of the deployment variants, there are a number of possible For each of the deployment variants, there are a number of possible
security setups between clients, resource servers and authorization security setups between clients, resource servers and authorization
skipping to change at page 68, line 10 skipping to change at page 68, line 10
(cnf) parameter that allows the RS to verify the client's proof of (cnf) parameter that allows the RS to verify the client's proof of
possession in step F. possession in step F.
After receiving message E, the RS responds to the client's POST in After receiving message E, the RS responds to the client's POST in
step C with the CoAP response code 2.01 (Created). step C with the CoAP response code 2.01 (Created).
Resource Resource
Client Server Client Server
| | | |
C: +-------->| Header: POST (T=CON, Code=0.02) C: +-------->| Header: POST (T=CON, Code=0.02)
| POST | Uri-Path:"authz-info" | POST | Uri-Path:"authz-info"
| | Content-Format: "application/ace+cbor"
| | Payload: b64'VGVzdCB0b2tlbg==' | | Payload: b64'VGVzdCB0b2tlbg=='
| | | |
| | Authorization | | Authorization
| | Server | | Server
| | | | | |
| D: +--------->| Header: POST (Code=0.02) | D: +--------->| Header: POST (Code=0.02)
| | POST | Uri-Path: "introspect" | | POST | Uri-Path: "introspect"
| | | Content-Format: "application/ace+cbor" | | | Content-Format: "application/ace+cbor"
| | | Payload: <Request-Payload> | | | Payload: <Request-Payload>
| | | | | |
skipping to change at page 69, line 32 skipping to change at page 69, 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 -15 to -16 F.1. Version -17 to -18
o Added OSCORE options in examples involving OSCORE.
o Removed requirement for the client to send application/cwt, since
the client has no way to know.
o Clarified verification of tokens by the RS.
o Added exi claim CWT registration.
F.2. Version -16 to -17
o Added references to (D)TLS 1.3.
o Added requirement that responses are bound to requests.
o Specify that grant_type is OPTIONAL in C2AS requests (as opposed
to REQUIRED in OAuth).
o Replaced examples with hypothetical COSE profile with OSCORE.
o Added requirement for content type application/ace+cbor in error
responses for token and introspection requests and responses.
o Reworked abbreviation space for claims, request and response
parameters.
o Added text that the RS may indicate that it is busy at the authz-
info resource.
o Added section that specifies how the RS verifies an access token.
o Added section on the protection of the authz-info endpoint.
o Removed the expiration mechanism based on sequence numbers.
o Added reference to RFC7662 security considerations.
o Added considerations on minimal security requirements for
communication.
o Added security considerations on unprotected information sent to
authz-info and in the error responses.
F.3. 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.2. Version -14 to -15 F.4. 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.3. Version -13 to -14 F.5. 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.4. Version -12 to -13 F.6. 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.5. Version -11 to -12 F.7. 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.6. Version -10 to -11 F.8. 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.7. Version -09 to -10 F.9. 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.8. Version -08 to -09 F.10. 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.9. Version -07 to -08 F.11. 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 71, line 23 skipping to change at page 72, line 4
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.10. Version -06 to -07 F.12. Version -06 to -07
o Various clarifications added. o Various clarifications added.
o Fixed erroneous author email. o Fixed erroneous author email.
F.11. Version -05 to -06 F.13. 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.12. Version -04 to -05 F.14. 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.13. Version -03 to -04 F.15. 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.14. Version -02 to -03 F.16. 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.15. Version -01 to -02 F.17. 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.16. Version -00 to -01 F.18. 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. 55 change blocks. 
101 lines changed or deleted 166 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/