< draft-ietf-oauth-jwsreq-19.txt   draft-ietf-oauth-jwsreq-20.txt >
OAuth Working Group N. Sakimura OAuth Working Group N. Sakimura
Internet-Draft Nomura Research Institute Internet-Draft Nomura Research Institute
Intended status: Standards Track J. Bradley Intended status: Standards Track J. Bradley
Expires: December 12, 2019 Yubico Expires: April 22, 2020 Yubico
June 10, 2019 October 20, 2019
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-19 draft-ietf-oauth-jwsreq-20
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 December 12, 2019. This Internet-Draft will expire on April 22, 2020.
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 2, line 25 skipping to change at page 2, line 25
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Request Object . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . 9
5.2.1. URI Referencing the Request Object . . . . . . . . . 11 5.2.1. URI Referencing the Request Object . . . . . . . . . 10
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 . . . . . 11
6. Validating JWT-Based Requests . . . . . . . . . . . . . . . . 12 6. Validating JWT-Based Requests . . . . . . . . . . . . . . . . 12
6.1. Encrypted Request Object . . . . . . . . . . . . . . . . 12 6.1. Encrypted Request Object . . . . . . . . . . . . . . . . 12
6.2. JWS Signed Request Object . . . . . . . . . . . . . . . . 13 6.2. JWS Signed Request Object . . . . . . . . . . . . . . . . 12
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 . . . . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14
10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9.1. OAuth Parameters Registration . . . . . . . . . . . . . . 14
10.1. Choice of Algorithms . . . . . . . . . . . . . . . . . . 14 9.2. Media Type Registration . . . . . . . . . . . . . . . . . 15
10.2. Request Source Authentication . . . . . . . . . . . . . 15 9.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 15
10.3. Explicit Endpoints . . . . . . . . . . . . . . . . . . . 15 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10.4. Risks Associated with request_uri . . . . . . . . . . . 16 10.1. Choice of Algorithms . . . . . . . . . . . . . . . . . . 16
10.4.1. DDoS Attack on the Authorization Server . . . . . . 16 10.2. Request Source Authentication . . . . . . . . . . . . . 16
10.4.2. Request URI Rewrite . . . . . . . . . . . . . . . . 16 10.3. Explicit Endpoints . . . . . . . . . . . . . . . . . . . 17
11. TLS security considerations . . . . . . . . . . . . . . . . . 17 10.4. Risks Associated with request_uri . . . . . . . . . . . 18
12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 10.4.1. DDoS Attack on the Authorization Server . . . . . . 18
12.1. Collection limitation . . . . . . . . . . . . . . . . . 17 10.4.2. Request URI Rewrite . . . . . . . . . . . . . . . . 18
12.2. Disclosure Limitation . . . . . . . . . . . . . . . . . 18 11. TLS security considerations . . . . . . . . . . . . . . . . . 19
12.2.1. Request Disclosure . . . . . . . . . . . . . . . . . 18 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19
12.2.2. Tracking using Request Object URI . . . . . . . . . 18 12.1. Collection limitation . . . . . . . . . . . . . . . . . 19
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 12.2. Disclosure Limitation . . . . . . . . . . . . . . . . . 20
14. Revision History . . . . . . . . . . . . . . . . . . . . . . 19 12.2.1. Request Disclosure . . . . . . . . . . . . . . . . . 20
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 12.2.2. Tracking using Request Object URI . . . . . . . . . 20
15.1. Normative References . . . . . . . . . . . . . . . . . . 25 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
15.2. Informative References . . . . . . . . . . . . . . . . . 26 14. Revision History . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
15.1. Normative References . . . . . . . . . . . . . . . . . . 28
15.2. Informative References . . . . . . . . . . . . . . . . . 30
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
parameter serialization and is typically sent through user agents parameter serialization and is typically sent through user agents
such as web browsers. such as web browsers.
For example, the parameters "response_type", "client_id", "state", For example, the parameters "response_type", "client_id", "state",
and "redirect_uri" are encoded in the URI of the request: and "redirect_uri" are encoded in the URI of the request:
GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1 &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com Host: server.example.com
While it is easy to implement, the encoding in the URI does not allow While it is easy to implement, the encoding in the URI does not allow
application layer security with confidentiality and integrity application layer security to be used to provide confidentiality and
protection to be used. While TLS is used to offer communication integrity protection. While TLS is used to offer communication
security between the Client and the user-agent as well as the user- security between the Client and the user-agent as well as the user-
agent and the Authorization Server, TLS sessions are terminated in agent and the Authorization Server, TLS sessions are terminated in
the user-agent. In addition, TLS sessions may be terminated the user-agent. In addition, TLS sessions may be terminated
prematurely at some middlebox (such as a load balancer). prematurely at some middlebox (such as a load balancer).
As the result, the Authorization Request of [RFC6749] has As the result, the Authorization Request of [RFC6749] has
shortcomings in that: shortcomings in that:
(a) the communication through the user agents are not integrity (a) the communication through the user agents are not integrity
protected and thus the parameters can be tainted (integrity protected and thus the parameters can be tainted (integrity
skipping to change at page 4, line 10 skipping to change at page 4, line 16
protocol, such as Redirection URI rewriting and Mix-up attack [FETT], protocol, such as Redirection URI rewriting and Mix-up attack [FETT],
have been identified. have been identified.
The use of application layer security mitigates these issues. The use of application layer security mitigates these issues.
The use of application layer security allows requests to be prepared The use of application layer security allows requests to be prepared
by a third party so that a client application cannot request more by a third party so that a client application cannot request more
permissions than previously agreed. This offers an additional degree permissions than previously agreed. This offers an additional degree
of privacy protection. of privacy protection.
Furthermore, the request by reference allows the reduction of over- Furthermore, passing the request by reference allows the reduction of
the-wire overhead. over-the-wire overhead.
The JWT [RFC7519] encoding has been chosen because of The JWT [RFC7519] encoding has been chosen because of
(1) its close relationship with JSON, which is used as OAuth's (1) its close relationship with JSON, which is used as OAuth's
response format response format
(2) its developer friendliness due to its textual nature (2) its developer friendliness due to its textual nature
(3) its relative compactness compared to XML (3) its relative compactness compared to XML
(4) its development status that it is an RFC and so is its (4) its development status as a Proposed Standard, along with the
associated signing and encryption methods as [RFC7515] and associated signing and encryption methods [RFC7515] [RFC7516]
[RFC7516]
(5) the relative ease of JWS and JWE compared to XML Signature and (5) the relative ease of JWS and JWE compared to XML Signature and
Encryption. Encryption.
The parameters "request" and "request_uri" are introduced as The parameters "request" and "request_uri" are introduced as
additional authorization request parameters for the OAuth 2.0 additional authorization request parameters for the OAuth 2.0
[RFC6749] flows. The "request" parameter is a JSON Web Token (JWT) [RFC6749] flows. The "request" parameter is a JSON Web Token (JWT)
[RFC7519] whose JWT Claims Set holds the JSON encoded OAuth 2.0 [RFC7519] whose JWT Claims Set holds the JSON encoded OAuth 2.0
authorization request parameters. This JWT is integrity protected authorization request parameters. This JWT is integrity protected
and source authenticated using JWS. and source authenticated using JWS.
skipping to change at page 4, line 51 skipping to change at page 5, line 7
parameters has several advantages: parameters has several advantages:
(a) (integrity protection) The request can be signed so that the (a) (integrity protection) The request can be signed so that the
integrity of the request can be checked. integrity of the request can be checked.
(b) (source authentication) The request can be signed so that the (b) (source authentication) The request can be signed so that the
signer can be authenticated. signer can be authenticated.
(c) (confidentiality protection) The request can be encrypted so (c) (confidentiality protection) The request can be encrypted so
that end-to-end confidentiality can be provided even if the TLS that end-to-end confidentiality can be provided even if the TLS
connection is terminated at one point or another. connection is terminated at one point or another (including at
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. In some cases,
it may even be desirable to skip the authorization dialogue it may even be desirable to skip the authorization dialogue
under such circumstances. 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 crypto. The 2. When the client does not want to do the application level crypto.
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
Client so that the Client is authenticated and the channel is TLS Client so that the Client is authenticated and the channel is TLS
protected. protected.
This capability is in use by OpenID Connect [OpenID.Core]. This capability is in use by OpenID Connect [OpenID.Core].
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Terminology 2. Terminology
For the purposes of this specification, the following terms and For the purposes of this specification, the following terms and
definitions in addition to what is defined in OAuth 2.0 Framework definitions in addition to what is defined in OAuth 2.0 Framework
[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
skipping to change at page 6, line 30 skipping to change at page 6, line 35
JWE JSON Web Encryption JWE JSON Web Encryption
URI Uniform Resource Identifier URI Uniform Resource Identifier
URL Uniform Resource Locator URL Uniform Resource Locator
4. Request Object 4. Request Object
A Request Object (Section 2.1) is used to provide authorization A Request Object (Section 2.1) is used to provide authorization
request parameters for an OAuth 2.0 authorization request. It MUST request parameters for an OAuth 2.0 authorization request. It MUST
contains all the OAuth 2.0 [RFC6749] authorization request parameters contain all the parameters (including extension parameters) used to
including extension parameters. The parameters are represented as process the OAuth 2.0 [RFC6749] authorization request except the
the JWT claims. Parameter names and string values MUST be included "request" and "request_uri" parameters that are defined in this
as JSON strings. Since Request Objects are handled across domains document. The parameters are represented as the JWT claims of the
and potentially outside of a closed ecosystem, per section 8.1 of object. Parameter names and string values MUST be included as JSON
strings. Since Request Objects are handled across domains and
potentially outside of a closed ecosystem, per section 8.1 of
[RFC8259], these JSON strings MUST be encoded using UTF-8 [RFC3629]. [RFC8259], these JSON strings MUST be encoded using UTF-8 [RFC3629].
Numerical values MUST be included as JSON numbers. It MAY include Numerical values MUST be included as JSON numbers. It MAY include
any extension parameters. This JSON [RFC7159] constitutes the JWT any extension parameters. This JSON [RFC7159] object constitutes the
Claims Set defined in JWT [RFC7519]. The JWT Claims Set is then JWT Claims Set defined in JWT [RFC7519]. The JWT Claims Set is then
signed or signed and encrypted. signed or signed and encrypted.
To sign, JSON Web Signature (JWS) [RFC7515] is used. The result is a To sign, JSON Web Signature (JWS) [RFC7515] is used. The result is a
JWS signed JWT [RFC7519]. If signed, the Authorization Request JWS signed JWT [RFC7519]. If signed, the Authorization Request
Object SHOULD contain the Claims "iss" (issuer) and "aud" (audience) Object SHOULD contain the Claims "iss" (issuer) and "aud" (audience)
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].
skipping to change at page 7, line 11 skipping to change at page 7, line 18
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 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/
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",
"scope": "openid", "scope": "openid",
"state": "af0ifjsldkj", "state": "af0ifjsldkj",
"nonce": "n-0S6_WzA2Mj", "nonce": "n-0S6_WzA2Mj",
"max_age": 86400 "max_age": 86400
} }
Signing it with the "RS256" algorithm results in this Request Object Signing it with the "RS256" algorithm results in this Request Object
value (with line wraps within values for display purposes only): value (with line wraps within values for display purposes only):
eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KICJpc3MiOiAiczZCaGRSa3 eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI6ICJzNkJoZF
F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsDQogInJl JrcXQzIiwKICAgICJhdWQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLAog
c3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWVudF9pZCI6ICJzNk ICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsCiAgICAiY2xpZW50X2
JoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8vY2xpZW50LmV4YW1w lkIjogInM2QmhkUmtxdDMiLAogICAgInJlZGlyZWN0X3VyaSI6ICJodHRwczovL2Ns
bGUub3JnL2NiIiwNCiAic2NvcGUiOiAib3BlbmlkIiwNCiAic3RhdGUiOiAiYWYwaW aWVudC5leGFtcGxlLm9yZy9jYiIsCiAgICAic2NvcGUiOiAib3BlbmlkIiwKICAgIC
Zqc2xka2oiLA0KICJub25jZSI6ICJuLTBTNl9XekEyTWoiLA0KICJtYXhfYWdlIjog JzdGF0ZSI6ICJhZjBpZmpzbGRraiIsCiAgICAibm9uY2UiOiAibi0wUzZfV3pBMk1q
ODY0MDAsDQogImNsYWltcyI6IA0KICB7DQogICAidXNlcmluZm8iOiANCiAgICB7DQ IiwKICAgICJtYXhfYWdlIjogODY0MDAKfQ.Nsxa_18VUElVaPjqW_ToI1yrEJ67BgK
ogICAgICJnaXZlbl9uYW1lIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgIm5p b5xsuZRVqzGkfKrOIX7BCx0biSxYGmjK9KJPctH1OC0iQJwXu5YVY-vnW0_PLJb1C2
Y2tuYW1lIjogbnVsbCwNCiAgICAgImVtYWlsIjogeyJlc3NlbnRpYWwiOiB0cnVlfS HG-ztVzcnKZC2gE4i0vgQcpkUOCpW3SEYXnyWnKzuKzqSb1wAZALo5f89B_p6QA6j6
wNCiAgICAgImVtYWlsX3ZlcmlmaWVkIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAg JwBSRvdVsDPdulW8lKxGTbH82czCaQ50rLAg3EYLYaCb4ik4I1zGXE4fvim9FIMs8O
ICAgInBpY3R1cmUiOiBudWxsDQogICAgfSwNCiAgICJpZF90b2tlbiI6IA0KICAgIH CMmzwIB5S-ujFfzwFjoyuPEV4hJnoVUmXR_W9typPf846lGwA8h9G9oNTIuX8Ft2jf
sNCiAgICAgImdlbmRlciI6IG51bGwsDQogICAgICJiaXJ0aGRhdGUiOiB7ImVzc2Vu pnZdFmLg3_wr3Wa5q3a-lfbgF3S9H_8nN3j1i7tLR_5Nz-g
dGlhbCI6IHRydWV9LA0KICAgICAiYWNyIjogeyJ2YWx1ZXMiOiBbInVybjptYWNlOm
luY29tbW9uOmlhcDpzaWx2ZXIiXX0NCiAgICB9DQogIH0NCn0.nwwnNsk1-Zkbmnvs
F6zTHm8CHERFMGQPhos-EJcaH4Hh-sMgk8ePrGhw_trPYs8KQxsn6R9Emo_wHwajyF
KzuMXZFSZ3p6Mb8dkxtVyjoy2GIzvuJT_u7PkY2t8QU9hjBcHs68PkgjDVTrG1uRTx
0GxFbuPbj96tVuj11pTnmFCUR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc8K
ol-cSLWoYE9l5QqholImzjT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLSjLLlxmPG
iyon_-Te111V8uE83IlzCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw
The following RSA public key, represented in JWK format, can be used The following RSA public key, represented in JWK format, can be used
to validate the Request Object signature in this and subsequent to validate the Request Object signature in this and subsequent
Request Object examples (with line wraps within values for display Request Object examples (with line wraps within values for display
purposes only): purposes only):
{ {
"kty":"RSA", "kty":"RSA",
"kid":"k2bdc", "kid":"k2bdc",
"n":"y9Lqv4fCp6Ei-u2-ZCKq83YvbFEk6JMs_pSj76eMkddWRuWX2aBKGHAtKlE5P "n":"x5RbkAZkmpRxia65qRQ1wwSMSxQUnS7gcpVTV_cdHmfmG2ltd2yabEO9XadD8
7_vn__PCKZWePt3vGkB6ePgzAFu08NmKemwE5bQI0e6kIChtt_6KzT5OaaXDF pJNZubINPpmgHh3J1aD9WRwS05ucmFq3CfFsluLt13_7oX5yDRSKX7poXmT_5
I6qCLJmk51Cc4VYFaxgqevMncYrzaW_50mZ1yGSFIQzLYP8bijAHGVjdEFgZa ko8k4NJZPMAO8fPToDTH7kHYbONSE2FYa5GZ60CUsFhSonI-dcMDJ0Ary9lxI
ZEN9lsn_GdWLaJpHrB3ROlS50E45wxrlg9xMncVb8qDPuXZarvghLL0HzOuYR w5k2z4TAdARVWcS7sD07VhlMMshrwsPHBQgTatlkxyIHXbYdtak8fqvNAwr7O
adBJVoWZowDNTpKpk2RklZ7QaBO7XDv3uR7s_sf2g-bAjSYxYUGsqkNA9b3xV lVEvM_Ipf5OfmdB8Sd-wjzaBsyP4VhJKoi_qdgSzpC694XZeYPq45Sw-q51iF
W53am_UZZ3tZbFTIh557JICWKHlWj5uzeJXaw", UlcOlTCI7z6jltUtnR6ySn6XDGFnzH5Fe5ypw",
"e":"AQAB" "e":"AQAB"
} }
5. Authorization Request 5. Authorization Request
The client constructs the authorization request URI by adding one of The client constructs the authorization request URI by adding one of
the following parameters but not both to the query component of the the following parameters but not both to the query component of the
authorization endpoint URI using the "application/x-www-form- authorization endpoint URI using the "application/x-www-form-
urlencoded" format: urlencoded" format:
skipping to change at page 9, line 22 skipping to change at page 9, line 22
5.1. Passing a Request Object by Value 5.1. Passing a Request Object by Value
The Client sends the Authorization Request as a Request Object to the The Client sends the Authorization Request as a Request Object to the
Authorization Endpoint as the "request" parameter value. Authorization Endpoint as the "request" parameter value.
The following is an example of an Authorization Request using the The following is an example of an Authorization Request using the
"request" parameter (with line wraps within values for display "request" parameter (with line wraps within values for display
purposes only): purposes only):
https://server.example.com/authorize? https://server.example.com/authorize?
request=eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KICJpc3MiOiA request=eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI6
iczZCaGRSa3F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmN ICJzNkJoZFJrcXQzIiwKICAgICJhdWQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBs
vbSIsDQogInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWV ZS5jb20iLAogICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsCiAg
udF9pZCI6ICJzNkJoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8 ICAiY2xpZW50X2lkIjogInM2QmhkUmtxdDMiLAogICAgInJlZGlyZWN0X3VyaSI6
vY2xpZW50LmV4YW1wbGUub3JnL2NiIiwNCiAic2NvcGUiOiAib3BlbmlkIiwNCiA ICJodHRwczovL2NsaWVudC5leGFtcGxlLm9yZy9jYiIsCiAgICAic2NvcGUiOiAi
ic3RhdGUiOiAiYWYwaWZqc2xka2oiLA0KICJub25jZSI6ICJuLTBTNl9XekEyTWo b3BlbmlkIiwKICAgICJzdGF0ZSI6ICJhZjBpZmpzbGRraiIsCiAgICAibm9uY2Ui
iLA0KICJtYXhfYWdlIjogODY0MDAsDQogImNsYWltcyI6IA0KICB7DQogICAidXN OiAibi0wUzZfV3pBMk1qIiwKICAgICJtYXhfYWdlIjogODY0MDAKfQ.Nsxa_18VU
lcmluZm8iOiANCiAgICB7DQogICAgICJnaXZlbl9uYW1lIjogeyJlc3NlbnRpYWw ElVaPjqW_ToI1yrEJ67BgKb5xsuZRVqzGkfKrOIX7BCx0biSxYGmjK9KJPctH1OC
iOiB0cnVlfSwNCiAgICAgIm5pY2tuYW1lIjogbnVsbCwNCiAgICAgImVtYWlsIjo 0iQJwXu5YVY-vnW0_PLJb1C2HG-ztVzcnKZC2gE4i0vgQcpkUOCpW3SEYXnyWnKz
geyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgImVtYWlsX3ZlcmlmaWVkIjogeyJ uKzqSb1wAZALo5f89B_p6QA6j6JwBSRvdVsDPdulW8lKxGTbH82czCaQ50rLAg3E
lc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgInBpY3R1cmUiOiBudWxsDQogICAgfSw YLYaCb4ik4I1zGXE4fvim9FIMs8OCMmzwIB5S-ujFfzwFjoyuPEV4hJnoVUmXR_W
NCiAgICJpZF90b2tlbiI6IA0KICAgIHsNCiAgICAgImdlbmRlciI6IG51bGwsDQo 9typPf846lGwA8h9G9oNTIuX8Ft2jfpnZdFmLg3_wr3Wa5q3a-lfbgF3S9H_8nN3
gICAgICJiaXJ0aGRhdGUiOiB7ImVzc2VudGlhbCI6IHRydWV9LA0KICAgICAiYWN j1i7tLR_5Nz-g
yIjogeyJ2YWx1ZXMiOiBbInVybjptYWNlOmluY29tbW9uOmlhcDpzaWx2ZXIiXX0
NCiAgICB9DQogIH0NCn0.nwwnNsk1-ZkbmnvsF6zTHm8CHERFMGQPhos-EJcaH4H
h-sMgk8ePrGhw_trPYs8KQxsn6R9Emo_wHwajyFKzuMXZFSZ3p6Mb8dkxtVyjoy2
GIzvuJT_u7PkY2t8QU9hjBcHs68PkgjDVTrG1uRTx0GxFbuPbj96tVuj11pTnmFC
UR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc8Kol-cSLWoYE9l5QqholImz
jT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLSjLLlxmPGiyon_-Te111V8uE83Il
zCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw
5.2. Passing a Request Object by Reference 5.2. Passing a Request Object by Reference
The "request_uri" Authorization Request parameter enables OAuth The "request_uri" Authorization Request parameter enables OAuth
authorization requests to be passed by reference, rather than by authorization requests to be passed by reference, rather than by
value. This parameter is used identically to the "request" value. This parameter is used identically to the "request"
parameter, other than that the Request Object value is retrieved from parameter, other than that the Request Object value is retrieved from
the resource identified by the specified URI rather than passed by the resource identified by the specified URI rather than passed by
value. value.
skipping to change at page 10, line 29 skipping to change at page 10, line 22
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. The "request_uri" value MUST be either URN as defined in
RFC8141 [RFC8141] or "https" URI, as defined in 2.7.2 of RFC7230 RFC8141 [RFC8141] or "https" URI, as defined in 2.7.2 of RFC7230
[RFC7230] . The "request_uri" value MUST be reachable by the [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.ew0KICJpc3MiOiAiczZCaGRSa3 eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI6ICJzNkJoZF
F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsDQogInJl JrcXQzIiwKICAgICJhdWQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLAog
c3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWVudF9pZCI6ICJzNk ICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsCiAgICAiY2xpZW50X2
JoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8vY2xpZW50LmV4YW1w lkIjogInM2QmhkUmtxdDMiLAogICAgInJlZGlyZWN0X3VyaSI6ICJodHRwczovL2Ns
bGUub3JnL2NiIiwNCiAic2NvcGUiOiAib3BlbmlkIiwNCiAic3RhdGUiOiAiYWYwaW aWVudC5leGFtcGxlLm9yZy9jYiIsCiAgICAic2NvcGUiOiAib3BlbmlkIiwKICAgIC
Zqc2xka2oiLA0KICJub25jZSI6ICJuLTBTNl9XekEyTWoiLA0KICJtYXhfYWdlIjog JzdGF0ZSI6ICJhZjBpZmpzbGRraiIsCiAgICAibm9uY2UiOiAibi0wUzZfV3pBMk1q
ODY0MDAsDQogImNsYWltcyI6IA0KICB7DQogICAidXNlcmluZm8iOiANCiAgICB7DQ IiwKICAgICJtYXhfYWdlIjogODY0MDAKfQ.Nsxa_18VUElVaPjqW_ToI1yrEJ67BgK
ogICAgICJnaXZlbl9uYW1lIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgIm5p b5xsuZRVqzGkfKrOIX7BCx0biSxYGmjK9KJPctH1OC0iQJwXu5YVY-vnW0_PLJb1C2
Y2tuYW1lIjogbnVsbCwNCiAgICAgImVtYWlsIjogeyJlc3NlbnRpYWwiOiB0cnVlfS HG-ztVzcnKZC2gE4i0vgQcpkUOCpW3SEYXnyWnKzuKzqSb1wAZALo5f89B_p6QA6j6
wNCiAgICAgImVtYWlsX3ZlcmlmaWVkIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAg JwBSRvdVsDPdulW8lKxGTbH82czCaQ50rLAg3EYLYaCb4ik4I1zGXE4fvim9FIMs8O
ICAgInBpY3R1cmUiOiBudWxsDQogICAgfSwNCiAgICJpZF90b2tlbiI6IA0KICAgIH CMmzwIB5S-ujFfzwFjoyuPEV4hJnoVUmXR_W9typPf846lGwA8h9G9oNTIuX8Ft2jf
sNCiAgICAgImdlbmRlciI6IG51bGwsDQogICAgICJiaXJ0aGRhdGUiOiB7ImVzc2Vu pnZdFmLg3_wr3Wa5q3a-lfbgF3S9H_8nN3j1i7tLR_5Nz-g
dGlhbCI6IHRydWV9LA0KICAgICAiYWNyIjogeyJ2YWx1ZXMiOiBbInVybjptYWNlOm
luY29tbW9uOmlhcDpzaWx2ZXIiXX0NCiAgICB9DQogIH0NCn0.nwwnNsk1-Zkbmnvs
F6zTHm8CHERFMGQPhos-EJcaH4Hh-sMgk8ePrGhw_trPYs8KQxsn6R9Emo_wHwajyF
KzuMXZFSZ3p6Mb8dkxtVyjoy2GIzvuJT_u7PkY2t8QU9hjBcHs68PkgjDVTrG1uRTx
0GxFbuPbj96tVuj11pTnmFCUR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc8K
ol-cSLWoYE9l5QqholImzjT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLSjLLlxmPG
iyon_-Te111V8uE83IlzCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw
5.2.1. URI Referencing the Request Object 5.2.1. URI Referencing the Request Object
The Client stores the Request Object resource either locally or The Client stores the Request Object resource either locally or
remotely at a URI the Authorization Server can access. Such facility remotely at a URI the Authorization Server can access. Such facility
may be provided by the authorization server or a third party. For may be provided by the authorization server or a third party. For
example, the authorization server may provide a URL to which the example, the authorization server may provide a URL to which the
client POSTs the request object and obtains the Request URI. This client POSTs the request object and obtains the Request URI. This
URI is the Request Object URI, "request_uri". URI is the Request Object URI, "request_uri".
It is possible for the Request Object to include values that are to It is possible for the Request Object to include values that are to
be revealed only to the Authorization Server. As such, the be revealed only to the Authorization Server. As such, the
"request_uri" MUST have appropriate entropy for its lifetime. For "request_uri" MUST have appropriate entropy for its lifetime. For
the guidance, refer to 5.1.4.2.2 of [RFC6819]. It is RECOMMENDED the guidance, refer to 5.1.4.2.2 of [RFC6819] and Good Practices for
that it be removed after a reasonable timeout unless access control Capability URLs [CapURLs]. It is RECOMMENDED that it be removed
measures are taken. after a reasonable timeout unless access control measures are taken.
The following is an example of a Request Object URI value (with line The following is an example of a Request Object URI value (with line
wraps within values for display purposes only): wraps within values for display purposes only):
https://tfp.example.org/request.jwt# https://tfp.example.org/request.jwt/
GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM
5.2.2. Request using the "request_uri" Request Parameter 5.2.2. Request using the "request_uri" Request Parameter
The Client sends the Authorization Request to the Authorization The Client sends the Authorization Request to the Authorization
Endpoint. Endpoint.
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
%23GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM %2FGkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM
&state=af0ifjsldkj &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:
GET /request.jwt HTTP/1.1 GET /request.jwt/GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM HTTP/1.1
Host: tfp.example.org Host: tfp.example.org
The following is an example of the fetch response: The following is an example of the fetch response:
HTTP/1.1 200 OK HTTP/1.1 200 OK
Date: Thu, 16 Feb 2017 23:52:39 GMT Date: Thu, 16 Feb 2017 23:52:39 GMT
Server: Apache/2.2.22 (tfp.example.org) Server: Apache/2.2.22 (tfp.example.org)
Content-type: application/jwt Content-type: application/oauth.authz.req+jwt
Content-Length: 1250 Content-Length: 1250
Last-Modified: Wed, 15 Feb 2017 23:52:32 GMT Last-Modified: Wed, 15 Feb 2017 23:52:32 GMT
eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KICJpc3MiOiAiczZCaGRSa3 eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI6ICJzNkJoZF
F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsDQogInJl JrcXQzIiwKICAgICJhdWQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLAog
c3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWVudF9pZCI6ICJzNk ICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsCiAgICAiY2xpZW50X2
JoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8vY2xpZW50LmV4YW1w lkIjogInM2QmhkUmtxdDMiLAogICAgInJlZGlyZWN0X3VyaSI6ICJodHRwczovL2Ns
bGUub3JnL2NiIiwNCiAic2NvcGUiOiAib3BlbmlkIiwNCiAic3RhdGUiOiAiYWYwaW aWVudC5leGFtcGxlLm9yZy9jYiIsCiAgICAic2NvcGUiOiAib3BlbmlkIiwKICAgIC
Zqc2xka2oiLA0KICJub25jZSI6ICJuLTBTNl9XekEyTWoiLA0KICJtYXhfYWdlIjog JzdGF0ZSI6ICJhZjBpZmpzbGRraiIsCiAgICAibm9uY2UiOiAibi0wUzZfV3pBMk1q
ODY0MDAsDQogImNsYWltcyI6IA0KICB7DQogICAidXNlcmluZm8iOiANCiAgICB7DQ IiwKICAgICJtYXhfYWdlIjogODY0MDAKfQ.Nsxa_18VUElVaPjqW_ToI1yrEJ67BgK
ogICAgICJnaXZlbl9uYW1lIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgIm5p b5xsuZRVqzGkfKrOIX7BCx0biSxYGmjK9KJPctH1OC0iQJwXu5YVY-vnW0_PLJb1C2
Y2tuYW1lIjogbnVsbCwNCiAgICAgImVtYWlsIjogeyJlc3NlbnRpYWwiOiB0cnVlfS HG-ztVzcnKZC2gE4i0vgQcpkUOCpW3SEYXnyWnKzuKzqSb1wAZALo5f89B_p6QA6j6
wNCiAgICAgImVtYWlsX3ZlcmlmaWVkIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAg JwBSRvdVsDPdulW8lKxGTbH82czCaQ50rLAg3EYLYaCb4ik4I1zGXE4fvim9FIMs8O
ICAgInBpY3R1cmUiOiBudWxsDQogICAgfSwNCiAgICJpZF90b2tlbiI6IA0KICAgIH CMmzwIB5S-ujFfzwFjoyuPEV4hJnoVUmXR_W9typPf846lGwA8h9G9oNTIuX8Ft2jf
sNCiAgICAgImdlbmRlciI6IG51bGwsDQogICAgICJiaXJ0aGRhdGUiOiB7ImVzc2Vu pnZdFmLg3_wr3Wa5q3a-lfbgF3S9H_8nN3j1i7tLR_5Nz-g
dGlhbCI6IHRydWV9LA0KICAgICAiYWNyIjogeyJ2YWx1ZXMiOiBbInVybjptYWNlOm
luY29tbW9uOmlhcDpzaWx2ZXIiXX0NCiAgICB9DQogIH0NCn0.nwwnNsk1-Zkbmnvs
F6zTHm8CHERFMGQPhos-EJcaH4Hh-sMgk8ePrGhw_trPYs8KQxsn6R9Emo_wHwajyF
KzuMXZFSZ3p6Mb8dkxtVyjoy2GIzvuJT_u7PkY2t8QU9hjBcHs68PkgjDVTrG1uRTx
0GxFbuPbj96tVuj11pTnmFCUR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc8K
ol-cSLWoYE9l5QqholImzjT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLSjLLlxmPG
iyon_-Te111V8uE83IlzCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw
6. Validating JWT-Based Requests 6. Validating JWT-Based Requests
6.1. Encrypted Request Object 6.1. Encrypted Request Object
If the request object is encrypted, the Authorization Server MUST If the request object is encrypted, the Authorization Server MUST
decrypt the JWT in accordance with the JSON Web Encryption [RFC7516] decrypt the JWT in accordance with the JSON Web Encryption [RFC7516]
specification. specification.
The result is a signed request object. The result is a signed request object.
skipping to change at page 14, line 9 skipping to change at page 13, line 47
Client implementations supporting the Request Object URI method MUST Client implementations supporting the Request Object URI method MUST
support TLS following Recommendations for Secure Use of Transport support TLS following Recommendations for Secure Use of Transport
Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
[BCP195]. [BCP195].
To protect against information disclosure and tampering, To protect against information disclosure and tampering,
confidentiality protection MUST be applied using TLS with a cipher confidentiality protection MUST be applied using TLS with a cipher
suite that provides confidentiality and integrity protection. suite that provides confidentiality and integrity protection.
HTTP clients MUST also verify the TLS server certificate, using HTTP clients MUST also verify the TLS server certificate, using DNS-
subjectAltName dNSName identities as described in [RFC6125], to avoid ID [RFC6125], to avoid man-in-the-middle attacks. The rules and
man-in-the-middle attacks. The rules and guidelines defined in guidelines defined in [RFC6125] apply here, with the following
[RFC6125] apply here, with the following considerations: considerations:
o Support for DNS-ID identifier type (that is, the dNSName identity o Support for DNS-ID identifier type (that is, the dNSName identity
in the subjectAltName extension) is REQUIRED. Certification in the subjectAltName extension) is REQUIRED. Certification
authorities which issue server certificates MUST support the DNS- authorities which issue server certificates MUST support the DNS-
ID identifier type, and the DNS-ID identifier type MUST be present ID identifier type, and the DNS-ID identifier type MUST be present
in server certificates. in server certificates.
o DNS names in server certificates MAY contain the wildcard o DNS names in server certificates MAY contain the wildcard
character "*". character "*".
o Clients MUST NOT use CN-ID identifiers; a CN field may be present o Clients MUST NOT use CN-ID identifiers; a CN field may be present
in the server certificate's subject name, but MUST NOT be used for in the server certificate's subject name, but MUST NOT be used for
authentication within the rules described in [BCP195]. authentication within the rules described in [BCP195].
o SRV-ID and URI-ID as described in Section 6.5 of [RFC6125] MUST o SRV-ID and URI-ID as described in Section 6.5 of [RFC6125] MUST
NOT be used for comparison. NOT be used for comparison.
9. IANA Considerations 9. IANA Considerations
This specification requests no actions by IANA. 9.1. OAuth Parameters Registration
Since the request object is a JWT, the core JWT claims cannot be used
for any purpose in the request object other than for what JWT
dictates. Thus, they need to be registered to OAuth Parameter
Registry to avoid future OAuth extensions using them with different
meanings.
This specification adds the following values to the "OAuth
Parameters" registry established by [RFC6749].
o Claim Name: "iss"
o Claim Description: Issuer of the JWT
o Change Controller: IESG
o Specification Document(s): Section 4.1.1 of [RFC7519] and this
document.
o Claim Name: "sub"
o Claim Description: Subject of the JWT
o Change Controller: IESG
o Specification Document(s): Section 4.1.2 of [RFC7519] and this
document.
o Claim Name: "aud"
o Claim Description: Audience of the JWT
o Change Controller: IETF
o Specification Document(s): Section 4.1.3 of [RFC7519] and this
document.
o Claim Name: "exp"
o Claim Description: Expiry time of the JWT
o Change Controller: IETF
o Specification Document(s): Section 4.1.4 of [RFC7519] and this
document.
o Claim Name: "nbf"
o Claim Description: Not Before - The time the JWT is not valid
before
o Change Controller: IETF
o Specification Document(s): Section 4.1.5 of [RFC7519] and this
document.
o Claim Name: "iat"
o Claim Description: The time the JWT was issued at.
o Change Controller: IESG
o Specification Document(s): Section 4.1.6 of [RFC7519] and this
document.
o Claim Name: "jti"
o Claim Description: JWT Identifier
o Change Controller: IESG
o Specification Document(s): Section 4.1.7 of [RFC7519] and this
document.
9.2. Media Type Registration
9.2.1. Registry Contents
This section registers the "application/oauth.authz.req+jwt" media
type [RFC2046] in the "Media Types" registry [IANA.MediaTypes] in the
manner described in [RFC6838], which can be used to indicate that the
content is a JWT containing Request Object claims.
o Type name: application
o Subtype name: oauth.authz.req+jwt
o Required parameters: n/a
o Optional parameters: n/a
o Encoding considerations: binary; A Request OBject is a JWT; JWT
values are encoded as a series of base64url-encoded values (some
of which may be the empty string) separated by period ('.')
characters.
o Security considerations: See Section 10 of [[ this specification
]]
o Interoperability considerations: n/a
o Published specification: Section 4 of [[ this specification ]]
o Applications that use this media type: Applications that use
Request Objects to make an OAuth 2.0 Authorization Request
o Fragment identifier considerations: n/a
o Additional information:
Magic number(s): n/a
File extension(s): n/a
Macintosh file type code(s): n/a
o Person & email address to contact for further information:
Nat Sakimura, n-sakimura@nri.co.jp
o Intended usage: COMMON
o Restrictions on usage: none
o Author: Nat Sakimura, n-sakimura@nri.co.jp
o Change controller: IESG
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 and [RFC7518] needs to be considered. Also, there are several
academic papers such as [BASIN] that provide useful insight into the academic papers such as [BASIN] that provide useful insight into the
security properties of protocols like OAuth. 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 encrypted parameter, it MUST either be signed using JWS [RFC7515] or signed
using JWE [RFC7516] with then considered appropriate algorithm. then encrypted using JWS [RFC7515] and JWE [RFC7516] respectively,
with then considered appropriate algorithms.
10.2. Request Source Authentication 10.2. Request Source Authentication
The source of the Authorization Request MUST always be verified. The source of the Authorization Request MUST always be verified.
There are several ways to do it in this specification. There are several ways to do it in this specification.
(a) Verifying the JWS Signature of the Request Object. (a) Verifying the JWS Signature of the Request Object.
(b) Verifying that the symmetric key for the JWE encryption is the (b) Verifying that the symmetric key for the JWE encryption is the
correct one if the JWE is using symmetric encryption. correct one if the JWE is using symmetric encryption.
(c) Verifying the TLS Server Identity of the Request Object URI. In (c) Verifying the TLS Server Identity of the Request Object URI. In
this case, the Authorization Server MUST know out-of-band that this case, the Authorization Server MUST know out-of-band that
the Client uses Request Object URI and only the Client is the Client uses Request Object URI and only the Client is
covered by the TLS certificate. In general, it is not a covered by the TLS certificate. In general, it is not a
reliable method. reliable method.
(d) Authorization Server is providing an endpoint that provides a (d) When Authorization Server is providing an endpoint that provides
Request Object URI in exchange for a Request Object. In this a Request Object URI in exchange for a Request Object, the
case, the Authorization Server MUST perform Client Authorization Server MUST perform Client Authentication to
Authentication to accept the Request Object and bind the Client accept the Request Object and bind the Client Identifier to the
Identifier to the Request Object URI it is providing. Since Request Object URI it is providing. Since Request Object URI
Request Object URI can be replayed, the lifetime of the Request can be replayed, the lifetime of the Request Object URI MUST be
Object URI MUST be short and preferably one-time use. The short and preferably one-time use. The entropy of the Request
entropy of the Request Object URI MUST be sufficiently large. Object URI MUST be sufficiently large. The adequate shortness
The adequate shortness of the validity and the entropy of the of the validity and the entropy of the Request Object URI
Request Object URI depends on the risk calculation based on the depends on the risk calculation based on the value of the
value of the resource being protected. A general guidance for resource being protected. A general guidance for the validity
the validity time would be less than a minute and the Request time would be less than a minute and the Request Object URI is
Object URI is to include a cryptographic random value of 128bit to include a cryptographic random value of 128bit or more at the
or more at the time of the writing of this specification. time of the writing of this specification.
(e) A third party, such as a Trust Framework Provider, provides an (e) When a third party, such as a Trust Framework Provider(TFP),
endpoint that provides a Request Object URI in exchange for a provides an endpoint that provides a Request Object URI in
Request Object. The same requirements as (b) above apply. In exchange for a Request Object. The same requirements as (b) and
addition, the Authorization Server MUST know out-of-band that (c) above apply. In addition, the Authorization Server MUST
the Client utilizes the Trust Framework Operator. know out-of-band that the Client utilizes the Trust Framework
Operator and the Authorization Server MUST be a member of that
trust framework so that it can trust the TFP.
10.3. Explicit Endpoints 10.3. Explicit Endpoints
Although this specification does not require them, research such as Although this specification does not require them, research such as
[BASIN] points out that it is a good practice to explicitly state the [BASIN] points out that it is a good practice to explicitly state the
intended interaction endpoints and the message position in the intended interaction endpoints and the message position in the
sequence in a tamper evident manner so that the intent of the sequence in a tamper evident manner so that the intent of the
initiator is unambiguous. The endpoints that come into question in initiator is unambiguous. The following endpoints defined in
this specification are : [RFC6749], [RFC6750], and [RFC8414] are RECOMMENDED by this
specification to use this practice :
(a) Protected Resources ("protected_resources") (a) Protected Resources ("protected_resources")
(b) Authorization Endpoint ("authorization_endpoint") (b) Authorization Endpoint ("authorization_endpoint")
(c) Redirection URI ("redirect_uri") (c) Redirection URI ("redirect_uri")
(d) Token Endpoint ("token_endpoint") (d) Token Endpoint ("token_endpoint")
Further, if dynamic discovery is used, then the discovery related Further, if dynamic discovery is used, then this practice also
endpoints also come into question. applies to the discovery related endpoints.
In [RFC6749], while Redirection URI is included, others are not In [RFC6749], while Redirection URI is included in the Authorization
included in the Authorization Request. As the result, the same Request, others are not. As a result, the same applies to
applies to Authorization Request Object. Authorization Request Object.
The lack of the link among those endpoints are cited as the cause of The lack of the link among those endpoints are cited as the cause of
Cross-Phase Attacks introduced in [FETT]. An extension specification Cross-Phase Attacks introduced in [FETT]. An extension specification
should be created as a measure to address the risk. should be created as a measure to address the risk.
10.4. Risks Associated with request_uri 10.4. Risks Associated with request_uri
The introduction of "request_uri" introduces several attack The introduction of "request_uri" introduces several attack
possibilities. possibilities. Consult the security considerations in Section 7 of
RFC3986 [RFC3986] for more information regarding risks associated
with URIs.
10.4.1. DDoS Attack on the Authorization Server 10.4.1. DDoS Attack on the Authorization Server
A set of malicious client can launch a DoS attack to the A set of malicious client can launch a DoS attack to the
authorization server by pointing the "request_uri" to a uri that authorization server by pointing the "request_uri" to a uri that
returns extremely large content or extremely slow to respond. Under returns extremely large content or extremely slow to respond. Under
such an attack, the server may use up its resource and start failing. such an attack, the server may use up its resource and start failing.
Similarly, a malicious client can specify the "request_uri" value Similarly, a malicious client can specify the "request_uri" value
that itself points to an authorization request URI that uses that itself points to an authorization request URI that uses
"request_uri" to cause the recursive lookup. "request_uri" to cause the recursive lookup.
To prevent such attack to succeed, the server should (a) check that To prevent such attack to succeed, the server should (a) check that
the value of "request_uri" parameter does not point to an unexpected the value of "request_uri" parameter does not point to an unexpected
location, (b) check the content type of the response is "application/ location, (b) check the content type of the response is "application/
jwt" (c) implement a time-out for obtaining the content of oauth.authz.req+jwt" (c) implement a time-out for obtaining the
"request_uri", and (d) do not perform recursive GET on the content of "request_uri", and (d) not perform recursive GET on the
"request_uri". "request_uri".
10.4.2. Request URI Rewrite 10.4.2. Request URI Rewrite
The value of "request_uri" is not signed thus it can be tampered by The value of "request_uri" is not signed thus it can be tampered by
Man-in-the-browser attacker. Several attack possibilities rise Man-in-the-browser attacker. Several attack possibilities rise
because of this, e.g., (a) attacker may create another file that the because of this, e.g., (a) attacker may create another file that the
rewritten URI points to making it possible to request extra scope (b) rewritten URI points to making it possible to request extra scope (b)
attacker launches a DoS attack to a victim site by setting the value attacker launches a DoS attack to a victim site by setting the value
of "request_uri" to be that of the victim. of "request_uri" to be that of the victim.
To prevent such attack to succeed, the server should (a) check that To prevent such attack to succeed, the server should (a) check that
the value of "request_uri" parameter does not point to an unexpected the value of "request_uri" parameter does not point to an unexpected
location, (b) check the content type of the response is "application/ location, (b) check the content type of the response is "application/
jwt" (c) implement a time-out for obtaining the content of oauth.authz.req+jwt" (c) implement a time-out for obtaining the
"request_uri". content of "request_uri".
11. TLS security considerations 11. TLS security considerations
Current security considerations can be found in Recommendations for Current security considerations can be found in Recommendations for
Secure Use of TLS and DTLS [BCP195]. This supersedes the TLS version Secure Use of TLS and DTLS [BCP195]. This supersedes the TLS version
recommendations in OAuth 2.0 [RFC6749]. recommendations in OAuth 2.0 [RFC6749].
12. Privacy Considerations 12. Privacy Considerations
When the Client is being granted access to a protected resource When the Client is being granted access to a protected resource
skipping to change at page 17, line 45 skipping to change at page 19, line 39
containing personal data, the Client SHOULD limit the collection of containing personal data, the Client SHOULD limit the collection of
personal data to that which is within the bounds of applicable law personal data to that which is within the bounds of applicable law
and strictly necessary for the specified purpose(s). and strictly necessary for the specified purpose(s).
It is often hard for the user to find out if the personal data asked It is often hard for the user to find out if the personal data asked
for is strictly necessary. A Trust Framework Provider can help the for is strictly necessary. A Trust Framework Provider can help the
user by examining the Client request and comparing to the proposed user by examining the Client request and comparing to the proposed
processing by the Client and certifying the request. After the processing by the Client and certifying the request. After the
certification, the Client, when making an Authorization Request, can certification, the Client, when making an Authorization Request, can
submit Authorization Request to the Trust Framework Provider to submit Authorization Request to the Trust Framework Provider to
obtain the Request Object URI. obtain the Request Object URI. This process is two steps:
(1) (Certification Process) The TFP examines the business process of
the client and determines what claims they need: This is the
certification process. Once the client is certified, then they
are issued a client credential to authenticate against to push
request objects to the TFP to get the "request_uri".
(2) (Translation Process) The client uses the client credential that
it got to push the request object to the TFP to get the
"request_uri".
Upon receiving such Request Object URI in the Authorization Request, Upon receiving such Request Object URI in the Authorization Request,
the Authorization Server first verifies that the authority portion of the Authorization Server first verifies that the authority portion of
the Request Object URI is a legitimate one for the Trust Framework the Request Object URI is a legitimate one for the Trust Framework
Provider. Then, the Authorization Server issues HTTP GET request to Provider. Then, the Authorization Server issues HTTP GET request to
the Request Object URI. Upon connecting, the Authorization Server the Request Object URI. Upon connecting, the Authorization Server
MUST verify the server identity represented in the TLS certificate is MUST verify the server identity represented in the TLS certificate is
legitimate for the Request Object URI. Then, the Authorization legitimate for the Request Object URI. Then, the Authorization
Server can obtain the Request Object, which includes the "client_id" Server can obtain the Request Object, which includes the "client_id"
representing the Client. representing the Client.
skipping to change at page 18, line 39 skipping to change at page 20, line 43
the Request Object URI depends on the risk calculation based on the the Request Object URI depends on the risk calculation based on the
value of the resource being protected. A general guidance for the value of the resource being protected. A general guidance for the
validity time would be less than a minute and the Request Object URI validity time would be less than a minute and the Request Object URI
is to include a cryptographic random value of 128bit or more at the is to include a cryptographic random value of 128bit or more at the
time of the writing of this specification. time of the writing of this specification.
12.2.2. Tracking using Request Object URI 12.2.2. Tracking using Request Object URI
Even if the protected resource does not include a personally Even if the protected resource does not include a personally
identifiable information, it is sometimes possible to identify the identifiable information, it is sometimes possible to identify the
user through the Request Object URI if persistent per-user Request user through the Request Object URI if persistent static per-user
Object URI is used. A third party may observe it through browser Request Object URIs are used. A third party may observe it through
history etc. and start correlating the user's activity using it. In browser history etc. and start correlating the user's activity using
a way, it is a data disclosure as well and should be avoided. it. In a way, it is a data disclosure as well and should be avoided.
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) Jim Manico, Axel Nenker(Deutsche Telecom), Hannes Tschofenig
(ARM), Ben Campbell, Kathleen Moriarty (as AD), and Steve Kent (as (ARM), Ben Campbell, Dirk Balfanz (Google), James H. Manger
SECDIR). (Telstra), John Panzer (Google), David Recordon (Facebook), Marius
Scurtescu (Google), Luke Shepard (Facebook), 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).
In addition, the following people contributed to this and previous
versions through the OAuth Working Group.
Dirk Balfanz (Google), James H. Manger (Telstra), John Panzer
(Google), David Recordon (Facebook), Marius Scurtescu (Google), Luke
Shepard (Facebook).
14. Revision History 14. Revision History
Note to the RFC Editor: Please remove this section from the final Note to the RFC Editor: Please remove this section from the final
RFC. RFC.
-20
o BK comments
o Section 3 Removed WAP
o Section 4. Clarified authorization request object parameters,
removed extension parameters from examples
o Section 4. Specifies application/oauth.authz.req+jwt as mime-type
fore request objects
o Section 5.2.1 Added reference to Capability URLs
o Section 5.2.3. Added entrophy fragment to example request
o Section 8. Replaced "subjectAltName dnsName" with "DNS-ID"
o Section 9. Registers authorization request parameters in JWT
Claims Registry.
o Section 9. Registers application/oauth.authz.req in IANA mime-
types registry
o Section 10.1. Clarified encypted request objects are "signed then
encrypted" to maintain consistency
o Section 10.2. Clarifies trust between AS and TFP
o Section 10.3. Clarified endpoints subject to the practice
o Section 10.4 Replaced "redirect_uri" to "request_uri"
o Section 10.4. Added reference to RFC 3986 for risks
o Section 10.4.1.d Deleted "do" to maintain grammar flow
o Section 10.4.1, 10.4.2 Replaced "application/jose" to
"application/jwt"
o Section 12.1. Extended description for submitting authorization
request to TFP to obtain request objec
o Section 12.2.2. Replaced per-user Request Object URI with static
per-user Request URIs
o Section 13. Combined OAuth WG contributors together
o Section Whole doc Replaced application/jwt with application/
oauth.authz.req+jwt
-19 -19
o AD cooments o AD comments
o Section 5.2.1. s/Requiest URI/Request URI/ o Section 5.2.1. s/Requiest URI/Request URI/
o Section 8 s/[BCP195] ./[BCP195]./ o Section 8 s/[BCP195] ./[BCP195]./
o Section 10.3. s/sited/cited/ o Section 10.3. s/sited/cited/
o Section 11. Typo. s/Curent/Current/ o Section 11. Typo. s/Curent/Current/
-17 -17
skipping to change at page 25, line 4 skipping to change at page 28, line 6
-02 -02
o Now that they are RFCs, replaced JWS, JWE, etc. with RFC numbers. o Now that they are RFCs, replaced JWS, JWE, etc. with RFC numbers.
-01 -01
o Copy Edits. o Copy Edits.
15. References 15. References
15.1. Normative References 15.1. Normative References
[BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre, [BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, May 2015. (DTLS)", BCP 195, RFC 7525, May 2015.
[IANA.MediaTypes]
IANA, "Media Types",
<http://www.iana.org/assignments/media-types>.
[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>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>. 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
skipping to change at page 26, line 21 skipping to change at page 29, line 26
<https://www.rfc-editor.org/info/rfc7516>. <https://www.rfc-editor.org/info/rfc7516>.
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
DOI 10.17487/RFC7518, May 2015, DOI 10.17487/RFC7518, May 2015,
<https://www.rfc-editor.org/info/rfc7518>. <https://www.rfc-editor.org/info/rfc7518>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>. <https://www.rfc-editor.org/info/rfc7519>.
[RFC7636] Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key
for Code Exchange by OAuth Public Clients", RFC 7636,
DOI 10.17487/RFC7636, September 2015,
<https://www.rfc-editor.org/info/rfc7636>.
[RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names [RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names
(URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017, (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017,
<https://www.rfc-editor.org/info/rfc8141>. <https://www.rfc-editor.org/info/rfc8141>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259, Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017, DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>. <https://www.rfc-editor.org/info/rfc8259>.
[RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
Authorization Server Metadata", RFC 8414, Authorization Server Metadata", RFC 8414,
DOI 10.17487/RFC8414, June 2018, DOI 10.17487/RFC8414, June 2018,
<https://www.rfc-editor.org/info/rfc8414>. <https://www.rfc-editor.org/info/rfc8414>.
[RFC8485] Richer, J., Ed. and L. Johansson, "Vectors of Trust",
RFC 8485, DOI 10.17487/RFC8485, October 2018,
<https://www.rfc-editor.org/info/rfc8485>.
15.2. Informative References 15.2. Informative References
[BASIN] Basin, D., Cremers, C., and S. Meier, "Provably Repairing [BASIN] Basin, D., Cremers, C., and S. Meier, "Provably Repairing
the ISO/IEC 9798 Standard for Entity Authentication", the ISO/IEC 9798 Standard for Entity Authentication",
Journal of Computer Security - Security and Trust Journal of Computer Security - Security and Trust
Principles Volume 21 Issue 6, Pages 817-846, November Principles Volume 21 Issue 6, Pages 817-846, November
2013, 2013,
<https://www.cs.ox.ac.uk/people/cas.cremers/downloads/ <https://www.cs.ox.ac.uk/people/cas.cremers/downloads/
papers/BCM2012-iso9798.pdf>. papers/BCM2012-iso9798.pdf>.
[CapURLs] Tennison, J., "Good Practices for Capability URLs",
W3C Working Draft, February 2014,
<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://infsec.uni-
trier.de/people/publications/paper/ trier.de/people/publications/paper/FettKuestersSchmitz-
FettKuestersSchmitz-CCS-2016.pdf>. CCS-2016.pdf>.
[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
Extensions (MIME) Part Two: Media Types", RFC 2046,
DOI 10.17487/RFC2046, November 1996,
<https://www.rfc-editor.org/info/rfc2046>.
[RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 [RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0
Threat Model and Security Considerations", RFC 6819, Threat Model and Security Considerations", RFC 6819,
DOI 10.17487/RFC6819, January 2013, DOI 10.17487/RFC6819, January 2013,
<https://www.rfc-editor.org/info/rfc6819>. <https://www.rfc-editor.org/info/rfc6819>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013,
<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>.
Authors' Addresses Authors' Addresses
Nat Sakimura Nat Sakimura
Nomura Research Institute Nomura Research Institute
 End of changes. 54 change blocks. 
192 lines changed or deleted 359 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/