draft-ietf-oauth-jwsreq-21.txt   draft-ietf-oauth-jwsreq-22.txt 
OAuth Working Group N. Sakimura OAuth Working Group N. Sakimura
Internet-Draft Nomura Research Institute Internet-Draft NAT.Consulting
Intended status: Standards Track J. Bradley Intended status: Standards Track J. Bradley
Expires: October 20, 2020 Yubico Expires: November 8, 2020 Yubico
April 18, 2020 May 07, 2020
The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request
(JAR) (JAR)
draft-ietf-oauth-jwsreq-21 draft-ietf-oauth-jwsreq-22
Abstract Abstract
The authorization request in OAuth 2.0 described in RFC 6749 utilizes The authorization request in OAuth 2.0 described in RFC 6749 utilizes
query parameter serialization, which means that Authorization Request query parameter serialization, which means that Authorization Request
parameters are encoded in the URI of the request and sent through parameters are encoded in the URI of the request and sent through
user agents such as web browsers. While it is easy to implement, it user agents such as web browsers. While it is easy to implement, it
means that (a) the communication through the user agents are not means that (a) the communication through the user agents are not
integrity protected and thus the parameters can be tainted, and (b) integrity protected and thus the parameters can be tainted, and (b)
the source of the communication is not authenticated. Because of the source of the communication is not authenticated. Because of
skipping to change at page 1, line 47 skipping to change at page 1, line 47
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 October 20, 2020. This Internet-Draft will expire on November 8, 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 2, line 29 skipping to change at page 2, line 29
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Request Object . . . . . . . . . . . . . . . . . . . . . 6 2.1. Request Object . . . . . . . . . . . . . . . . . . . . . 6
2.2. Request Object URI . . . . . . . . . . . . . . . . . . . 6 2.2. Request Object URI . . . . . . . . . . . . . . . . . . . 6
3. Symbols and abbreviated terms . . . . . . . . . . . . . . . . 6 3. Symbols and abbreviated terms . . . . . . . . . . . . . . . . 6
4. Request Object . . . . . . . . . . . . . . . . . . . . . . . 6 4. Request Object . . . . . . . . . . . . . . . . . . . . . . . 6
5. Authorization Request . . . . . . . . . . . . . . . . . . . . 8 5. Authorization Request . . . . . . . . . . . . . . . . . . . . 9
5.1. Passing a Request Object by Value . . . . . . . . . . . . 9 5.1. Passing a Request Object by Value . . . . . . . . . . . . 9
5.2. Passing a Request Object by Reference . . . . . . . . . . 9 5.2. Passing a Request Object by Reference . . . . . . . . . . 10
5.2.1. URI Referencing the Request Object . . . . . . . . . 10 5.2.1. URI Referencing the Request Object . . . . . . . . . 11
5.2.2. Request using the "request_uri" Request Parameter . . 11 5.2.2. Request using the "request_uri" Request Parameter . . 11
5.2.3. Authorization Server Fetches Request Object . . . . . 11 5.2.3. Authorization Server Fetches Request Object . . . . . 12
6. Validating JWT-Based Requests . . . . . . . . . . . . . . . . 12 6. Validating JWT-Based Requests . . . . . . . . . . . . . . . . 13
6.1. Encrypted Request Object . . . . . . . . . . . . . . . . 12 6.1. Encrypted Request Object . . . . . . . . . . . . . . . . 13
6.2. JWS Signed Request Object . . . . . . . . . . . . . . . . 12 6.2. JWS Signed Request Object . . . . . . . . . . . . . . . . 13
6.3. Request Parameter Assembly and Validation . . . . . . . . 13 6.3. Request Parameter Assembly and Validation . . . . . . . . 13
7. Authorization Server Response . . . . . . . . . . . . . . . . 13 7. Authorization Server Response . . . . . . . . . . . . . . . . 13
8. TLS Requirements . . . . . . . . . . . . . . . . . . . . . . 13 8. TLS Requirements . . . . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14
9.1. OAuth Parameters Registration . . . . . . . . . . . . . . 14 9.1. OAuth Parameters Registration . . . . . . . . . . . . . . 14
9.2. Media Type Registration . . . . . . . . . . . . . . . . . 15 9.2. Media Type Registration . . . . . . . . . . . . . . . . . 16
9.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 15 9.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 16
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10.1. Choice of Algorithms . . . . . . . . . . . . . . . . . . 16 10.1. Choice of Algorithms . . . . . . . . . . . . . . . . . . 17
10.2. Request Source Authentication . . . . . . . . . . . . . 16 10.2. Request Source Authentication . . . . . . . . . . . . . 17
10.3. Explicit Endpoints . . . . . . . . . . . . . . . . . . . 17 10.3. Explicit Endpoints . . . . . . . . . . . . . . . . . . . 18
10.4. Risks Associated with request_uri . . . . . . . . . . . 18 10.4. Risks Associated with request_uri . . . . . . . . . . . 18
10.4.1. DDoS Attack on the Authorization Server . . . . . . 18 10.4.1. DDoS Attack on the Authorization Server . . . . . . 18
10.4.2. Request URI Rewrite . . . . . . . . . . . . . . . . 18 10.4.2. Request URI Rewrite . . . . . . . . . . . . . . . . 19
11. TLS security considerations . . . . . . . . . . . . . . . . . 19 11. TLS security considerations . . . . . . . . . . . . . . . . . 19
12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19
12.1. Collection limitation . . . . . . . . . . . . . . . . . 19 12.1. Collection limitation . . . . . . . . . . . . . . . . . 19
12.2. Disclosure Limitation . . . . . . . . . . . . . . . . . 20 12.2. Disclosure Limitation . . . . . . . . . . . . . . . . . 20
12.2.1. Request Disclosure . . . . . . . . . . . . . . . . . 20 12.2.1. Request Disclosure . . . . . . . . . . . . . . . . . 20
12.2.2. Tracking using Request Object URI . . . . . . . . . 20 12.2.2. Tracking using Request Object URI . . . . . . . . . 21
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
14. Revision History . . . . . . . . . . . . . . . . . . . . . . 21 14. Revision History . . . . . . . . . . . . . . . . . . . . . . 21
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
15.1. Normative References . . . . . . . . . . . . . . . . . . 28 15.1. Normative References . . . . . . . . . . . . . . . . . . 28
15.2. Informative References . . . . . . . . . . . . . . . . . 30 15.2. Informative References . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
The Authorization Request in OAuth 2.0 [RFC6749] utilizes query The Authorization Request in OAuth 2.0 [RFC6749] utilizes query
skipping to change at page 5, line 18 skipping to change at page 5, line 18
and before user-agents). and before user-agents).
(d) (collection minimization) The request can be signed by a third (d) (collection minimization) The request can be signed by a third
party attesting that the authorization request is compliant with party attesting that the authorization request is compliant with
a certain policy. For example, a request can be pre-examined by a certain policy. For example, a request can be pre-examined by
a third party that all the personal data requested is strictly a third party that all the personal data requested is strictly
necessary to perform the process that the end-user asked for, necessary to perform the process that the end-user asked for,
and statically signed by that third party. The authorization and statically signed by that third party. The authorization
server then examines the signature and shows the conformance server then examines the signature and shows the conformance
status to the end-user, who would have some assurance as to the status to the end-user, who would have some assurance as to the
legitimacy of the request when authorizing it. In some cases, legitimacy of the request when authorizing it.
it may even be desirable to skip the authorization dialogue
under such circumstances.
There are a few cases that request by reference is useful such as: There are a few cases that request by reference is useful such as:
1. When it is desirable to reduce the size of transmitted request. 1. When it is desirable to reduce the size of transmitted request.
The use of application layer security increases the size of the The use of application layer security increases the size of the
request, particularly when public key cryptography is used. request, particularly when public key cryptography is used.
2. When the client does not want to do the application level crypto. 2. When the client does not want to do the application level crypto.
The Authorization Server may provide an endpoint to accept the The Authorization Server may provide an endpoint to accept the
Authorization Request through direct communication with the Authorization Request through direct communication with the
skipping to change at page 6, line 12 skipping to change at page 6, line 12
[RFC6749], JSON Web Signature [RFC7515], and JSON Web Encryption [RFC6749], JSON Web Signature [RFC7515], and JSON Web Encryption
[RFC7519] apply. [RFC7519] apply.
2.1. Request Object 2.1. Request Object
JWT [RFC7519] that holds an OAuth 2.0 authorization request as JWT JWT [RFC7519] that holds an OAuth 2.0 authorization request as JWT
Claims Set Claims Set
2.2. Request Object URI 2.2. Request Object URI
Absolute URI from which the Request Object (Section 2.1) can be Absolute URI that references the set of parameters comprising an
obtained OAuth 2.0 authorization request. The contents of the resource
referenced by the URI are a Request Object (Section 2.1), unless the
URI was provided to the client by the same Authorization Server, in
which case the content is an implementation detail at the discretion
the Authorization Server. The former is to ensure interoperability
in cases where the provider of the request_uri is a separate entity
from the consumer, such as when a client provides a URI referencing a
Request Object stored on the client's backend service and made
accessible via HTTPS. In the latter case where the Authorization
Server is both provider and consumer of the URI, such as when it
offers an endpoint that provides a URI in exchange for a Request
Object, this interoperability concern does not apply.
3. Symbols and abbreviated terms 3. Symbols and abbreviated terms
The following abbreviations are common to this specification. The following abbreviations are common to this specification.
JSON Javascript Object Notation JSON Javascript Object Notation
JWT JSON Web Token JWT JSON Web Token
JWS JSON Web Signature JWS JSON Web Signature
skipping to change at page 7, line 12 skipping to change at page 7, line 24
as members, with their semantics being the same as defined in the JWT as members, with their semantics being the same as defined in the JWT
[RFC7519] specification. The value of "aud" should be the value of [RFC7519] specification. The value of "aud" should be the value of
the Authorization Server (AS) "issuer" as defined in RFC8414 the Authorization Server (AS) "issuer" as defined in RFC8414
[RFC8414]. [RFC8414].
To encrypt, JWE [RFC7516] is used. When both signature and To encrypt, JWE [RFC7516] is used. When both signature and
encryption are being applied, the JWT MUST be signed then encrypted encryption are being applied, the JWT MUST be signed then encrypted
as advised in the section 11.2 of [RFC7519]. The result is a Nested as advised in the section 11.2 of [RFC7519]. The result is a Nested
JWT, as defined in [RFC7519]. JWT, as defined in [RFC7519].
The client determines the algorithms used to sign and encrypt request
objects. This decision can be based on metadata the client
registered via dynamic client registration [RFC7591] using the
parameters "request_object_signing_alg",
"request_object_encryption_alg", "request_object_encryption_enc" as
defined in the the IANA "OAuth Dynamic Client Registration Metadata"
registry [IANA.OAuth.Parameters] established by [RFC7591].
If the authorization server publishes its supported algorithms using
Authorization Server Metadata [RFC8414], the algorithms used by the
client must be contained in the list of algorithms published in the
metadata data parameters
"request_object_signing_alg_values_supported",
"request_object_encryption_alg_values_supported", and
"request_object_encryption_enc_values_supported" as defined in IANA
"OAuth Authorization Server Metadata" registry
[IANA.OAuth.Parameters] established by [RFC8414].
The Authorization Request Object MAY be sent by value as described in The Authorization Request Object MAY be sent by value as described in
Section 5.1 or by reference as described in Section 5.2. Section 5.1 or by reference as described in Section 5.2.
"request" and "request_uri" parameters MUST NOT be included in "request" and "request_uri" parameters MUST NOT be included in
Request Objects. Request Objects.
A Request Object (Section 2.1) has the "mime-type" "application/ A Request Object (Section 2.1) has the "mime-type" "application/
oauth.authz.req+jwt" oauth.authz.req+jwt"
The following is an example of the Claims in a Request Object before The following is an example of the Claims in a Request Object before
base64url encoding and signing. Note that it includes extension base64url encoding and signing. Note that it includes extension
variables such as "nonce" and "max_age". variables such as "nonce" and "max_age".
{ {
"iss": "s6BhdRkqt3", "iss": "s6BhdRkqt3",
"aud": "https://server.example.com", "aud": "https://server.example.com",
"response_type": "code id_token", "response_type": "code id_token",
"client_id": "s6BhdRkqt3", "client_id": "s6BhdRkqt3",
"redirect_uri": "https://client.example.org/cb", "redirect_uri": "https://client.example.org/cb",
skipping to change at page 8, line 33 skipping to change at page 9, line 16
The client constructs the authorization request URI by adding the The client constructs the authorization request URI by adding the
following parameters to the query component of the authorization following parameters to the query component of the authorization
endpoint URI using the "application/x-www-form-urlencoded" format: endpoint URI using the "application/x-www-form-urlencoded" format:
request REQUIRED unless "request_uri" is specified. The Request request REQUIRED unless "request_uri" is specified. The Request
Object (Section 2.1) that holds authorization request parameters Object (Section 2.1) that holds authorization request parameters
stated in section 4 of OAuth 2.0 [RFC6749]. stated in section 4 of OAuth 2.0 [RFC6749].
request_uri REQUIRED unless "request" is specified. The absolute request_uri REQUIRED unless "request" is specified. The absolute
URI as defined by RFC3986 [RFC3986] that points to the Request URI as defined by RFC3986 [RFC3986] that is the Request Object URI
Object (Section 2.1) that holds authorization request parameters (Section 2.2) referencing the authorization request parameters
stated in section 4 of OAuth 2.0 [RFC6749]. stated in section 4 of OAuth 2.0 [RFC6749].
client_id REQUIRED. OAuth 2.0 [RFC6749] "client_id". The value client_id REQUIRED. OAuth 2.0 [RFC6749] "client_id". The value
MUST match the "request" or "request_uri" Request Object's MUST match the "request" or "request_uri" Request Object's
(Section 2.1) "client_id". (Section 2.1) "client_id".
The client directs the resource owner to the constructed URI using an The client directs the resource owner to the constructed URI using an
HTTP redirection response, or by other means available to it via the HTTP redirection response, or by other means available to it via the
user-agent. user-agent.
skipping to change at page 10, line 17 skipping to change at page 10, line 48
ASCII characters. ASCII characters.
2. The maximum URL length supported by older versions of Internet 2. The maximum URL length supported by older versions of Internet
Explorer is 2083 ASCII characters. Explorer is 2083 ASCII characters.
3. On a slow connection such as 2G mobile connection, a large URL 3. On a slow connection such as 2G mobile connection, a large URL
would cause the slow response and therefore the use of such is would cause the slow response and therefore the use of such is
not advisable from the user experience point of view. not advisable from the user experience point of view.
The contents of the resource referenced by the URI MUST be a Request The contents of the resource referenced by the URI MUST be a Request
Object. The "request_uri" value MUST be either URN as defined in Object, unless the URI was provided to the client by the
RFC8141 [RFC8141] or "https" URI, as defined in 2.7.2 of RFC7230 Authorization Server. The "request_uri" value MUST be either URN as
[RFC7230] . The "request_uri" value MUST be reachable by the defined in RFC8141 [RFC8141] or "https" URI, as defined in 2.7.2 of
RFC7230 [RFC7230] . The "request_uri" value MUST be reachable by the
Authorization Server. Authorization Server.
The following is an example of the contents of a Request Object The following is an example of the contents of a Request Object
resource that can be referenced by a "request_uri" (with line wraps resource that can be referenced by a "request_uri" (with line wraps
within values for display purposes only): within values for display purposes only):
eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI6ICJzNkJoZF eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI6ICJzNkJoZF
JrcXQzIiwKICAgICJhdWQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLAog JrcXQzIiwKICAgICJhdWQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLAog
ICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsCiAgICAiY2xpZW50X2 ICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsCiAgICAiY2xpZW50X2
lkIjogInM2QmhkUmtxdDMiLAogICAgInJlZGlyZWN0X3VyaSI6ICJodHRwczovL2Ns lkIjogInM2QmhkUmtxdDMiLAogICAgInJlZGlyZWN0X3VyaSI6ICJodHRwczovL2Ns
skipping to change at page 11, line 27 skipping to change at page 12, line 14
The following is an example of an Authorization Request using the The following is an example of an Authorization Request using the
"request_uri" parameter (with line wraps within values for display "request_uri" parameter (with line wraps within values for display
purposes only): purposes only):
https://server.example.com/authorize? https://server.example.com/authorize?
response_type=code%20id_token response_type=code%20id_token
&client_id=s6BhdRkqt3 &client_id=s6BhdRkqt3
&request_uri=https%3A%2F%2Ftfp.example.org%2Frequest.jwt &request_uri=https%3A%2F%2Ftfp.example.org%2Frequest.jwt
%2FGkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM %2FGkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM
&state=af0ifjsldkj
5.2.3. Authorization Server Fetches Request Object 5.2.3. Authorization Server Fetches Request Object
Upon receipt of the Request, the Authorization Server MUST send an Upon receipt of the Request, the Authorization Server MUST send an
HTTP "GET" request to the "request_uri" to retrieve the referenced HTTP "GET" request to the "request_uri" to retrieve the referenced
Request Object, unless it is stored in a way so that it can retrieve Request Object, unless it is stored in a way so that it can retrieve
it through other mechanism securely, and parse it to recreate the it through other mechanism securely, and parse it to recreate the
Authorization Request parameters. Authorization Request parameters.
The following is an example of this fetch process: The following is an example of this fetch process:
skipping to change at page 16, line 22 skipping to change at page 16, line 47
o Intended usage: COMMON o Intended usage: COMMON
o Restrictions on usage: none o Restrictions on usage: none
o Author: Nat Sakimura, n-sakimura@nri.co.jp o Author: Nat Sakimura, n-sakimura@nri.co.jp
o Change controller: IESG o Change controller: IESG
o Provisional registration? No o Provisional registration? No
10. Security Considerations 10. Security Considerations
In addition to the all the security considerations discussed in OAuth In addition to the all the security considerations discussed in OAuth
2.0 [RFC6819], the security considerations in [RFC7515], [RFC7516], 2.0 [RFC6819], the security considerations in [RFC7515], [RFC7516],
and [RFC7518] needs to be considered. Also, there are several [RFC7518], and [RFC8725] needs to be considered. Also, there are
academic papers such as [BASIN] that provide useful insight into the several academic papers such as [BASIN] that provide useful insight
security properties of protocols like OAuth. into the security properties of protocols like OAuth.
In consideration of the above, this document advises taking the In consideration of the above, this document advises taking the
following security considerations into account. following security considerations into account.
10.1. Choice of Algorithms 10.1. Choice of Algorithms
When sending the authorization request object through "request" When sending the authorization request object through "request"
parameter, it MUST either be signed using JWS [RFC7515] or signed parameter, it MUST either be signed using JWS [RFC7515] or signed
then encrypted using JWS [RFC7515] and JWE [RFC7516] respectively, then encrypted using JWS [RFC7515] and JWE [RFC7516] respectively,
with then considered appropriate algorithms. with then considered appropriate algorithms.
skipping to change at page 21, line 13 skipping to change at page 21, line 33
Therefore, per-user Request Object URI should be avoided. Therefore, per-user Request Object URI should be avoided.
13. Acknowledgements 13. Acknowledgements
The following people contributed to the creation of this document in The following people contributed to the creation of this document in
the OAuth WG. (Affiliations at the time of the contribution are the OAuth WG. (Affiliations at the time of the contribution are
used.) used.)
Sergey Beryozkin, Brian Campbell (Ping Identity), Vladimir Dzhuvinov Sergey Beryozkin, Brian Campbell (Ping Identity), Vladimir Dzhuvinov
(Connect2id), Michael B. Jones (Microsoft), Torsten Lodderstedt (Connect2id), Michael B. Jones (Microsoft), Torsten Lodderstedt
(YES) Jim Manico, Axel Nenker(Deutsche Telecom), Hannes Tschofenig (yes.com) Jim Manico, Axel Nenker(Deutsche Telecom), Hannes
(ARM), Ben Campbell, Dirk Balfanz (Google), James H. Manger Tschofenig (ARM), Ben Campbell, Dirk Balfanz (Google), James H.
(Telstra), John Panzer (Google), David Recordon (Facebook), Marius Manger (Telstra), John Panzer (Google), David Recordon (Facebook),
Scurtescu (Google), Luke Shepard (Facebook), Kathleen Moriarty (as Marius Scurtescu (Google), Luke Shepard (Facebook), Annabelle Backman
AD), and Steve Kent (as SECDIR). (Amazon) Kathleen Moriarty (as AD), and Steve Kent (as SECDIR).
The following people contributed to creating this document through The following people contributed to creating this document through
the OpenID Connect Core 1.0 [OpenID.Core]. the OpenID Connect Core 1.0 [OpenID.Core].
Brian Campbell (Ping Identity), George Fletcher (AOL), Ryo Itou Brian Campbell (Ping Identity), George Fletcher (AOL), Ryo Itou
(Mixi), Edmund Jay (Illumila), Michael B. Jones (Microsoft), Breno (Mixi), Edmund Jay (Illumila), Michael B. Jones (Microsoft), Breno
de Medeiros (Google), Hideki Nara (TACT), Justin Richer (MITRE). de Medeiros (Google), Hideki Nara (TACT), Justin Richer (MITRE).
14. Revision History 14. Revision History
skipping to change at page 30, line 23 skipping to change at page 30, line 45
papers/BCM2012-iso9798.pdf>. papers/BCM2012-iso9798.pdf>.
[CapURLs] Tennison, J., "Good Practices for Capability URLs", [CapURLs] Tennison, J., "Good Practices for Capability URLs",
W3C Working Draft, February 2014, W3C Working Draft, February 2014,
<https://www.w3.org/TR/capability-urls/>. <https://www.w3.org/TR/capability-urls/>.
[FETT] Fett, D., Kusters, R., and G. Schmitz, "A Comprehensive [FETT] Fett, D., Kusters, R., and G. Schmitz, "A Comprehensive
Formal Security Analysis of OAuth 2.0", CCS '16 Formal Security Analysis of OAuth 2.0", CCS '16
Proceedings of the 2016 ACM SIGSAC Conference on Computer Proceedings of the 2016 ACM SIGSAC Conference on Computer
and Communications Security Pages 1204-1215 , October and Communications Security Pages 1204-1215 , October
2016, <https://infsec.uni- 2016, <https://arxiv.org/pdf/1601.01229v2.pdf>.
trier.de/people/publications/paper/FettKuestersSchmitz-
CCS-2016.pdf>. [IANA.OAuth.Parameters]
IANA, "OAuth Parameters",
<http://www.iana.org/assignments/oauth-parameters>.
[OpenID.Core] [OpenID.Core]
Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
C. Mortimore, "OpenID Connect Core 1.0", OpenID C. Mortimore, "OpenID Connect Core 1.0", OpenID
Foundation Standards, February 2014, Foundation Standards, February 2014,
<http://openid.net/specs/openid-connect-core-1_0.html>. <http://openid.net/specs/openid-connect-core-1_0.html>.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, Extensions (MIME) Part Two: Media Types", RFC 2046,
DOI 10.17487/RFC2046, November 1996, DOI 10.17487/RFC2046, November 1996,
skipping to change at page 31, line 5 skipping to change at page 31, line 32
Specifications and Registration Procedures", BCP 13, Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013, RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/info/rfc6838>. <https://www.rfc-editor.org/info/rfc6838>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973, Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013, DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/info/rfc6973>. <https://www.rfc-editor.org/info/rfc6973>.
[RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and
P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",
RFC 7591, DOI 10.17487/RFC7591, July 2015,
<https://www.rfc-editor.org/info/rfc7591>.
[RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best
Current Practices", BCP 225, RFC 8725,
DOI 10.17487/RFC8725, February 2020,
<https://www.rfc-editor.org/info/rfc8725>.
Authors' Addresses Authors' Addresses
Nat Sakimura Nat Sakimura
Nomura Research Institute NAT.Consulting
2-22-17 Naka 2-22-17 Naka
Kunitachi, Tokyo 186-0004 Kunitachi, Tokyo 186-0004
Japan Japan
Phone: +81-42-580-7401 Phone: +81-42-580-7401
Email: nat@nat.consulting Email: nat@nat.consulting
URI: http://nat.sakimura.org/ URI: http://nat.sakimura.org/
John Bradley John Bradley
Yubico Yubico
Casilla 177, Sucursal Talagante Casilla 177, Sucursal Talagante
Talagante, RM Talagante, RM
Chile Chile
Phone: +1.202.630.5272 Phone: +1.202.630.5272
Email: ve7jtb@ve7jtb.com Email: ve7jtb@ve7jtb.com
URI: http://www.thread-safe.com/ URI: http://www.thread-safe.com/
 End of changes. 25 change blocks. 
45 lines changed or deleted 82 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/