draft-ietf-oauth-jwt-introspection-response-02.txt   draft-ietf-oauth-jwt-introspection-response-03.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: August 23, 2019 Connect2id Ltd. Expires: November 22, 2019 Connect2id Ltd.
February 19, 2019 May 21, 2019
JWT Response for OAuth Token Introspection JWT Response for OAuth Token Introspection
draft-ietf-oauth-jwt-introspection-response-02 draft-ietf-oauth-jwt-introspection-response-03
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 August 23, 2019. This Internet-Draft will expire on November 22, 2019.
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 22 skipping to change at page 2, line 22
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6.1. Cross-JWT Confusion . . . . . . . . . . . . . . . . . . . 5 6.1. Cross-JWT Confusion . . . . . . . . . . . . . . . . . . . 5
6.2. Token Data Leakage . . . . . . . . . . . . . . . . . . . 6 6.2. Token Data Leakage . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8.1. OAuth Dynamic Client Registration Metadata Registration . 7 8.1. OAuth Dynamic Client Registration Metadata Registration . 7
8.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 7 8.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 7
8.2. OAuth Authorization Server Metadata Registration . . . . 7 8.2. OAuth Authorization Server Metadata Registration . . . . 7
8.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 7 8.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 7
8.3. OAuth Token Introspection Response . . . . . . . . . . . 8 8.3. OAuth Token Introspection Response . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Document History . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Appendix A. Document History . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
OAuth 2.0 Token Introspection [RFC7662] specifies a method for a OAuth 2.0 Token Introspection [RFC7662] specifies a method for a
protected resource to query an OAuth 2.0 authorization server to protected resource to query an OAuth 2.0 authorization server to
determine the state of an access token and obtain data associated determine the state of an access token and obtain data associated
with the access token. This allows deployments to implement with the access token. This allows deployments to implement
identifier-based access tokens in an interoperable way. identifier-based access tokens in an interoperable way.
The introspection response, as specified in OAuth 2.0 Token The introspection response, as specified in OAuth 2.0 Token
skipping to change at page 7, line 41 skipping to change at page 7, line 41
o Client Metadata Description: String value specifying the desired o Client Metadata Description: String value specifying the desired
introspection response encryption algorithm (enc value). introspection response encryption algorithm (enc value).
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 4 of [[ this specification ]] o Specification Document(s): Section 4 of [[ this specification ]]
8.2. OAuth Authorization Server Metadata Registration 8.2. OAuth Authorization Server Metadata Registration
This specification requests registration of the following value in This specification requests registration of the following values in
the IANA "OAuth Authorization Server Metadata" registry the IANA "OAuth Authorization Server Metadata" registry
[IANA.OAuth.Parameters] established by [RFC8414]. [IANA.OAuth.Parameters] established by [RFC8414].
8.2.1. Registry Contents 8.2.1. Registry Contents
o Metadata Name: "introspection_signing_alg_values_supported" o Metadata Name: "introspection_signing_alg_values_supported"
o Metadata Description: JSON array containing a list of algorithms o Metadata Description: JSON array containing a list of algorithms
supported by the authorization server for introspection response supported by the authorization server for introspection response
signing. signing.
skipping to change at page 8, line 31 skipping to change at page 8, line 31
o Metadata Description: JSON array containing a list of algorithms o Metadata Description: JSON array containing a list of algorithms
supported by the authorization server for introspection response supported by the authorization server for introspection response
encryption (enc value). encryption (enc value).
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 5 of [[ this specification ]] o Specification Document(s): Section 5 of [[ this specification ]]
8.3. OAuth Token Introspection Response 8.3. OAuth Token Introspection Response
TBD: add all OpenID Connect standard claims. This specification requests registration of the following claim
values as defined in [OpenID.Core], Section 5.1, in the IANA "OAuth
Token Introspection Response" registry. [IANA.OAuth.Parameters]
established by [RFC8414].
8.3.1. Registry Contents
o Name: "name"
o Description: End-User's full name in displayable form including
all name parts, possibly including titles and suffixes, ordered
according to the End-User's locale and preferences.
o Change Controller: IESG
o Specification Document(s):[OpenID.Core], Section 5.1
o Name: "given_name"
o Description: Given name(s) or first name(s) of the End-User. Note
that in some cultures, people can have multiple given names; all
can be present, with the names being separated by space
characters.
o Change Controller: IESG
o Specification Document(s):[OpenID.Core], Section 5.1
o Name: "family_name"
o Description: Surname(s) or last name(s) of the End-User. Note
that in some cultures, people can have multiple family names or no
family name; all can be present, with the names being separated by
space characters.
o Change Controller: IESG
o Specification Document(s):[OpenID.Core], Section 5.1
o Name: "middle_name"
o Description: Middle name(s) of the End-User. Note that in some
cultures, people can have multiple middle names; all can be
present, with the names being separated by space characters. Also
note that in some cultures, middle names are not used.
o Change Controller: IESG
o Specification Document(s):[OpenID.Core], Section 5.1
o Name: "nickname"
o Description: Casual name of the End-User that may or may not be
the same as the given_name. For instance, a nickname value of
Mike might be returned alongside a given_name value of Michael.
o Change Controller: IESG
o Specification Document(s):[OpenID.Core], Section 5.1
o Name: "preferred_username"
o Description: Shorthand name by which the End-User wishes to be
referred to at the RP, such as janedoe or j.doe. This value MAY
be any valid JSON string including special characters such as @,
/, or whitespace.
o Change Controller: IESG
o Specification Document(s):[OpenID.Core], Section 5.1
o Name: "profile"
o Description:URL of the End-User's profile page. The contents of
this Web page SHOULD be about the End-User.
o Change Controller: IESG
o Specification Document(s):[OpenID.Core], Section 5.1
o Name: "picture"
o Description: URL of the End-User's profile picture. This URL MUST
refer to an image file (for example, a PNG, JPEG, or GIF image
file), rather than to a Web page containing an image. Note that
this URL SHOULD specifically reference a profile photo of the End-
User suitable for displaying when describing the End-User, rather
than an arbitrary photo taken by the End-User.
o Change Controller: IESG
o Specification Document(s):[OpenID.Core], Section 5.1
o Name: "website"
o Description: URL of the End-User's Web page or blog. This Web
page SHOULD contain information published by the End-User or an
organization that the End-User is affiliated with.
o Change Controller: IESG
o Specification Document(s):[OpenID.Core], Section 5.1
o Name: "email"
o Description: End-User's preferred e-mail address. Its value MUST
conform to the RFC 5322 [RFC5322] addr-spec syntax.
o Change Controller: IESG
o Specification Document(s):[OpenID.Core], Section 5.1
o Name: "email_verified"
o Description: True if the End-User's e-mail address has been
verified; otherwise false. When this Claim Value is true, this
means that the OP took affirmative steps to ensure that this
e-mail address was controlled by the End-User at the time the
verification was performed. The means by which an e-mail address
is verified is context-specific, and dependent upon the trust
framework or contractual agreements within which the parties are
operating.
o Change Controller: IESG
o Specification Document(s):[OpenID.Core], Section 5.1
o Name: "gender"
o Description:End-User's gender. Values defined by this
specification are female and male. Other values MAY be used when
neither of the defined values are applicable.
o Change Controller: IESG
o Specification Document(s):[OpenID.Core], Section 5.1
o Name: "birthdate"
o Description:Time the End-User's information was last updated. Its
value is a JSON number representing the number of seconds from
1970-01-01T0:0:0Z as measured in UTC until the date/time.
o Change Controller: IESG
o Specification Document(s):[OpenID.Core], Section 5.1
o Name: "zoneinfo"
o Description: String from zoneinfo [zoneinfo] time zone database
representing the End-User's time zone. For example, Europe/Paris
or America/Los_Angeles.
o Change Controller: IESG
o Specification Document(s):[OpenID.Core], Section 5.1
o Name: "locale"
o Description: Time the End-User's information was last updated.
Its value is a JSON number representing the number of seconds from
1970-01-01T0:0:0Z as measured in UTC until the date/time.
o Change Controller: IESG
o Specification Document(s):[OpenID.Core], Section 5.1
o Name: "phone_number"
o Description: End-User's preferred telephone number. E.164 [E.164]
is RECOMMENDED as the format of this Claim, for example, +1 (425)
555-1212 or +56 (2) 687 2400. If the phone number contains an
extension, it is RECOMMENDED that the extension be represented
using the RFC 3966 [RFC3966] extension syntax, for example, +1
(604) 555-1234;ext=5678.
o Change Controller: IESG
o Specification Document(s):[OpenID.Core], Section 5.1
o Name: "phone_number_verified"
o Description: True if the End-User's phone number has been
verified; otherwise false. When this Claim Value is true, this
means that the OP took affirmative steps to ensure that this phone
number was controlled by the End-User at the time the verification
was performed. The means by which a phone number is verified is
context-specific, and dependent upon the trust framework or
contractual agreements within which the parties are operating.
When true, the phone_number Claim MUST be in E.164 format and any
extensions MUST be represented in RFC 3966 format.
o Change Controller: IESG
o Specification Document(s):[OpenID.Core], Section 5.1
o Name: "address"
o Description: End-User's preferred postal address. The value of
the address member is a JSON [RFC4627] structure containing some
or all of the members defined in [OpenID.Core],Section 5.1.1.
o Change Controller: IESG
o Specification Document(s):[OpenID.Core], Section 5.1
o Name: "updated_at"
o Description: Time the End-User's information was last updated.
Its value is a JSON number representing the number of seconds from
1970-01-01T0:0:0Z as measured in UTC until the date/time.
o Change Controller: IESG
o Specification Document(s):[OpenID.Core], Section 5.1
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-oauth-jwt-bcp] [I-D.ietf-oauth-jwt-bcp]
Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best
Current Practices", draft-ietf-oauth-jwt-bcp-04 (work in Current Practices", draft-ietf-oauth-jwt-bcp-04 (work in
progress), November 2018. progress), November 2018.
[I-D.ietf-oauth-security-topics] [I-D.ietf-oauth-security-topics]
Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett, Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett,
"OAuth 2.0 Security Best Current Practice", draft-ietf- "OAuth 2.0 Security Best Current Practice", draft-ietf-
oauth-security-topics-11 (work in progress), December oauth-security-topics-11 (work in progress), December
2018. 2018.
[OpenID.Core] [OpenID.Core]
NRI, Ping Identity, Microsoft, Google, and Salesforce, Sakimura, N., Bradley, J., Jones, M., Medeiros, B. D., and
"OpenID Connect Core 1.0 incorporating errata set 1", Nov C. Mortimore, "OpenID Connect Core 1.0 incorporating
2014, errata set 1", Nov 2014,
<http://openid.net/specs/openid-connect-core-1_0.html>. <http://openid.net/specs/openid-connect-core-1_0.html>.
[OpenID.Registration] [OpenID.Registration]
NRI, Ping Identity, and Microsoft, "OpenID Connect Dynamic Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect
Client Registration 1.0 incorporating errata set 1", Nov Dynamic Client Registration 1.0 incorporating errata set
2014, <https://openid.net/specs/ 1", Nov 2014, <https://openid.net/specs/
openid-connect-registration-1_0.html>. openid-connect-registration-1_0.html>.
[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>.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, DOI 10.17487/RFC2246, January 1999, RFC 2246, DOI 10.17487/RFC2246, January 1999,
<https://www.rfc-editor.org/info/rfc2246>. <https://www.rfc-editor.org/info/rfc2246>.
skipping to change at page 10, line 15 skipping to change at page 14, line 37
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 ]]
-03
o added registration for OpenID Connect Standard Claims to OAuth
Token Introspection Response registry
-02 -02
o updated references o updated references
-01 -01
o adapted wording to preclude any accept header except "application/ o adapted wording to preclude any accept header except "application/
jwt" if encrypted responses are required jwt" if encrypted responses are required
o use registered alg value RS256 for default signing algorithm o use registered alg value RS256 for default signing algorithm
 End of changes. 9 change blocks. 
17 lines changed or deleted 234 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/