draft-ietf-ace-oauth-authz-20.txt   draft-ietf-ace-oauth-authz-21.txt 
ACE Working Group L. Seitz ACE Working Group L. Seitz
Internet-Draft RISE Internet-Draft RISE
Intended status: Standards Track G. Selander Intended status: Standards Track G. Selander
Expires: August 15, 2019 Ericsson Expires: August 18, 2019 Ericsson
E. Wahlstroem E. Wahlstroem
S. Erdtman S. Erdtman
Spotify AB Spotify AB
H. Tschofenig H. Tschofenig
Arm Ltd. Arm Ltd.
February 11, 2019 February 14, 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-20 draft-ietf-ace-oauth-authz-21
Abstract Abstract
This specification defines a framework for authentication and This specification defines a framework for authentication and
authorization in Internet of Things (IoT) environments called ACE- authorization in Internet of Things (IoT) environments called ACE-
OAuth. The framework is based on a set of building blocks including OAuth. The framework is based on a set of building blocks including
OAuth 2.0 and CoAP, thus making a well-known and widely used OAuth 2.0 and CoAP, thus making a well-known and widely used
authorization solution suitable for IoT devices. Existing authorization solution suitable for IoT devices. Existing
specifications are used where possible, but where the constraints of specifications are used where possible, but where the constraints of
IoT devices require it, extensions are added and profiles are IoT devices require it, extensions are added and profiles are
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 15, 2019. This Internet-Draft will expire on August 18, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 8 skipping to change at page 3, line 8
5.7.2. Introspection Response . . . . . . . . . . . . . . . 31 5.7.2. Introspection Response . . . . . . . . . . . . . . . 31
5.7.3. Error Response . . . . . . . . . . . . . . . . . . . 32 5.7.3. Error Response . . . . . . . . . . . . . . . . . . . 32
5.7.4. Mapping Introspection parameters to CBOR . . . . . . 33 5.7.4. Mapping Introspection parameters to CBOR . . . . . . 33
5.8. The Access Token . . . . . . . . . . . . . . . . . . . . 33 5.8. The Access Token . . . . . . . . . . . . . . . . . . . . 33
5.8.1. The Authorization Information Endpoint . . . . . . . 34 5.8.1. The Authorization Information Endpoint . . . . . . . 34
5.8.1.1. Verifying an Access Token . . . . . . . . . . . . 35 5.8.1.1. Verifying an Access Token . . . . . . . . . . . . 35
5.8.1.2. Protecting the Authorization Information 5.8.1.2. Protecting the Authorization Information
Endpoint . . . . . . . . . . . . . . . . . . . . 37 Endpoint . . . . . . . . . . . . . . . . . . . . 37
5.8.2. Client Requests to the RS . . . . . . . . . . . . . . 37 5.8.2. Client Requests to the RS . . . . . . . . . . . . . . 37
5.8.3. Token Expiration . . . . . . . . . . . . . . . . . . 38 5.8.3. Token Expiration . . . . . . . . . . . . . . . . . . 38
5.8.4. Key Expriation . . . . . . . . . . . . . . . . . . . 39
6. Security Considerations . . . . . . . . . . . . . . . . . . . 39 6. Security Considerations . . . . . . . . . . . . . . . . . . . 39
6.1. Unprotected AS Request Creation Hints . . . . . . . . . . 40 6.1. Unprotected AS Request Creation Hints . . . . . . . . . . 41
6.2. Minimal security requirements for communication . 40 6.2. Minimal security requirements for communication . 41
6.3. Use of Nonces for Replay Protection . . . . . . . . . . . 41 6.3. Use of Nonces for Replay Protection . . . . . . . . . . . 42
6.4. Combining profiles . . . . . . . . . . . . . . . . . . . 41 6.4. Combining profiles . . . . . . . . . . . . . . . . . . . 42
6.5. Unprotected Information . . . . . . . . . . . . . . . . . 42 6.5. Unprotected Information . . . . . . . . . . . . . . . . . 42
6.6. Identifying audiences . . . . . . . . . . . . . . . . . . 42 6.6. Identifying audiences . . . . . . . . . . . . . . . . . . 43
6.7. Denial of service against or with Introspection . . 43 6.7. Denial of service against or with Introspection . . 44
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 43 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 44
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45
8.1. ACE Authorization Server Request Creation Hints . . . . . 44 8.1. ACE Authorization Server Request Creation Hints . . . . . 45
8.2. OAuth Extensions Error Registration . . . . . . . . . . . 45 8.2. OAuth Extensions Error Registration . . . . . . . . . . . 46
8.3. OAuth Error Code CBOR Mappings Registry . . . . . . . . . 45 8.3. OAuth Error Code CBOR Mappings Registry . . . . . . . . . 46
8.4. OAuth Grant Type CBOR Mappings . . . . . . . . . . . . . 46 8.4. OAuth Grant Type CBOR Mappings . . . . . . . . . . . . . 46
8.5. OAuth Access Token Types . . . . . . . . . . . . . . . . 46 8.5. OAuth Access Token Types . . . . . . . . . . . . . . . . 47
8.6. OAuth Access Token Type CBOR Mappings . . . . . . . . . . 47 8.6. OAuth Access Token Type CBOR Mappings . . . . . . . . . . 47
8.6.1. Initial Registry Contents . . . . . . . . . . . . . . 47 8.6.1. Initial Registry Contents . . . . . . . . . . . . . . 48
8.7. ACE Profile Registry . . . . . . . . . . . . . . . . . . 47 8.7. ACE Profile Registry . . . . . . . . . . . . . . . . . . 48
8.8. OAuth Parameter Registration . . . . . . . . . . . . . . 48 8.8. OAuth Parameter Registration . . . . . . . . . . . . . . 49
8.9. OAuth Parameters CBOR Mappings Registry . . . . . . . . . 48 8.9. OAuth Parameters CBOR Mappings Registry . . . . . . . . . 49
8.10. OAuth Introspection Response Parameter Registration . . . 49 8.10. OAuth Introspection Response Parameter Registration . . . 49
8.11. OAuth Token Introspection Response CBOR Mappings Registry 49 8.11. OAuth Token Introspection Response CBOR Mappings Registry 50
8.12. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 50 8.12. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 50
8.13. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 50 8.13. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 51
8.14. Media Type Registrations . . . . . . . . . . . . . . . . 51 8.14. Media Type Registrations . . . . . . . . . . . . . . . . 52
8.15. CoAP Content-Format Registry . . . . . . . . . . . . . . 52 8.15. CoAP Content-Format Registry . . . . . . . . . . . . . . 53
8.16. Expert Review Instructions . . . . . . . . . . . . . . . 52 8.16. Expert Review Instructions . . . . . . . . . . . . . . . 53
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 54
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 54
10.1. Normative References . . . . . . . . . . . . . . . . . . 54 10.1. Normative References . . . . . . . . . . . . . . . . . . 54
10.2. Informative References . . . . . . . . . . . . . . . . . 56 10.2. Informative References . . . . . . . . . . . . . . . . . 56
Appendix A. Design Justification . . . . . . . . . . . . . . . . 58 Appendix A. Design Justification . . . . . . . . . . . . . . . . 59
Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 62 Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 62
Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 64 Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 64
Appendix D. Assumptions on AS knowledge about C and RS . . . . . 64 Appendix D. Assumptions on AS knowledge about C and RS . . . . . 65
Appendix E. Deployment Examples . . . . . . . . . . . . . . . . 65 Appendix E. Deployment Examples . . . . . . . . . . . . . . . . 66
E.1. Local Token Validation . . . . . . . . . . . . . . . . . 65 E.1. Local Token Validation . . . . . . . . . . . . . . . . . 66
E.2. Introspection Aided Token Validation . . . . . . . . . . 69 E.2. Introspection Aided Token Validation . . . . . . . . . . 70
Appendix F. Document Updates . . . . . . . . . . . . . . . . . . 73 Appendix F. Document Updates . . . . . . . . . . . . . . . . . . 74
F.1. Verion -19 to 20 . . . . . . . . . . . . . . . . . . . . 73 F.1. Verion -20 to 21 . . . . . . . . . . . . . . . . . . . . 74
F.2. Version -18 to -19 . . . . . . . . . . . . . . . . . . . 73 F.2. Verion -19 to 20 . . . . . . . . . . . . . . . . . . . . 74
F.3. Version -17 to -18 . . . . . . . . . . . . . . . . . . . 74 F.3. Version -18 to -19 . . . . . . . . . . . . . . . . . . . 74
F.4. Version -16 to -17 . . . . . . . . . . . . . . . . . . . 74 F.4. Version -17 to -18 . . . . . . . . . . . . . . . . . . . 75
F.5. Version -15 to -16 . . . . . . . . . . . . . . . . . . . 74 F.5. Version -16 to -17 . . . . . . . . . . . . . . . . . . . 75
F.6. Version -14 to -15 . . . . . . . . . . . . . . . . . . . 74 F.6. Version -15 to -16 . . . . . . . . . . . . . . . . . . . 75
F.7. Version -13 to -14 . . . . . . . . . . . . . . . . . . . 75 F.7. Version -14 to -15 . . . . . . . . . . . . . . . . . . . 75
F.8. Version -12 to -13 . . . . . . . . . . . . . . . . . . . 75 F.8. Version -13 to -14 . . . . . . . . . . . . . . . . . . . 76
F.9. Version -11 to -12 . . . . . . . . . . . . . . . . . . . 75 F.9. Version -12 to -13 . . . . . . . . . . . . . . . . . . . 76
F.10. Version -10 to -11 . . . . . . . . . . . . . . . . . . . 75 F.10. Version -11 to -12 . . . . . . . . . . . . . . . . . . . 76
F.11. Version -09 to -10 . . . . . . . . . . . . . . . . . . . 75 F.11. Version -10 to -11 . . . . . . . . . . . . . . . . . . . 76
F.12. Version -08 to -09 . . . . . . . . . . . . . . . . . . . 75 F.12. Version -09 to -10 . . . . . . . . . . . . . . . . . . . 76
F.13. Version -07 to -08 . . . . . . . . . . . . . . . . . . . 76 F.13. Version -08 to -09 . . . . . . . . . . . . . . . . . . . 77
F.14. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 76 F.14. Version -07 to -08 . . . . . . . . . . . . . . . . . . . 77
F.15. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 76 F.15. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 77
F.16. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 77 F.16. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 78
F.17. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 77 F.17. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 78
F.18. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 77 F.18. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 78
F.19. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 77 F.19. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 78
F.20. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 78 F.20. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 79
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 79 F.21. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 79
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 80
1. Introduction 1. Introduction
Authorization is the process for granting approval to an entity to Authorization is the process for granting approval to an entity to
access a resource [RFC4949]. The authorization task itself can best access a resource [RFC4949]. The authorization task itself can best
be described as granting access to a requesting client, for a be described as granting access to a requesting client, for a
resource hosted on a device, the resource server (RS). This exchange resource hosted on a device, the resource server (RS). This exchange
is mediated by one or multiple authorization servers (AS). Managing is mediated by one or multiple authorization servers (AS). Managing
authorization for a large number of devices and users can be a authorization for a large number of devices and users can be a
complex task. complex task.
skipping to change at page 39, line 5 skipping to change at page 39, line 5
in some regular intervals, so that the can AS provide the RS with in some regular intervals, so that the can AS provide the RS with
a list of expired tokens. The drawback of this mitigation is that a list of expired tokens. The drawback of this mitigation is that
the RS might as well use the communication with the AS to the RS might as well use the communication with the AS to
synchronize its internal clock. synchronize its internal clock.
If a token that authorizes a long running request such as a CoAP If a token that authorizes a long running request such as a CoAP
Observe [RFC7641] expires, the RS MUST send an error response with Observe [RFC7641] expires, the RS MUST send an error response with
the response code equivalent to the CoAP code 4.01 (Unauthorized) to the response code equivalent to the CoAP code 4.01 (Unauthorized) to
the client and then terminate processing the long running request. the client and then terminate processing the long running request.
5.8.4. Key Expriation
The AS provides the client with key material that the RS uses. This
can either be a common symmetric pop-key, or an asymmetric key used
by the RS to authenticate towards the client. Since there is no
metadata associated to those keys, the client has no way of knowing
if these keys are still valid. This may lead to situations where the
client sends requests containing sensitive information to the RS
using a key that is expired and possibly in the hands of an attacker,
or accepts responses from the RS that are not properly protected and
could possibly have been forged by an attacker.
In order to prevent this, the client must assume that those keys are
only valid as long as the related access token is. Since the access
token is opaque to the client, one of the following methods MUST be
used to inform the client about the validity of an access token:
o The client knows a default validity period for all tokens it is
using. This information could be provisioned to the client when
it is registered at the AS, or published by the AS in a way that
the client can query.
o The AS informs the client about the token validity using the
"expires_in" parameter in the Access Information.
o The client performs an introspection of the token. Although this
is not explicitly forbidden, how exactly this is done is not
currently specified for OAuth.
A client that is not able to obtain information about the expiration
of a token MUST NOT use this token.
6. Security Considerations 6. Security Considerations
Security considerations applicable to authentication and Security considerations applicable to authentication and
authorization in RESTful environments provided in OAuth 2.0 [RFC6749] authorization in RESTful environments provided in OAuth 2.0 [RFC6749]
apply to this work. Furthermore [RFC6819] provides additional apply to this work. Furthermore [RFC6819] provides additional
security considerations for OAuth which apply to IoT deployments as security considerations for OAuth which apply to IoT deployments as
well. If the introspection endpoint is used, the security well. If the introspection endpoint is used, the security
considerations from [RFC7662] also apply. considerations from [RFC7662] also apply.
A large range of threats can be mitigated by protecting the contents A large range of threats can be mitigated by protecting the contents
skipping to change at page 43, line 15 skipping to change at page 43, line 48
memberships change. Furthermore issuing access tokens bound to memberships change. Furthermore issuing access tokens bound to
symmetric proof-of-possession keys that apply to a group-audience is symmetric proof-of-possession keys that apply to a group-audience is
problematic, as an RS that is in possession of the access token can problematic, as an RS that is in possession of the access token can
impersonate the client towards the other RSs that are part of the impersonate the client towards the other RSs that are part of the
group. It is therefore NOT RECOMMENDED to issue access tokens bound group. It is therefore NOT RECOMMENDED to issue access tokens bound
to a group audience and symmetric proof-of possession keys. to a group audience and symmetric proof-of possession keys.
Even the client must be able to determine the correct values to put Even the client must be able to determine the correct values to put
into the "audience" parameter, in order to obtain a token for the into the "audience" parameter, in order to obtain a token for the
intended RS. Errors in this process can lead to the client intended RS. Errors in this process can lead to the client
inadvertantly communicating with the wrong RS. The correct values inadvertently communicating with the wrong RS. The correct values
for "audience" can either be provisioned to the client as part of its for "audience" can either be provisioned to the client as part of its
configuration, or provided by the RS as part of the "AS Request configuration, or provided by the RS as part of the "AS Request
Creation Hints" Section 5.1.2 or dynamically looked up by the client Creation Hints" Section 5.1.2 or dynamically looked up by the client
in some directory. In the latter case the integrity and correctness in some directory. In the latter case the integrity and correctness
of the directory data must be assured. of the directory data must be assured.
6.7. Denial of service against or with Introspection 6.7. 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
skipping to change at page 54, line 15 skipping to change at page 54, line 47
[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-02 (work in progress), January 2019. params-04 (work in progress), February 2019.
[I-D.ietf-oauth-token-exchange] [I-D.ietf-oauth-token-exchange]
Jones, M., Nadalin, A., Campbell, B., Bradley, J., and C. Jones, M., Nadalin, A., Campbell, B., Bradley, J., and C.
Mortimore, "OAuth 2.0 Token Exchange", draft-ietf-oauth- Mortimore, "OAuth 2.0 Token Exchange", draft-ietf-oauth-
token-exchange-16 (work in progress), October 2018. token-exchange-16 (work in progress), October 2018.
[IANA.CborWebTokenClaims] [IANA.CborWebTokenClaims]
IANA, "CBOR Web Token (CWT) Claims", IANA, "CBOR Web Token (CWT) Claims",
<https://www.iana.org/assignments/cwt/ <https://www.iana.org/assignments/cwt/
cwt.xhtml#claims-registry>. cwt.xhtml#claims-registry>.
skipping to change at page 73, line 32 skipping to change at page 74, line 32
F: |<--------+ Header: 2.04 Changed F: |<--------+ Header: 2.04 Changed
| 2.04 | Payload: <new state for the lock> | 2.04 | Payload: <new state for the lock>
| | | |
Figure 26: Resource request and response protected by OSCORE Figure 26: Resource request and response protected by OSCORE
Appendix F. Document Updates Appendix F. Document Updates
RFC EDITOR: PLEASE REMOVE THIS SECTION. RFC EDITOR: PLEASE REMOVE THIS SECTION.
F.1. Verion -19 to 20 F.1. Verion -20 to 21
o Added text about expiration of RS keys.
F.2. Verion -19 to 20
o Replaced "req_aud" with "audience" from the OAuth token exchange o Replaced "req_aud" with "audience" from the OAuth token exchange
draft. draft.
o Updated examples to remove unnecessary elements. o Updated examples to remove unnecessary elements.
F.2. Version -18 to -19 F.3. Version -18 to -19
o Added definition of "Authorization Information". o Added definition of "Authorization Information".
o Explicitly state that ACE allows encoding refresh tokens in binary o Explicitly state that ACE allows encoding refresh tokens in binary
format in addition to strings. format in addition to strings.
o Renamed "AS Information" to "AS Request Creation Hints" and added o Renamed "AS Information" to "AS Request Creation Hints" and added
the possibility to specify req_aud and scope as hints. the possibility to specify req_aud and scope as hints.
o Added the "kid" parameter to AS Request Creation Hints. o Added the "kid" parameter to AS Request Creation Hints.
o Added security considerations about the integrity protection of o Added security considerations about the integrity protection of
tokens with multi-RS audiences. tokens with multi-RS audiences.
o Renamed IANA registries mapping OAuth parameters to reflect the o Renamed IANA registries mapping OAuth parameters to reflect the
mapped registry. mapped registry.
o Added JWT claim names to CWT claim registrations. o Added JWT claim names to CWT claim registrations.
o Added expert review instructions. o Added expert review instructions.
o Updated references to TLS from 1.2 to 1.3. o Updated references to TLS from 1.2 to 1.3.
F.3. Version -17 to -18 F.4. 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.4. Version -16 to -17 F.5. 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 74, line 35 skipping to change at page 75, line 41
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.5. Version -15 to -16 F.6. 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.6. Version -14 to -15 F.7. 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.7. Version -13 to -14 F.8. 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.8. Version -12 to -13 F.9. 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.9. Version -11 to -12 F.10. 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.10. Version -10 to -11 F.11. 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.11. Version -09 to -10 F.12. 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.12. Version -08 to -09 F.13. 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.13. Version -07 to -08 F.14. 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 76, line 40 skipping to change at page 77, line 45
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.14. Version -06 to -07 F.15. Version -06 to -07
o Various clarifications added. o Various clarifications added.
o Fixed erroneous author email. o Fixed erroneous author email.
F.15. Version -05 to -06 F.16. 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.16. Version -04 to -05 F.17. 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.17. Version -03 to -04 F.18. 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.18. Version -02 to -03 F.19. 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).
skipping to change at page 77, line 44 skipping to change at page 79, line 4
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.19. Version -01 to -02 F.20. 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.
skipping to change at page 78, line 17 skipping to change at page 79, line 25
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.20. Version -00 to -01 F.21. 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. 41 change blocks. 
78 lines changed or deleted 117 lines changed or added

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