draft-ietf-oauth-introspection-10.txt   draft-ietf-oauth-introspection-11.txt 
OAuth Working Group J. Richer, Ed. OAuth Working Group J. Richer, Ed.
Internet-Draft June 22, 2015 Internet-Draft July 3, 2015
Intended status: Standards Track Intended status: Standards Track
Expires: December 24, 2015 Expires: January 4, 2016
OAuth 2.0 Token Introspection OAuth 2.0 Token Introspection
draft-ietf-oauth-introspection-10 draft-ietf-oauth-introspection-11
Abstract Abstract
This specification defines a method for a protected resource to query This specification defines a method for a protected resource to query
an OAuth 2.0 authorization server to determine the active state of an an OAuth 2.0 authorization server to determine the active state of an
OAuth 2.0 token and to determine meta-information about this token. OAuth 2.0 token and to determine meta-information about this token.
OAuth 2.0 deployments can use this method to convey information about OAuth 2.0 deployments can use this method to convey information about
the authorization context of the token from the authorization server the authorization context of the token from the authorization server
to the protected resource. to the protected resource.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 24, 2015. This Internet-Draft will expire on January 4, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 4, line 48 skipping to change at page 4, line 48
token_type_hint OPTIONAL. A hint about the type of the token token_type_hint OPTIONAL. A hint about the type of the token
submitted for introspection. The protected resource MAY pass this submitted for introspection. The protected resource MAY pass this
parameter to help the authorization server to optimize the token parameter to help the authorization server to optimize the token
lookup. If the server is unable to locate the token using the lookup. If the server is unable to locate the token using the
given hint, it MUST extend its search across all of its supported given hint, it MUST extend its search across all of its supported
token types. An authorization server MAY ignore this parameter, token types. An authorization server MAY ignore this parameter,
particularly if it is able to detect the token type automatically. particularly if it is able to detect the token type automatically.
Values for this field are defined in the OAuth Token Type Hints Values for this field are defined in the OAuth Token Type Hints
registry defined in OAuth Token Revocation [RFC7009]. registry defined in OAuth Token Revocation [RFC7009].
The endpoint MAY accept other OPTIONAL parameters to provide further The introspection endpoint MAY accept other OPTIONAL parameters to
context to the query. For instance, an authorization server may provide further context to the query. For instance, an authorization
desire to know the IP address of the client accessing the protected server may desire to know the IP address of the client accessing the
resource to determine the appropriateness of the token being protected resource to determine if the correct client is likely to be
presented. The definition of any other parameters are outside the presenting the token. The definition of this or any other parameters
scope of this specification, to be defined by service documentation are outside the scope of this specification, to be defined by service
or extensions to this specification. If the authorization server is documentation or extensions to this specification. If the
unable to determine the state of the token without additional authorization server is unable to determine the state of the token
information, it SHOULD return an introspection response indicating without additional information, it SHOULD return an introspection
the token is not active as described in Section 2.2. response indicating the token is not active as described in
Section 2.2.
To prevent token scanning attacks, the endpoint MUST also require To prevent token scanning attacks, the endpoint MUST also require
some form of authorization to access this endpoint, such as client some form of authorization to access this endpoint, such as client
authentication as described in OAuth 2.0 [RFC6749] or a separate authentication as described in OAuth 2.0 [RFC6749] or a separate
OAuth 2.0 access token such as the bearer token described in OAuth OAuth 2.0 access token such as the bearer token described in OAuth
2.0 Bearer Token Usage [RFC6750]. The methods of managing and 2.0 Bearer Token Usage [RFC6750]. The methods of managing and
validating these authentication credentials are out of scope of this validating these authentication credentials are out of scope of this
specification. specification.
For example, the following example shows a protected resource calling For example, the following example shows a protected resource calling
skipping to change at page 14, line 21 skipping to change at page 14, line 21
The introspection response may contain privacy-sensitive information The introspection response may contain privacy-sensitive information
such as user identifiers for resource owners. When this is the case, such as user identifiers for resource owners. When this is the case,
measures MUST be taken to prevent disclosure of this information to measures MUST be taken to prevent disclosure of this information to
unintended parties. One method is to transmit user identifiers as unintended parties. One method is to transmit user identifiers as
opaque service-specific strings, potentially returning different opaque service-specific strings, potentially returning different
identifiers to each protected resource. identifiers to each protected resource.
If the protected resource sends additional information about the If the protected resource sends additional information about the
client's request to the authorization server (such as the client's IP client's request to the authorization server (such as the client's IP
address) using an extension of this specification, such information address) using an extension of this specification, such information
could have additional privacy considerations. However, the nature could have additional privacy considerations that the extension
and implications of such extensions are outside the scope of this should detail. However, the nature and implications of such
specification. extensions are outside the scope of this specification.
Omitting privacy-sensitive information from an introspection response Omitting privacy-sensitive information from an introspection response
is the simplest way of minimizing privacy issues. is the simplest way of minimizing privacy issues.
6. Acknowledgements 6. Acknowledgements
Thanks to the OAuth Working Group and the User Managed Access Working Thanks to the OAuth Working Group and the User Managed Access Working
Group for feedback and review of this document, and to the various Group for feedback and review of this document, and to the various
implementors of both the client and server components of this implementors of both the client and server components of this
specification. In particular, the author would like to thank Amanda specification. In particular, the author would like to thank Amanda
skipping to change at page 16, line 12 skipping to change at page 16, line 12
identifier to the authorization server's token endpoint to obtain the identifier to the authorization server's token endpoint to obtain the
necessary key information needed to validate the signature on the necessary key information needed to validate the signature on the
request. The details of this usage are outside the scope of this request. The details of this usage are outside the scope of this
specification and will be defined in an extension to this specification and will be defined in an extension to this
specification. specification.
Appendix B. Document History Appendix B. Document History
[[ To be removed by the RFC Editor. ]] [[ To be removed by the RFC Editor. ]]
-11
o Minor wording tweaks from IESG review.
-10 -10
o Added missing 2119 section to terminology. o Added missing 2119 section to terminology.
o Removed optional HTTP GET at introspection endpoint. o Removed optional HTTP GET at introspection endpoint.
o Added terminology. o Added terminology.
o Renamed this "a protocol" instead of "web API". o Renamed this "a protocol" instead of "web API".
o Moved JWT to normative reference. o Moved JWT to normative reference.
o Reworded definition of "scope" value. o Reworded definition of "scope" value.
o Clarified extensibility of input parameters. o Clarified extensibility of input parameters.
o Noted that discover is out of scope. o Noted that discover is out of scope.
 End of changes. 7 change blocks. 
17 lines changed or deleted 22 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/