+1 to defining RS-AS interactions. We've implemented such a 'token
introspection' endpoint in our AS and I'm be happy to no longer need to
explain to customers/partners why it's not part of the standard.
As input, an (incomplete) spec for our endpoint enclosed. (we modeled
the verification as a new grant type, leveraging as much as possible the
existing token endpoint API)
Wrt the 5 item limit
1) is this an arbitrary #? if people sign up to work on more items,
could it be extended?
2) the use cases document seems already well progressed (and
informational). Need it count against the 5?
paul
On 3/14/12 5:53 PM, Richer, Justin P. wrote:
Methods of connecting the PR to the AS are something that several groups have
invented outside of the OAuth WG, and I think we should try to pull some of
this work together. OAuth2 gives us a logical separation of the concerns but
not a way to knit them back together.
Proposals for inclusion in the discussion include UMA's Step 3, OpenID Connect's CheckID,
and several "token introspection" endpoints in various implementations.
-- Justin
On Mar 14, 2012, at 4:21 PM, Hannes Tschofenig wrote:
So, here is a proposal:
-------
Web Authorization Protocol (oauth)
Description of Working Group
The Web Authorization (OAuth) protocol allows a user to grant
a third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that supports
OAuth could allow its users to use a third-party printing Web site to
print their private pictures, without allowing the printing site to
gain full control of the user's account and without having the user
sharing his or her photo-sharing sites' long-term credential with the
printing site.
The OAuth protocol suite encompasses
* a procedure for allowing a client to discover a resource server,
* a protocol for obtaining authorization tokens from an authorization
server with the resource owner's consent,
* protocols for presenting these authorization tokens to protected
resources for access to a resource, and
* consequently for sharing data in a security and privacy respective way.
In April 2010 the OAuth 1.0 specification, documenting pre-IETF work,
was published as an informational document (RFC 5849). With the
completion of OAuth 1.0 the working group started their work on OAuth 2.0
to incorporate implementation experience with version 1.0, additional
use cases, and various other security, readability, and interoperability
improvements. An extensive security analysis was conducted and the result
is available as a stand-alone document offering guidance for audiences
beyond the community of protocol implementers.
The working group also developed security schemes for presenting authorization
tokens to access a protected resource. This led to the publication of
the bearer token as well as the message authentication code (MAC) access
authentication specification.
OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH token
with
the SAML 2.0 bearer assertion profile. This offers interworking with existing
identity management solutions, in particular SAML based deployments.
OAuth has enjoyed widespread adoption by the Internet application service
provider
community. To build on this success we aim for nothing more than to make OAuth
the
authorization framework of choice for any Internet protocol. Consequently, the
ongoing standardization effort within the OAuth working group is focused on
enhancing interoperability of OAuth deployments. While the core OAuth
specification
truly is an important building block it relies on other specifications in order
to
claim completeness. Luckily, these components already exist and have been
deployed
on the Internet. Through the IETF standards process they will be improved in
quality and will undergo a rigorous review process.
Goals and Milestones
[Editor's Note: Here are the completed items.]
Done Submit 'OAuth 2.0 Threat Model and Security Considerations' as a
working group item
Done Submit 'HTTP Authentication: MAC Authentication' as a working group item
Done Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for
consideration as a Proposed Standard
Done Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for
consideration as a Proposed Standard
[Editor's Note: Finishing existing work. Double-check the proposed dates - are
they realistic?]
Jun. 2012 Submit 'HTTP Authentication: MAC Authentication' to the IESG
for consideration as a Proposed Standard
Apr. 2012 Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' to
the IESG for consideration as a Proposed Standard
Apr. 2012 Submit 'OAuth 2.0 Assertion Profile' to the IESG for consideration
as a Proposed Standard
Apr. 2012 Submit 'An IETF URN Sub-Namespace for OAuth' to the IESG for
consideration as a Proposed Standard
May 2012 Submit 'OAuth 2.0 Threat Model and Security Considerations' to the
IESG for consideration as an Informational RFC
[Editor's Note: New work for the group. 5 items maximum! ]
Aug. 2012 Submit 'Token Revocation' to the IESG for consideration as a
Proposed Standard
[Starting point for the work will be
http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/]
Nov. 2012 Submit 'JSON Web Token (JWT)' to the IESG for consideration as a
Proposed Standard
[Starting point for the work will be
http://tools.ietf.org/html/draft-jones-json-web-token]
Nov. 2012 Submit 'JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0'
to the IESG for consideration as a Proposed Standard
[Starting point for the work will be
http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer]
Jan. 2013 Submit 'OAuth Dynamic Client Registration Protocol' to the IESG
for consideration as a Proposed Standard
[Starting point for the work will be
http://tools.ietf.org/html/draft-hardjono-oauth-dynreg]
Sep. 2012 Submit 'OAuth Use Cases' to the IESG for consideration as an
Informational RFC
[Starting point for the work will be
http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases]
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
P. Madsen
Internet-Draft Ping Identity Corp.
Intended status: Informational June 2011
Expires: December 3, 2011
OAuth Authorization Server Verification Interface
verification.xml
Abstract
This specification defines an interface by which a Resource Server,
upon receiving an access token on a call from a Client, can verify
with the issuing Authorization Server that the token is valid, and
optionally, retrieve identity attributes associated with the
corresponding Client and/or Resource Owner.
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 3, 2011.
Madsen Expires December 3, 2011 [Page 1]
Internet-Draft Ping Identity Verification June 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 3
2. Access Token Validation Request/Response . . . . . . . . . . . 3
2.1. RS sends Validation Request . . . . . . . . . . . . . . . . 4
2.2. Validation Server sends Response . . . . . . . . . . . . . 4
2.3. Example (non-normative) . . . . . . . . . . . . . . . . . . 5
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . . 6
Appendix B. Document History . . . . . . . . . . . . . . . . . . . 6
3. Normative References . . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6
Intellectual Property and Copyright Statements . . . . . . . . . . 7
Madsen Expires December 3, 2011 [Page 2]
Internet-Draft Ping Identity Verification June 2011
1. Introduction
The OAuth 2.0 Authorization Protocol [I-D.ietf.oauth-v2] provides a
method for making authenticated HTTP requests to a resource hosted by
some Resource Server using an access token. Access tokens are issued
to third-party clients by an Authorization Server with the (sometimes
implicit) approval of the resource owner.
Depending on the nature of the access token, a Resource Server may
not be able to directly verify/validate the access token and may need
to interact with an Authorization Server in order to verify the
token.
This specification defines an interface by which a Resource Server,
upon receiving an access token on a call from a Client, can verify
with the issuing Authorization Server that the token is valid, and
optionally, retrieve identity attributes associated with the
corresponding Client and/or Resource Owner
1.1. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Unless otherwise noted, all the protocol parameter names and values
are case sensitive.
2. Access Token Validation Request/Response
A Resource Server validates an access token by sending the token to
an Authorization Server - as shown below.
The validation endpoint interface profiles and extends that of the
OAuth [I-D.ietf.oauth-v2] token endpoint, by defining a unique grant
type and a format for the returned token.
+--------+ +---------------+
| | | |
|Resource|>--(A)----- access token ----->| Authorization |
| Server | | Server |
| |<--(B)---- y/n + attributes ----<| |
| | | |
+--------+ +---------------+
Madsen Expires December 3, 2011 [Page 3]
Internet-Draft Ping Identity Verification June 2011
Figure 1: Access Token Validation Request/Response
The request/response flow illustrated in Figure 1 includes the
following steps:
(A) The RS sends an access token validation request to the
Authorization Server that includes an access token and a
grant_type of
"urn:pingidentity.com:oauth2:grant_type:validate_bearer".
(B) The Authorization Server validates the access token and returns
a list of attributes associated with the access token, formatted
as JSON.
2.1. RS sends Validation Request
The client calls the Authorization Server with an access token
request, the core details of which are defined in OAuth
[I-D.ietf.oauth-v2] and by adding the following parameters:
grant_type
REQUIRED. A value of
"urn:pingidentity.com:oauth2:grant_type:validate_bearer"
token
REQUIRED. The value of the access token for which validation
is sought.
2.2. Validation Server sends Response
If validation was successful, the Authorization Server responds with
a JSON formatted data structure with the following parameters at the
top-level.
token_type
REQUIRED. A value of 'ping_validated_token' indicates the
access token was successfully validated.
expires_in
OPTIONAL. The duration in seconds of the returned attributes.
client_id
OPTIONAL. The client identifier of the client to whom the
grant was originally issued.
Madsen Expires December 3, 2011 [Page 4]
Internet-Draft Ping Identity Verification June 2011
access_token
OPTIONAL. A set of attributes.
If validation was not successful, the Authorization Server responds
with an OAuth error response with an error code of 'invalid grant'.
2.3. Example (non-normative)
The following examples illustrate access token validation request and
responses.
GET
/as/token.oauth2?client_id=a&client_secret=pwd&grant_type=urn:pingidentity.com:oauth2:grant_type:validate_bearer&token=5mZkmAoN6JjHREneyC7EuY8WdzGm1aRJaXT
HTTP/1.1
Host: authz.example.net
Figure 2: Example GET Request
HTTP/1.1 200 OK
Content-Type: application/json; charset=UTF-8
{"token_type":"ping_validated_token",
"expires_in":"3600",
"client_id":"a",
"access_token":
{"uid":"john",
"fake-email":"[email protected]"}}
Figure 3: Example Successful Response
HTTP/1.1 400 Bad Request
Content-Type: application/json; charset=UTF-8
{"error":"invalid_grant",
"error_description":"token not found, expired or invalid"}
Figure 4: Example Unsuccessful Response
Madsen Expires December 3, 2011 [Page 5]
Internet-Draft Ping Identity Verification June 2011
Appendix A. Contributors
folks
Appendix B. Document History
[[ to be removed by RFC editor before publication as an RFC ]]
3. Normative References
[I-D.ietf.oauth-v2]
Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, "The
OAuth 2.0 Authorization Protocol",
ID draft-ietf-oauth-v2-16 (work in progress), July 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Author's Address
Paul Madsen
Ping Identity Corp.
Email: [email protected]
Madsen Expires December 3, 2011 [Page 6]
Internet-Draft Ping Identity Verification June 2011
Full Copyright Statement
Copyright (C) The IETF Trust (2011).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
[email protected].
Madsen Expires December 3, 2011 [Page 7]
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
