draft-ietf-ace-oauth-authz-30.txt   draft-ietf-ace-oauth-authz-31.txt 
ACE Working Group L. Seitz ACE Working Group L. Seitz
Internet-Draft Combitech Internet-Draft Combitech
Intended status: Standards Track G. Selander Intended status: Standards Track G. Selander
Expires: July 14, 2020 Ericsson Expires: July 21, 2020 Ericsson
E. Wahlstroem E. Wahlstroem
S. Erdtman S. Erdtman
Spotify AB Spotify AB
H. Tschofenig H. Tschofenig
Arm Ltd. Arm Ltd.
January 11, 2020 January 18, 2020
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-30 draft-ietf-ace-oauth-authz-31
Abstract Abstract
This specification defines a framework for authentication and This specification defines a framework for authentication and
authorization in Internet of Things (IoT) environments called ACE- authorization in Internet of Things (IoT) environments called ACE-
OAuth. The framework is based on a set of building blocks including OAuth. The framework is based on a set of building blocks including
OAuth 2.0 and the Constrained Application Protocol (CoAP), thus OAuth 2.0 and the Constrained Application Protocol (CoAP), thus
transforming a well-known and widely used authorization solution into transforming a well-known and widely used authorization solution into
a form suitable for IoT devices. Existing specifications are used a form suitable for IoT devices. Existing specifications are used
where possible, but extensions are added and profiles are defined to where possible, but extensions are added and profiles are defined to
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 14, 2020. This Internet-Draft will expire on July 21, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 14 skipping to change at page 3, line 14
5.8.1. The Authorization Information Endpoint . . . . . . . 36 5.8.1. The Authorization Information Endpoint . . . . . . . 36
5.8.1.1. Verifying an Access Token . . . . . . . . . . . . 37 5.8.1.1. Verifying an Access Token . . . . . . . . . . . . 37
5.8.1.2. Protecting the Authorization Information 5.8.1.2. Protecting the Authorization Information
Endpoint . . . . . . . . . . . . . . . . . . . . 39 Endpoint . . . . . . . . . . . . . . . . . . . . 39
5.8.2. Client Requests to the RS . . . . . . . . . . . . . . 39 5.8.2. Client Requests to the RS . . . . . . . . . . . . . . 39
5.8.3. Token Expiration . . . . . . . . . . . . . . . . . . 40 5.8.3. Token Expiration . . . . . . . . . . . . . . . . . . 40
5.8.4. Key Expiration . . . . . . . . . . . . . . . . . . . 41 5.8.4. Key Expiration . . . . . . . . . . . . . . . . . . . 41
6. Security Considerations . . . . . . . . . . . . . . . . . . . 42 6. Security Considerations . . . . . . . . . . . . . . . . . . . 42
6.1. Protecting Tokens . . . . . . . . . . . . . . . . . . . . 42 6.1. Protecting Tokens . . . . . . . . . . . . . . . . . . . . 42
6.2. Communication Security . . . . . . . . . . . . . . . . . 43 6.2. Communication Security . . . . . . . . . . . . . . . . . 43
6.3. Long-Term Credentials . . . . . . . . . . . . . . . . . . 43 6.3. Long-Term Credentials . . . . . . . . . . . . . . . . . . 44
6.4. Unprotected AS Request Creation Hints . . . . . . . . . . 44 6.4. Unprotected AS Request Creation Hints . . . . . . . . . . 44
6.5. Minimal security requirements for communication . 45 6.5. Minimal security requirements for communication . 45
6.6. Token Freshness and Expiration . . . . . . . . . . . . . 46 6.6. Token Freshness and Expiration . . . . . . . . . . . . . 46
6.7. Combining profiles . . . . . . . . . . . . . . . . . . . 47 6.7. Combining profiles . . . . . . . . . . . . . . . . . . . 47
6.8. Unprotected Information . . . . . . . . . . . . . . . . . 47 6.8. Unprotected Information . . . . . . . . . . . . . . . . . 47
6.9. Identifying audiences . . . . . . . . . . . . . . . . . . 48 6.9. Identifying audiences . . . . . . . . . . . . . . . . . . 48
6.10. Denial of service against or with Introspection . . 48 6.10. Denial of service against or with Introspection . . 48
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 49 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 49
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50
8.1. ACE Authorization Server Request Creation Hints . . . . . 50 8.1. ACE Authorization Server Request Creation Hints . . . . . 50
skipping to change at page 3, line 46 skipping to change at page 3, line 46
8.12. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 55 8.12. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 55
8.13. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 55 8.13. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 55
8.14. Media Type Registrations . . . . . . . . . . . . . . . . 56 8.14. Media Type Registrations . . . . . . . . . . . . . . . . 56
8.15. CoAP Content-Format Registry . . . . . . . . . . . . . . 57 8.15. CoAP Content-Format Registry . . . . . . . . . . . . . . 57
8.16. Expert Review Instructions . . . . . . . . . . . . . . . 57 8.16. Expert Review Instructions . . . . . . . . . . . . . . . 57
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 58 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 58
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 59 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 59
10.1. Normative References . . . . . . . . . . . . . . . . . . 59 10.1. Normative References . . . . . . . . . . . . . . . . . . 59
10.2. Informative References . . . . . . . . . . . . . . . . . 61 10.2. Informative References . . . . . . . . . . . . . . . . . 61
Appendix A. Design Justification . . . . . . . . . . . . . . . . 64 Appendix A. Design Justification . . . . . . . . . . . . . . . . 64
Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 68 Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 67
Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 70 Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 70
Appendix D. Assumptions on AS knowledge about C and RS . . . . . 71 Appendix D. Assumptions on AS knowledge about C and RS . . . . . 71
Appendix E. Deployment Examples . . . . . . . . . . . . . . . . 71 Appendix E. Deployment Examples . . . . . . . . . . . . . . . . 71
E.1. Local Token Validation . . . . . . . . . . . . . . . . . 72 E.1. Local Token Validation . . . . . . . . . . . . . . . . . 71
E.2. Introspection Aided Token Validation . . . . . . . . . . 76 E.2. Introspection Aided Token Validation . . . . . . . . . . 76
Appendix F. Document Updates . . . . . . . . . . . . . . . . . . 80 Appendix F. Document Updates . . . . . . . . . . . . . . . . . . 80
F.1. Version -21 to 22 . . . . . . . . . . . . . . . . . . . . 81 F.1. Version -21 to 22 . . . . . . . . . . . . . . . . . . . . 81
F.2. Version -20 to 21 . . . . . . . . . . . . . . . . . . . . 81 F.2. Version -20 to 21 . . . . . . . . . . . . . . . . . . . . 81
F.3. Version -19 to 20 . . . . . . . . . . . . . . . . . . . . 81 F.3. Version -19 to 20 . . . . . . . . . . . . . . . . . . . . 81
F.4. Version -18 to -19 . . . . . . . . . . . . . . . . . . . 81 F.4. Version -18 to -19 . . . . . . . . . . . . . . . . . . . 81
F.5. Version -17 to -18 . . . . . . . . . . . . . . . . . . . 81 F.5. Version -17 to -18 . . . . . . . . . . . . . . . . . . . 81
F.6. Version -16 to -17 . . . . . . . . . . . . . . . . . . . 81 F.6. Version -16 to -17 . . . . . . . . . . . . . . . . . . . 81
F.7. Version -15 to -16 . . . . . . . . . . . . . . . . . . . 82 F.7. Version -15 to -16 . . . . . . . . . . . . . . . . . . . 82
skipping to change at page 22, line 37 skipping to change at page 22, line 37
profile MUST specify how the communication is protected. The content profile MUST specify how the communication is protected. The content
of the request consists of the parameters specified in the relevant of the request consists of the parameters specified in the relevant
subsection of section 4 of the OAuth 2.0 specification [RFC6749], subsection of section 4 of the OAuth 2.0 specification [RFC6749],
depending on the grant type, with the following exceptions and depending on the grant type, with the following exceptions and
additions: additions:
o The parameter "grant_type" is OPTIONAL in the context of this o The parameter "grant_type" is OPTIONAL in the context of this
framework (as opposed to REQUIRED in RFC6749). If that parameter framework (as opposed to REQUIRED in RFC6749). If that parameter
is missing, the default value "client_credentials" is implied. is missing, the default value "client_credentials" is implied.
o The "audience" parameter from [I-D.ietf-oauth-token-exchange] is o The "audience" parameter from [RFC8693] is OPTIONAL to request an
OPTIONAL to request an access token bound to a specific audience. access token bound to a specific audience.
o The "cnonce" parameter defined in Section 5.6.4.4 is REQUIRED if o The "cnonce" parameter defined in Section 5.6.4.4 is REQUIRED if
the RS provided a client-nonce in the "AS Request Creation Hints" the RS provided a client-nonce in the "AS Request Creation Hints"
message Section 5.1.2 message Section 5.1.2
o The "scope" parameter MAY be encoded as a byte string instead of o The "scope" parameter MAY be encoded as a byte string instead of
the string encoding specified in section 3.3 of [RFC6749], in the string encoding specified in section 3.3 of [RFC6749], in
order allow compact encoding of complex scopes. The syntax of order allow compact encoding of complex scopes. The syntax of
such a binary encoding is explicitly not specified here and left such a binary encoding is explicitly not specified here and left
to profiles or applications, specifically note that a binary to profiles or applications, specifically note that a binary
skipping to change at page 36, line 8 skipping to change at page 36, line 8
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
document uses the "cnf" claim from document uses the "cnf" claim from
[I-D.ietf-ace-cwt-proof-of-possession] and the "scope" claim from [I-D.ietf-ace-cwt-proof-of-possession] and the "scope" claim from
[I-D.ietf-oauth-token-exchange] for JWT- and CWT-encoded tokens. In [RFC8693] for JWT- and CWT-encoded tokens. In addition to string
addition to string encoding specified for the "scope" claim, a binary encoding specified for the "scope" claim, a binary encoding MAY be
encoding MAY be used. The syntax of such an encoding is explicitly used. The syntax of such an encoding is explicitly not specified
not specified here and left to profiles or applications, specifically here and left to profiles or applications, specifically note that a
note that a binary encoded scope does not necessarily use the space binary encoded scope does not necessarily use the space character
character '0x20' to delimit scope-tokens. '0x20' to delimit scope-tokens.
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 an should use to communicate with the client, the AS MAY include an
"ace_profile" claim in the access token, with the same syntax and "ace_profile" claim in the access token, with the same syntax and
semantics as defined in Section 5.6.4.3. semantics as defined in Section 5.6.4.3.
If the client submitted a client-nonce parameter in the access token If the client submitted a client-nonce parameter in the access token
request Section 5.6.4.4, the AS MUST include the value of this request Section 5.6.4.4, the AS MUST include the value of this
parameter in the "cnonce" claim specified here. The "cnonce" claim parameter in the "cnonce" claim specified here. The "cnonce" claim
uses binary encoding. uses binary encoding.
skipping to change at page 41, line 22 skipping to change at page 41, line 22
JSON number. JSON number.
o Processing this claim requires that the RS does the following: o Processing this claim requires that the RS does the following:
* For each token the RS receives, that contains an "exi" claim: * For each token the RS receives, that contains an "exi" claim:
Keep track of the time it received that token and revisit that Keep track of the time it received that token and revisit that
list regularly to expunge expired tokens. list regularly to expunge expired tokens.
* Keep track of the identifiers of tokens containing the "exi" * Keep track of the identifiers of tokens containing the "exi"
claim that have expired (in order to avoid accepting them claim that have expired (in order to avoid accepting them
again). again). In order to avoid an unbounded memory usage growth,
this MUST be implemented in the following way when the "exi"
claim is used:
+ When creating the token, the AS MUST add a 'cti' claim ( or
'jti' for JWTs) to the access token. The value of this
claim MUST be created as the binary representation of the
concatenation of the identifier of the RS with a sequence
number counting the tokens containing an 'exi' claim, issued
by this AS for the RS.
+ The RS MUST store the highest sequence number of an expired
token containing the "exi" claim that it has seen, and treat
tokens with lower sequence numbers as expired.
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 Expiration 5.8.4. Key Expiration
The AS provides the client with key material that the RS uses. This The AS provides the client with key material that the RS uses. This
can either be a common symmetric PoP-key, or an asymmetric key used can either be a common symmetric PoP-key, or an asymmetric key used
skipping to change at page 46, line 35 skipping to change at page 46, line 47
predictable alternative. The "exi" approach has some drawbacks that predictable alternative. The "exi" approach has some drawbacks that
need to be considered: need to be considered:
A malicious client may hold back tokens with the "exi" claim in A malicious client may hold back tokens with the "exi" claim in
order to prolong their lifespan. order to prolong their lifespan.
If an RS loses state (e.g. due to an unscheduled reboot), it may If an RS loses state (e.g. due to an unscheduled reboot), it may
loose the current values of counters tracking the "exi" claims of loose the current values of counters tracking the "exi" claims of
tokens it is storing. tokens it is storing.
The RS needs to keep state about expired tokens that used "exi" in
order to be sure not to accept it again. Attacker may use this to
deplete the RS's storage resources.
The first drawback is inherent to the deployment scenario and the The first drawback is inherent to the deployment scenario and the
"exi" solution. It can therefore not be mitigated without requiring "exi" solution. It can therefore not be mitigated without requiring
the the RS be online at times. The second drawback can be mitigated the the RS be online at times. The second drawback can be mitigated
by regularly storing the value of "exi" counters to persistent by regularly storing the value of "exi" counters to persistent
memory. The third problem can be mitigated by the AS, by assigning memory.
identifiers (e.g. 'cti') to the tokens, that include an RS identifier
and a sequence number. The RS would then just have to store the
highest sequence number of an expired token it has seen, thus
limiting the necessary state.
6.7. Combining profiles 6.7. Combining profiles
There may be use cases were different profiles of this framework are There may be use cases were different profiles of this framework are
combined. For example, an MQTT-TLS profile is used between the combined. For example, an MQTT-TLS profile is used between the
client and the RS in combination with a CoAP-DTLS profile for client and the RS in combination with a CoAP-DTLS profile for
interactions between the client and the AS. The security of a interactions between the client and the AS. The security of a
profile MUST NOT depend on the assumption that the profile is used profile MUST NOT depend on the assumption that the profile is used
for all the different types of interactions in this framework. for all the different types of interactions in this framework.
skipping to change at page 48, line 8 skipping to change at page 48, line 8
obsolete profile that in turn specifies a vulnerable security obsolete profile that in turn specifies a vulnerable security
mechanism via the authz-info endpoint. Such an attack would require mechanism via the authz-info endpoint. Such an attack would require
a valid access token containing an "ace_profile" claim requesting the a valid access token containing an "ace_profile" claim requesting the
use of said obsolete profile. Resource Owners should update the use of said obsolete profile. Resource Owners should update the
configuration of their RS's to prevent them from using such obsolete configuration of their RS's to prevent them from using such obsolete
profiles. profiles.
6.9. Identifying audiences 6.9. Identifying audiences
The audience claim as defined in [RFC7519] and the equivalent The audience claim as defined in [RFC7519] and the equivalent
"audience" parameter from [I-D.ietf-oauth-token-exchange] are "audience" parameter from [RFC8693] are intentionally vague on how to
intentionally vague on how to match the audience value to a specific match the audience value to a specific RS. This is intended to allow
RS. This is intended to allow application specific semantics to be application specific semantics to be used. This section attempts to
used. This section attempts to give some general guidance for the give some general guidance for the use of audiences in constrained
use of audiences in constrained environments. environments.
URLs are not a good way of identifying mobile devices that can switch URLs are not a good way of identifying mobile devices that can switch
networks and thus be associated with new URLs. If the audience networks and thus be associated with new URLs. If the audience
represents a single RS, and asymmetric keys are used, the RS can be represents a single RS, and asymmetric keys are used, the RS can be
uniquely identified by a hash of its public key. If this approach is uniquely identified by a hash of its public key. If this approach is
used this framework RECOMMENDS to apply the procedure from section 3 used this framework RECOMMENDS to apply the procedure from section 3
of [RFC6920]. of [RFC6920].
If the audience addresses a group of resource servers, the mapping of If the audience addresses a group of resource servers, the mapping of
group identifier to individual RS has to be provisioned to each RS group identifier to individual RS has to be provisioned to each RS
skipping to change at page 55, line 48 skipping to change at page 55, line 48
This specification registers the following new claims in the "CBOR This specification registers the following new claims in the "CBOR
Web Token (CWT) Claims" registry [IANA.CborWebTokenClaims]. Web Token (CWT) Claims" registry [IANA.CborWebTokenClaims].
o Claim Name: "scope" o Claim Name: "scope"
o Claim Description: The scope of an access token as defined in o Claim Description: The scope of an access token as defined in
[RFC6749]. [RFC6749].
o JWT Claim Name: scope o JWT Claim Name: scope
o Claim Key: TBD (suggested: 9) o Claim Key: TBD (suggested: 9)
o Claim Value Type(s): byte string or text string o Claim Value Type(s): byte string or text string
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 4.2 of o Specification Document(s): Section 4.2 of [RFC8693]
[I-D.ietf-oauth-token-exchange]
o Claim Name: "ace_profile" o Claim Name: "ace_profile"
o Claim Description: The ACE profile a token is supposed to be used o Claim Description: The ACE profile a token is supposed to be used
with. with.
o JWT Claim Name: ace_profile o JWT Claim Name: ace_profile
o Claim Key: TBD (suggested: 38) o Claim Key: TBD (suggested: 38)
o Claim Value Type(s): integer o Claim Value Type(s): integer
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 5.8 of [this document] o Specification Document(s): Section 5.8 of [this document]
o Claim Name: "exi" o Claim Name: "exi"
o Claim Description: The expiration time of a token measured from o Claim Description: The expiration time of a token measured from
when it was received at the RS in seconds. when it was received at the RS in seconds.
o JWT Claim Name: exi o JWT Claim Name: exi
skipping to change at page 57, line 4 skipping to change at page 56, line 50
Required parameters: none Required parameters: none
Optional parameters: none Optional parameters: none
Encoding considerations: Must be encoded as CBOR map containing the Encoding considerations: Must be encoded as CBOR map containing the
protocol parameters defined in [this document]. protocol parameters defined in [this document].
Security considerations: See Section 6 of this document. Security considerations: See Section 6 of this document.
Interoperability considerations: n/a Interoperability considerations: n/a
Published specification: [this document]
Published specification: [this document]
Applications that use this media type: The type is used by Applications that use this media type: The type is used by
authorization servers, clients and resource servers that support the authorization servers, clients and resource servers that support the
ACE framework as specified in [this document]. ACE framework as specified in [this document].
Additional information: Additional information:
Magic number(s): n/a Magic number(s): n/a
File extension(s): .ace File extension(s): .ace
skipping to change at page 59, line 25 skipping to change at page 59, line 23
[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-11 (work in progress), October 2019. possession-11 (work in progress), October 2019.
[I-D.ietf-ace-oauth-params] [I-D.ietf-ace-oauth-params]
Seitz, L., "Additional OAuth Parameters for Authorization Seitz, L., "Additional OAuth Parameters for Authorization
in Constrained Environments (ACE)", draft-ietf-ace-oauth- in Constrained Environments (ACE)", draft-ietf-ace-oauth-
params-10 (work in progress), January 2020. params-11 (work in progress), January 2020.
[I-D.ietf-oauth-token-exchange]
Jones, M., Nadalin, A., Campbell, B., Bradley, J., and C.
Mortimore, "OAuth 2.0 Token Exchange", draft-ietf-oauth-
token-exchange-19 (work in progress), July 2019.
[IANA.CborWebTokenClaims] [IANA.CborWebTokenClaims]
IANA, "CBOR Web Token (CWT) Claims", IANA, "CBOR Web Token (CWT) Claims",
<https://www.iana.org/assignments/cwt/cwt.xhtml#claims- <https://www.iana.org/assignments/cwt/cwt.xhtml#claims-
registry>. registry>.
[IANA.JsonWebTokenClaims] [IANA.JsonWebTokenClaims]
IANA, "JSON Web Token Claims", IANA, "JSON Web Token Claims",
<https://www.iana.org/assignments/jwt/jwt.xhtml#claims>. <https://www.iana.org/assignments/jwt/jwt.xhtml#claims>.
skipping to change at page 61, line 39 skipping to change at page 61, line 30
<https://www.rfc-editor.org/info/rfc8152>. <https://www.rfc-editor.org/info/rfc8152>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
May 2018, <https://www.rfc-editor.org/info/rfc8392>. May 2018, <https://www.rfc-editor.org/info/rfc8392>.
[RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J.,
and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693,
DOI 10.17487/RFC8693, January 2020,
<https://www.rfc-editor.org/info/rfc8693>.
10.2. Informative References 10.2. Informative References
[BLE] Bluetooth SIG, "Bluetooth Core Specification v5.1", [BLE] Bluetooth SIG, "Bluetooth Core Specification v5.1",
Section 4.4, January 2019, Section 4.4, January 2019,
<https://www.bluetooth.com/specifications/bluetooth-core- <https://www.bluetooth.com/specifications/bluetooth-core-
specification/>. specification/>.
[I-D.erdtman-ace-rpcc] [I-D.erdtman-ace-rpcc]
Seitz, L. and S. Erdtman, "Raw-Public-Key and Pre-Shared- Seitz, L. and S. Erdtman, "Raw-Public-Key and Pre-Shared-
Key as OAuth client credentials", draft-erdtman-ace- Key as OAuth client credentials", draft-erdtman-ace-
 End of changes. 19 change blocks. 
39 lines changed or deleted 44 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/