draft-ietf-oauth-jwt-introspection-response-00.txt   draft-ietf-oauth-jwt-introspection-response-01.txt 
Open Authentication Protocol T. Lodderstedt, Ed. Open Authentication Protocol T. Lodderstedt, Ed.
Internet-Draft YES.com AG Internet-Draft YES.com AG
Intended status: Standards Track V. Dzhuvinov Intended status: Standards Track V. Dzhuvinov
Expires: February 6, 2019 Connect2id Ltd. Expires: February 23, 2019 Connect2id Ltd.
August 05, 2018 August 22, 2018
JWT Response for OAuth Token Introspection JWT Response for OAuth Token Introspection
draft-ietf-oauth-jwt-introspection-response-00 draft-ietf-oauth-jwt-introspection-response-01
Abstract Abstract
This draft proposes an additional JSON Web Token (JWT) based response This draft proposes an additional JSON Web Token (JWT) based response
for OAuth 2.0 Token Introspection. for OAuth 2.0 Token Introspection.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 32 skipping to change at page 1, line 32
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 February 6, 2019. This Internet-Draft will expire on February 23, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 28 skipping to change at page 3, line 28
token=2YotnFZFEjr1zCsicMWpAA token=2YotnFZFEjr1zCsicMWpAA
3. JWT Response 3. JWT Response
The introspection endpoint responds with a JWT, setting the Content- The introspection endpoint responds with a JWT, setting the Content-
Type header to "application/jwt". Type header to "application/jwt".
This JWT MUST contain the claims "iss" and "aud" in order to prevent This JWT MUST contain the claims "iss" and "aud" in order to prevent
misuse of the JWT as ID or access token (see Section 6.1). misuse of the JWT as ID or access token (see Section 6.1).
This JWT may furthermore contain all other claims described in This JWT MAY furthermore contain all other claims described in
Section 2.2. of [RFC7662]. Section 2.2. of [RFC7662] and beyond (e.g. as defined in
[OpenID.Core]).
The following is a non-normative example response (with line breaks The following is a non-normative example response (with line breaks
for display purposes only): for display purposes only):
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/jwt Content-Type: application/jwt
eyJraWQiOiIxIiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiJaNU8zdXBQQzg4UXJBa eyJraWQiOiIxIiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiJaNU8zdXBQQzg4UXJBa
ngwMGRpcyIsImF1ZCI6Imh0dHBzOlwvXC9wcm90ZWN0ZWQuZXhhbXBsZS5uZXRcL ngwMGRpcyIsImF1ZCI6Imh0dHBzOlwvXC9wcm90ZWN0ZWQuZXhhbXBsZS5uZXRcL
3Jlc291cmNlIiwiZXh0ZW5zaW9uX2ZpZWxkIjoidHdlbnR5LXNldmVuIiwic2Nvc 3Jlc291cmNlIiwiZXh0ZW5zaW9uX2ZpZWxkIjoidHdlbnR5LXNldmVuIiwic2Nvc
skipping to change at page 4, line 25 skipping to change at page 4, line 25
"family_name":"Doe", "family_name":"Doe",
"birthdate":"1982-02-01" "birthdate":"1982-02-01"
} }
Depending on the specific resource server policy the JWT is either Depending on the specific resource server policy the JWT is either
signed, or signed and encrypted. If the JWT is signed and encrypted signed, or signed and encrypted. If the JWT is signed and encrypted
it MUST be a Nested JWT, as defined in JWT [RFC7519]. it MUST be a Nested JWT, as defined in JWT [RFC7519].
Note: If the resource server policy requires a signed and encrypted Note: If the resource server policy requires a signed and encrypted
response and the authorization server receives an unauthenticated response and the authorization server receives an unauthenticated
request containing an Accept header with content type "application/ request containing an Accept header with content type other than
json", it MUST refuse to serve the request and return an HTTP status "application/jwt", it MUST refuse to serve the request and return an
code 400. This is done to prevent downgrading attacks to obtain HTTP status code 400. This is done to prevent downgrading attacks to
token data intended for release to legitimate recipients only (which obtain token data intended for release to legitimate recipients only
possess the respective decryption key). (see Section 6.2).
4. Client Metadata 4. Client Metadata
The authorization server determines what algorithm to employ to The authorization server determines what algorithm to employ to
secure the JWT for a particular introspection response. This secure the JWT for a particular introspection response. This
decision can be based on registered metadata parameters for the decision can be based on registered metadata parameters for the
resource server, supplied via dynamic client registration with the resource server, supplied via dynamic client registration with the
resource server posing as the client, as defined by this draft. resource server posing as the client, as defined by this draft.
The parameter names follow the pattern established by OpenID Connect The parameter names follow the pattern established by OpenID Connect
Dynamic Client Registration [OpenID.Registration] for configuring Dynamic Client Registration [OpenID.Registration] for configuring
signing and encryption algorithms for JWT responses at the UserInfo signing and encryption algorithms for JWT responses at the UserInfo
endpoint. endpoint.
The following client metadata parameters are introduced by this The following client metadata parameters are introduced by this
specification: specification:
introspection_signed_response_alg JWS [RFC7515] "alg" algorithm JWA introspection_signed_response_alg JWS [RFC7515] "alg" algorithm JWA
[RFC7518] REQUIRED for signing introspection responses. If [RFC7518] REQUIRED for signing introspection responses. If
this is specified, the response will be signed using JWS and this is specified, the response will be signed using JWS and
the configured algorithm. The default, if omitted, is RSA the configured algorithm. The default, if omitted, is
SHA-256. "RS256".
introspection_encrypted_response_alg JWE [RFC7516] "alg" algorithm introspection_encrypted_response_alg JWE [RFC7516] "alg" algorithm
JWA [RFC7518] REQUIRED for encrypting introspection JWA [RFC7518] REQUIRED for encrypting introspection
responses. If both signing and encryption are requested, the responses. If both signing and encryption are requested, the
response will be signed then encrypted, with the result being response will be signed then encrypted, with the result being
a Nested JWT, as defined in JWT [RFC7519]. The default, if a Nested JWT, as defined in JWT [RFC7519]. The default, if
omitted, is that no encryption is performed. omitted, is that no encryption is performed.
introspection_encrypted_response_enc JWE [RFC7516] "enc" algorithm introspection_encrypted_response_enc JWE [RFC7516] "enc" algorithm
JWA [RFC7518] REQUIRED for encrypting introspection JWA [RFC7518] REQUIRED for encrypting introspection
skipping to change at page 6, line 36 skipping to change at page 6, line 36
If the authorization server supports unauthenticated requests an If the authorization server supports unauthenticated requests an
attacker could potentially retrieve token data which must be kept attacker could potentially retrieve token data which must be kept
confidential. This attack can be prevented by either authenticating confidential. This attack can be prevented by either authenticating
any request to the token introspection endpoint or by setting up the any request to the token introspection endpoint or by setting up the
respective recipient for encrypted responses. respective recipient for encrypted responses.
In the latter case, confidentiality is ensured by the fact that only In the latter case, confidentiality is ensured by the fact that only
the legitimate recipient is able to decrypt the response. An the legitimate recipient is able to decrypt the response. An
attacker could try to circumvent this measure by requesting a plain attacker could try to circumvent this measure by requesting a plain
JSON response, using an Accept header with the content type set to JSON response, using an Accept header with the content type set to,
"application/json" instead of "application/jwt". To prevent this for example, "application/json" instead of "application/jwt". To
attack the authorization server MUST not serve requests with content prevent this attack the authorization server MUST NOT serve requests
type "application/json" if the resource server is set up to receive with content type other than "application/jwt" if the resource server
encrypted responses (see also Section 3). is set up to receive encrypted responses (see also Section 3).
7. Acknowledgements 7. Acknowledgements
We would like to thank Petteri Stenius, Neil Madden, Filip Skokan, We would like to thank Petteri Stenius, Neil Madden, Filip Skokan,
and Tony Nadalin for their valuable feedback. and Tony Nadalin for their valuable feedback.
8. IANA Considerations 8. IANA Considerations
8.1. OAuth Dynamic Client Registration Metadata Registration 8.1. OAuth Dynamic Client Registration Metadata Registration
This specification requests registration of the following client This specification requests registration of the following client
skipping to change at page 10, line 20 skipping to change at page 10, line 20
9.2. Informative References 9.2. Informative References
[IANA.OAuth.Parameters] [IANA.OAuth.Parameters]
IANA, "OAuth Parameters", IANA, "OAuth Parameters",
<http://www.iana.org/assignments/oauth-parameters>. <http://www.iana.org/assignments/oauth-parameters>.
Appendix A. Document History Appendix A. Document History
[[ To be removed from the final specification ]] [[ To be removed from the final specification ]]
-01
o adapted wording to preclude any accept header except "application/
jwt" if encrypted responses are required
o use registered alg value RS256 for default signing algorithm
o added text on claims in the token introspection response
-00 -00
o initial version of the WG draft o initial version of the WG draft
o defined default signing algorithm o defined default signing algorithm
o changed behavior in case resource server is set up for encryption o changed behavior in case resource server is set up for encryption
o Added text on token data leakage prevention to the security o Added text on token data leakage prevention to the security
considerations considerations
 End of changes. 8 change blocks. 
18 lines changed or deleted 28 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/