draft-ietf-ace-oauth-authz-45.txt   draft-ietf-ace-oauth-authz-46.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: 2 March 2022 Ericsson Expires: 12 May 2022 Ericsson
E. Wahlstroem E. Wahlstroem
S. Erdtman S. Erdtman
Spotify AB Spotify AB
H. Tschofenig H. Tschofenig
Arm Ltd. Arm Ltd.
29 August 2021 8 November 2021
Authentication and Authorization for Constrained Environments (ACE) Authentication and Authorization for Constrained Environments (ACE)
using the OAuth 2.0 Framework (ACE-OAuth) using the OAuth 2.0 Framework (ACE-OAuth)
draft-ietf-ace-oauth-authz-45 draft-ietf-ace-oauth-authz-46
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 2 March 2022. This Internet-Draft will expire on 12 May 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 18, line 49 skipping to change at page 18, line 49
} }
Figure 3: AS Request Creation Hints payload example Figure 3: AS Request Creation Hints payload example
In the example above, the response parameter "AS" points the receiver In the example above, the response parameter "AS" points the receiver
of this message to the URI "coaps://as.example.com/token" to request of this message to the URI "coaps://as.example.com/token" to request
access tokens. The RS sending this response uses an internal clock access tokens. The RS sending this response uses an internal clock
that is not synchronized with the clock of the AS. Therefore, it can that is not synchronized with the clock of the AS. Therefore, it can
not reliably verify the expiration time of access tokens it receives. not reliably verify the expiration time of access tokens it receives.
To ensure a certain level of access token freshness nevertheless, the To ensure a certain level of access token freshness nevertheless, the
RS has included a "cnonce" parameter (see Section 5.3.1) in the RS has included a cnonce parameter (see Section 5.3.1) in the
response. (The hex-sequence of the cnonce parameter is encoded in response. (The hex-sequence of the cnonce parameter is encoded in
CBOR-based notation in this example.) CBOR-based notation in this example.)
Figure 4 illustrates the mandatory to use binary encoding of the Figure 4 illustrates the mandatory to use binary encoding of the
message payload shown in Figure 3. message payload shown in Figure 3.
a4 # map(4) a4 # map(4)
01 # unsigned(1) (=AS) 01 # unsigned(1) (=AS)
78 1c # text(28) 78 1c # text(28)
636f6170733a2f2f61732e657861 636f6170733a2f2f61732e657861
6d706c652e636f6d2f746f6b656e # "coaps://as.example.com/token" 6d706c652e636f6d2f746f6b656e # "coaps://as.example.com/token"
skipping to change at page 30, line 19 skipping to change at page 30, line 19
Clients that want the AS to provide them with the "ace_profile" Clients that want the AS to provide them with the "ace_profile"
parameter in the access token response can indicate that by sending a parameter in the access token response can indicate that by sending a
ace_profile parameter with a null value for CBOR-based interactions, ace_profile parameter with a null value for CBOR-based interactions,
or an empty string if CBOR is not used, in the access token request. or an empty string if CBOR is not used, in the access token request.
5.8.4.4. Client-Nonce 5.8.4.4. Client-Nonce
This parameter MUST be sent from the client to the AS, if it This parameter MUST be sent from the client to the AS, if it
previously received a "cnonce" parameter in the "AS Request Creation previously received a "cnonce" parameter in the "AS Request Creation
Hints" Section 5.3. The parameter is encoded as a byte string for Hints" Section 5.3. The parameter is encoded as a byte string for
CBOR-based interactions, and as a string (Base64 encoded binary) if CBOR-based interactions, and as a string (base64url without padding
CBOR is not used. It MUST copy the value from the cnonce parameter encoded binary [RFC4648]) if CBOR is not used. It MUST copy the
in the "AS Request Creation Hints". value from the cnonce parameter in the "AS Request Creation Hints".
5.8.5. Mapping Parameters to CBOR 5.8.5. Mapping Parameters to CBOR
If CBOR encoding is used, all OAuth parameters in access token If CBOR encoding is used, all OAuth parameters in access token
requests and responses MUST be mapped to CBOR types as specified in requests and responses MUST be mapped to CBOR types as specified in
the registry defined by Section 8.10, using the given integer the registry defined by Section 8.10, using the given integer
abbreviation for the map keys. abbreviation for the map keys.
Note that we have aligned the abbreviations corresponding to claims Note that we have aligned the abbreviations corresponding to claims
with the abbreviations defined in [RFC8392]. with the abbreviations defined in [RFC8392].
skipping to change at page 33, line 29 skipping to change at page 33, line 29
ace_profile OPTIONAL. This indicates the profile that the RS MUST ace_profile OPTIONAL. This indicates the profile that the RS MUST
use with the client. See Section 5.8.4.3 for more details on the use with the client. See Section 5.8.4.3 for more details on the
formatting of this parameter. If this parameter is absent, the AS formatting of this parameter. If this parameter is absent, the AS
assumes that the RS implicitly knows which profile to use towards assumes that the RS implicitly knows which profile to use towards
the client. the client.
cnonce OPTIONAL. A client-nonce provided to the AS by the client. cnonce OPTIONAL. A client-nonce provided to the AS by the client.
The RS MUST verify that this corresponds to the client-nonce The RS MUST verify that this corresponds to the client-nonce
previously provided to the client in the "AS Request Creation previously provided to the client in the "AS Request Creation
Hints". See Section 5.3 and Section 5.8.4.4. Hints". See Section 5.3 and Section 5.8.4.4. Its value is a byte
string when encoded in CBOR and the base64url encoding of this
byte string without padding when encoded in JSON [RFC4648].
cti OPTIONAL. The "cti" claim associated to this access token. cti OPTIONAL. The "cti" claim associated to this access token.
This parameter has the same meaning and processing rules as the This parameter has the same meaning and processing rules as the
"jti" parameter defined in section 3.1.2 of [RFC7662] except that "jti" parameter defined in section 3.1.2 of [RFC7662] except that
the value is a byte string. its value is a byte string when encoded in CBOR and the base64url
encoding of this byte string without padding when encoded in JSON
[RFC4648].
exi OPTIONAL. The "expires-in" claim associated to this access exi OPTIONAL. The "expires-in" claim associated to this access
token. See Section 5.10.3. token. See Section 5.10.3.
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"
skipping to change at page 51, line 33 skipping to change at page 51, line 33
This registry will be initially populated by the values in Figure 2. This registry will be initially populated by the values in Figure 2.
The Reference column for all of these entries will be this document. The Reference column for all of these entries will be this document.
8.2. CoRE Resource Type Registry 8.2. CoRE Resource Type Registry
IANA is requested to register a new Resource Type (rt=) Link Target IANA is requested to register a new Resource Type (rt=) Link Target
Attribute in the "Resource Type (rt=) Link Target Attribute Values" Attribute in the "Resource Type (rt=) Link Target Attribute Values"
subregistry under the "Constrained RESTful Environments (CoRE) subregistry under the "Constrained RESTful Environments (CoRE)
Parameters" [IANA.CoreParameters] registry: Parameters" [IANA.CoreParameters] registry:
* Value: "ace.ai" * Value: ace.ai
* Description: ACE-OAuth authz-info endpoint resource. * Description: ACE-OAuth authz-info endpoint resource.
* Reference: [this document] * Reference: [this document]
Specific ACE-OAuth profiles can use this common resource type for Specific ACE-OAuth profiles can use this common resource type for
defining their profile-specific discovery processes. defining their profile-specific discovery processes.
8.3. OAuth Extensions Error Registration 8.3. OAuth Extensions Error Registration
This specification registers the following error values in the OAuth This specification registers the following error values in the OAuth
Extensions Error registry [IANA.OAuthExtensionsErrorRegistry]. Extensions Error registry [IANA.OAuthExtensionsErrorRegistry].
* Error name: "unsupported_pop_key" * Error name: unsupported_pop_key
* Error usage location: token error response * Error usage location: token error response
* Related protocol extension: [this document] * Related protocol extension: [this document]
* Change Controller: IETF * Change Controller: IETF
* Specification document(s): Section 5.8.3 of [this document] * Specification document(s): Section 5.8.3 of [this document]
* Error name: "incompatible_ace_profiles" * Error name: incompatible_ace_profiles
* Error usage location: token error response * Error usage location: token error response
* Related protocol extension: [this document] * Related protocol extension: [this document]
* Change Controller: IETF * Change Controller: IETF
* Specification document(s): Section 5.8.3 of [this document] * Specification document(s): Section 5.8.3 of [this document]
8.4. OAuth Error Code CBOR Mappings Registry 8.4. OAuth Error Code CBOR Mappings Registry
This specification establishes the IANA "OAuth Error Code CBOR This specification establishes the IANA "OAuth Error Code CBOR
Mappings" registry. The registry has been created to use the "Expert Mappings" registry. The registry has been created to use the "Expert
Review" registration procedure [RFC8126], except for the value range Review" registration procedure [RFC8126], except for the value range
skipping to change at page 53, line 10 skipping to change at page 53, line 10
specification of the grant type, if one exists. specification of the grant type, if one exists.
This registry will be initially populated by the values in Figure 11. This registry will be initially populated by the values in Figure 11.
The Reference column for all of these entries will be this document. The Reference column for all of these entries will be this document.
8.6. OAuth Access Token Types 8.6. OAuth Access Token Types
This section registers the following new token type in the "OAuth This section registers the following new token type in the "OAuth
Access Token Types" registry [IANA.OAuthAccessTokenTypes]. Access Token Types" registry [IANA.OAuthAccessTokenTypes].
* Type name: "PoP" * Type name: PoP
* Additional Token Endpoint Response Parameters: "cnf", "rs_cnf" see * Additional Token Endpoint Response Parameters: "cnf", "rs_cnf" see
section 3.1 of [RFC8747] and section 3.1 of section 3.1 of [RFC8747] and section 3.1 of
[I-D.ietf-ace-oauth-params]. [I-D.ietf-ace-oauth-params].
* HTTP Authentication Scheme(s): N/A * HTTP Authentication Scheme(s): N/A
* Change Controller: IETF * Change Controller: IETF
* Specification document(s): [this document] * Specification document(s): [this document]
8.7. OAuth Access Token Type CBOR Mappings 8.7. OAuth Access Token Type CBOR Mappings
This specification established the IANA "OAuth Access Token Type CBOR This specification established the IANA "OAuth Access Token Type CBOR
skipping to change at page 53, line 39 skipping to change at page 53, line 39
CBOR Value CBOR abbreviation for this token type. Integer values CBOR Value CBOR abbreviation for this token type. Integer values
less than -65536 are marked as "Private Use", all other values use less than -65536 are marked as "Private Use", all other values use
the registration policy "Expert Review" [RFC8126]. the registration policy "Expert Review" [RFC8126].
Reference This contains a pointer to the public specification of the Reference This contains a pointer to the public specification of the
OAuth token type abbreviation, if one exists. OAuth token type abbreviation, if one exists.
Original Specification This contains a pointer to the public Original Specification This contains a pointer to the public
specification of the OAuth token type, if one exists. specification of the OAuth token type, if one exists.
8.7.1. Initial Registry Contents 8.7.1. Initial Registry Contents
* Name: "Bearer" * Name: Bearer
* Value: 1 * Value: 1
* Reference: [this document] * Reference: [this document]
* Original Specification: [RFC6749] * Original Specification: [RFC6749]
* Name: "PoP" * Name: PoP
* Value: 2 * Value: 2
* Reference: [this document] * Reference: [this document]
* Original Specification: [this document] * Original Specification: [this document]
8.8. ACE Profile Registry 8.8. ACE Profile Registry
This specification establishes the IANA "ACE Profile" registry. The This specification establishes the IANA "ACE Profile" registry. The
registry has been created to use the "Expert Review" registration registry has been created to use the "Expert Review" registration
procedure [RFC8126]. It should be noted that, in addition to the procedure [RFC8126]. It should be noted that, in addition to the
expert review, some portions of the registry require a specification, expert review, some portions of the registry require a specification,
skipping to change at page 54, line 37 skipping to change at page 54, line 37
profile abbreviation, if one exists. profile abbreviation, if one exists.
This registry will be initially empty and will be populated by the This registry will be initially empty and will be populated by the
registrations from the ACE framework profiles. registrations from the ACE framework profiles.
8.9. OAuth Parameter Registration 8.9. OAuth Parameter Registration
This specification registers the following parameter in the "OAuth This specification registers the following parameter in the "OAuth
Parameters" registry [IANA.OAuthParameters]: Parameters" registry [IANA.OAuthParameters]:
* Name: "ace_profile" * Name: ace_profile
* Parameter Usage Location: token response * Parameter Usage Location: token response
* Change Controller: IETF * Change Controller: IETF
* Reference: Section 5.8.2 and Section 5.8.4.3 of [this document] * Reference: Section 5.8.2 and Section 5.8.4.3 of [this document]
8.10. OAuth Parameters CBOR Mappings Registry 8.10. OAuth Parameters CBOR Mappings Registry
This specification establishes the IANA "OAuth Parameters CBOR This specification establishes the IANA "OAuth Parameters CBOR
Mappings" registry. The registry has been created to use the "Expert Mappings" registry. The registry has been created to use the "Expert
Review" registration procedure [RFC8126], except for the value range Review" registration procedure [RFC8126], except for the value range
designated for private use. designated for private use.
skipping to change at page 55, line 24 skipping to change at page 55, line 24
This registry will be initially populated by the values in Figure 12. This registry will be initially populated by the values in Figure 12.
The Reference column for all of these entries will be this document. The Reference column for all of these entries will be this document.
8.11. OAuth Introspection Response Parameter Registration 8.11. OAuth Introspection Response Parameter Registration
This specification registers the following parameters in the OAuth This specification registers the following parameters in the OAuth
Token Introspection Response registry Token Introspection Response registry
[IANA.TokenIntrospectionResponse]. [IANA.TokenIntrospectionResponse].
* Name: "ace_profile" * Name: ace_profile
* Description: The ACE profile used between client and RS. * Description: The ACE profile used between client and RS.
* Change Controller: IETF * Change Controller: IETF
* Reference: Section 5.9.2 of [this document] * Reference: Section 5.9.2 of [this document]
* Name: "cnonce" * Name: cnonce
* Description: "client-nonce". A nonce previously provided to the * Description: "client-nonce". A nonce previously provided to the
AS by the RS via the client. Used to verify token freshness when AS by the RS via the client. Used to verify token freshness when
the RS cannot synchronize its clock with the AS. the RS cannot synchronize its clock with the AS.
* Change Controller: IETF * Change Controller: IETF
* Reference: Section 5.9.2 of [this document] * Reference: Section 5.9.2 of [this document]
* Name: "cti" * Name: cti
* Description: "CWT ID". The identifier of a CWT as defined in * Description: "CWT ID". The identifier of a CWT as defined in
[RFC8392]. [RFC8392].
* Change Controller: IETF * Change Controller: IETF
* Reference: Section 5.9.2 of [this document] * Reference: Section 5.9.2 of [this document]
* Name: "exi" * Name: exi
* Description: "Expires in". Lifetime of the token in seconds from * Description: "Expires in". Lifetime of the token in seconds from
the time the RS first sees it. Used to implement a weaker from of the time the RS first sees it. Used to implement a weaker from of
token expiration for devices that cannot synchronize their token expiration for devices that cannot synchronize their
internal clocks. internal clocks.
* Change Controller: IETF * Change Controller: IETF
* Reference: Section 5.9.2 of [this document] * Reference: Section 5.9.2 of [this document]
8.12. OAuth Token Introspection Response CBOR Mappings Registry 8.12. OAuth Token Introspection Response CBOR Mappings Registry
This specification establishes the IANA "OAuth Token Introspection This specification establishes the IANA "OAuth Token Introspection
skipping to change at page 56, line 40 skipping to change at page 56, line 40
Note that the mappings of parameters corresponding to claim names Note that the mappings of parameters corresponding to claim names
intentionally coincide with the CWT claim name mappings from intentionally coincide with the CWT claim name mappings from
[RFC8392]. [RFC8392].
8.13. JSON Web Token Claims 8.13. JSON Web Token Claims
This specification registers the following new claims in the JSON Web This specification registers the following new claims in the JSON Web
Token (JWT) registry of JSON Web Token Claims Token (JWT) registry of JSON Web Token Claims
[IANA.JsonWebTokenClaims]: [IANA.JsonWebTokenClaims]:
* Claim Name: "ace_profile" * Claim Name: ace_profile
* Claim Description: The ACE profile a token is supposed to be used * Claim Description: The ACE profile a token is supposed to be used
with. with.
* Change Controller: IETF * Change Controller: IETF
* Reference: Section 5.10 of [this document] * Reference: Section 5.10 of [this document]
* Claim Name: "cnonce" * Claim Name: cnonce
* Claim Description: "client-nonce". A nonce previously provided to * Claim Description: "client-nonce". A nonce previously provided to
the AS by the RS via the client. Used to verify token freshness the AS by the RS via the client. Used to verify token freshness
when the RS cannot synchronize its clock with the AS. when the RS cannot synchronize its clock with the AS.
* Change Controller: IETF * Change Controller: IETF
* Reference: Section 5.10 of [this document] * Reference: Section 5.10 of [this document]
* Claim Name: "exi" * Claim Name: exi
* Claim Description: "Expires in". Lifetime of the token in seconds * Claim Description: "Expires in". Lifetime of the token in seconds
from the time the RS first sees it. Used to implement a weaker from the time the RS first sees it. Used to implement a weaker
from of token expiration for devices that cannot synchronize their from of token expiration for devices that cannot synchronize their
internal clocks. internal clocks.
* Change Controller: IETF * Change Controller: IETF
* Reference: Section 5.10.3 of [this document] * Reference: Section 5.10.3 of [this document]
8.14. CBOR Web Token Claims 8.14. CBOR Web Token Claims
This specification registers the following new claims in the "CBOR This specification registers the following new claims in the "CBOR
Web Token (CWT) Claims" registry [IANA.CborWebTokenClaims]. Web Token (CWT) Claims" registry [IANA.CborWebTokenClaims].
* Claim Name: "ace_profile" * Claim Name: ace_profile
* Claim Description: The ACE profile a token is supposed to be used * Claim Description: The ACE profile a token is supposed to be used
with. with.
* JWT Claim Name: ace_profile * JWT Claim Name: ace_profile
* Claim Key: TBD (suggested: 38) * Claim Key: TBD (suggested: 38)
* Claim Value Type(s): integer * Claim Value Type(s): integer
* Change Controller: IETF * Change Controller: IETF
* Specification Document(s): Section 5.10 of [this document] * Specification Document(s): Section 5.10 of [this document]
* Claim Name: "cnonce" * Claim Name: cnonce
* Claim Description: The client-nonce sent to the AS by the RS via * Claim Description: The client-nonce sent to the AS by the RS via
the client. the client.
* JWT Claim Name: cnonce * JWT Claim Name: cnonce
* Claim Key: TBD (suggested: 39) * Claim Key: TBD (suggested: 39)
* Claim Value Type(s): byte string * Claim Value Type(s): byte string
* Change Controller: IETF * Change Controller: IETF
* Specification Document(s): Section 5.10 of [this document] * Specification Document(s): Section 5.10 of [this document]
* Claim Name: "exi" * Claim Name: exi
* Claim Description: The expiration time of a token measured from * 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.
* JWT Claim Name: exi * JWT Claim Name: exi
* Claim Key: TBD (suggested: 40) * Claim Key: TBD (suggested: 40)
* Claim Value Type(s): integer * Claim Value Type(s): integer
* Change Controller: IETF * Change Controller: IETF
* Specification Document(s): Section 5.10.3 of [this document] * Specification Document(s): Section 5.10.3 of [this document]
* Claim Name: "scope" * Claim Name: scope
* Claim Description: The scope of an access token as defined in * Claim Description: The scope of an access token as defined in
[RFC6749]. [RFC6749].
* JWT Claim Name: scope * JWT Claim Name: scope
* Claim Key: TBD (suggested: 9) * Claim Key: TBD (suggested: 9)
* Claim Value Type(s): byte string or text string * Claim Value Type(s): byte string or text string
* Change Controller: IETF * Change Controller: IETF
* Specification Document(s): Section 4.2 of [RFC8693] * Specification Document(s): Section 4.2 of [RFC8693]
8.15. Media Type Registrations 8.15. Media Type Registrations
skipping to change at page 60, line 46 skipping to change at page 60, line 46
Seitz was also received further funding for this work by Vinnova in Seitz was also received further funding for this work by Vinnova in
the context of the CelticNext project Critisec. the context of the CelticNext project Critisec.
10. References 10. References
10.1. Normative References 10.1. Normative References
[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)", Work in Progress, in Constrained Environments (ACE)", Work in Progress,
Internet-Draft, draft-ietf-ace-oauth-params-15, 6 May Internet-Draft, draft-ietf-ace-oauth-params-16, 7
2021, <https://www.ietf.org/archive/id/draft-ietf-ace- September 2021, <https://www.ietf.org/archive/id/draft-
oauth-params-15.txt>. ietf-ace-oauth-params-16.txt>.
[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.CoreParameters] [IANA.CoreParameters]
IANA, "Constrained RESTful Environments (CoRE) IANA, "Constrained RESTful Environments (CoRE)
Parameters", <https://www.iana.org/assignments/core- Parameters", <https://www.iana.org/assignments/core-
parameters/core-parameters.xhtml>. parameters/core-parameters.xhtml>.
skipping to change at page 61, line 49 skipping to change at page 61, line 49
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012, RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>. <https://www.rfc-editor.org/info/rfc6749>.
[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
Framework: Bearer Token Usage", RFC 6750, Framework: Bearer Token Usage", RFC 6750,
 End of changes. 28 change blocks. 
31 lines changed or deleted 39 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/