< draft-ietf-oauth-resource-indicators-03.txt   draft-ietf-oauth-resource-indicators-04.txt >
OAuth Working Group B. Campbell OAuth Working Group B. Campbell
Internet-Draft Ping Identity Internet-Draft Ping Identity
Intended status: Standards Track J. Bradley Intended status: Standards Track J. Bradley
Expires: January 21, 2020 Yubico Expires: January 22, 2020 Yubico
H. Tschofenig H. Tschofenig
Arm Limited Arm Limited
July 20, 2019 July 21, 2019
Resource Indicators for OAuth 2.0 Resource Indicators for OAuth 2.0
draft-ietf-oauth-resource-indicators-03 draft-ietf-oauth-resource-indicators-04
Abstract Abstract
An extension to the OAuth 2.0 Authorization Framework defining An extension to the OAuth 2.0 Authorization Framework defining
request parameters that enable a client to explicitly signal to an request parameters that enable a client to explicitly signal to an
authorization server about the identity of the protected resource(s) authorization server about the identity of the protected resource(s)
to which it is requesting access. to which it is requesting access.
Status of This Memo Status of This Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 January 21, 2020. This Internet-Draft will expire on January 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 7, line 14 skipping to change at page 7, line 14
When requesting a token, the client can indicate the desired target When requesting a token, the client can indicate the desired target
service(s) where it intends to use that token by way of the service(s) where it intends to use that token by way of the
"resource" parameter and can indicate the desired scope of the "resource" parameter and can indicate the desired scope of the
requested token using the "scope" parameter. The semantics of such a requested token using the "scope" parameter. The semantics of such a
request are that the client is asking for a token with the requested request are that the client is asking for a token with the requested
scope that is usable at all the requested target services. scope that is usable at all the requested target services.
Effectively, the requested access rights of the token are the Effectively, the requested access rights of the token are the
cartesian product of all the scopes at all the target services. To cartesian product of all the scopes at all the target services. To
the extent possible, when issuing access tokens, the authorization the extent possible, when issuing access tokens, the authorization
server should adapt the scope value associated with an access token server should downscope the scope value associated with an access
to the value the respective resource is able to process and needs to token to the value the respective resource is able to process and
know. This further improves privacy as scope values give an needs to know. This further improves privacy as scope values give an
indication of what services the resource owner uses and it improves indication of what services the resource owner uses and downscoping a
security as scope values may contain confidential data. As specified token to only that which is needed for a particular service can limit
in Section 5.1 of [RFC6749], the authorization server must indicate the extent to which such information is revealed across different
the access token's effective scope to the client in the "scope" services. As specified in Section 5.1 of [RFC6749], the
response parameter value when it differs from the scope requested by authorization server must indicate the access token's effective scope
the client. to the client in the "scope" response parameter value when it differs
from the scope requested by the client.
Following from the code flow authorization request shown in Figure 2, Following from the code flow authorization request shown in Figure 2,
the below examples show an "authorization_code" grant type access the below examples show an "authorization_code" grant type access
token request (Figure 3) and response (Figure 4) where the client token request (Figure 3) and response (Figure 4) where the client
tells the authorization server that it wants the access token for use tells the authorization server that it wants the access token for use
at "https://cal.example.com/" (extra line breaks and indentation are at "https://cal.example.com/" (extra line breaks and indentation are
for display purposes only). for display purposes only).
POST /as/token.oauth2 HTTP/1.1 POST /as/token.oauth2 HTTP/1.1
Host: authorization-server.example.com Host: authorization-server.example.com
skipping to change at page 12, line 11 skipping to change at page 12, line 11
Vittorio Bertocci, Sergey Beryozkin, Roman Danyliw, William Denniss, Vittorio Bertocci, Sergey Beryozkin, Roman Danyliw, William Denniss,
Vladimir Dzhuvinov, George Fletcher, Dick Hardt, Phil Hunt, Michael Vladimir Dzhuvinov, George Fletcher, Dick Hardt, Phil Hunt, Michael
Jones, Torsten Lodderstedt, Anthony Nadalin, Justin Richer, Nat Jones, Torsten Lodderstedt, Anthony Nadalin, Justin Richer, Nat
Sakimura, Rifaat Shekh-Yusef, Filip Skokan, and Hans Zandbelt. Sakimura, Rifaat Shekh-Yusef, Filip Skokan, and Hans Zandbelt.
Appendix B. Document History Appendix B. Document History
[[ to be removed by the RFC Editor before publication as an RFC ]] [[ to be removed by the RFC Editor before publication as an RFC ]]
draft-ietf-oauth-resource-indicators-04
o Editorial updates from AD review that were overlooked in -03.
draft-ietf-oauth-resource-indicators-03 draft-ietf-oauth-resource-indicators-03
o Editorial updates from AD review. o Editorial updates from AD review.
o Update draft-ietf-oauth-jwsreq ref to -19. o Update draft-ietf-oauth-jwsreq ref to -19.
o Update the IANA requests to say they update the registries. o Update the IANA requests to say they update the registries.
draft-ietf-oauth-resource-indicators-02 draft-ietf-oauth-resource-indicators-02
o Clarify that the value of the "resource" parameter is a URI which o Clarify that the value of the "resource" parameter is a URI which
can be an abstract identifier for the target resource and doesn't can be an abstract identifier for the target resource and doesn't
skipping to change at page 12, line 48 skipping to change at page 13, line 5
draft-ietf-oauth-resource-indicators-00 draft-ietf-oauth-resource-indicators-00
o First version of the working group document. A replica of draft- o First version of the working group document. A replica of draft-
campbell-oauth-resource-indicators-02. campbell-oauth-resource-indicators-02.
draft-campbell-oauth-resource-indicators-02 draft-campbell-oauth-resource-indicators-02
o No changes. o No changes.
draft-campbell-oauth-resource-indicators-01
o Move Hannes Tschofenig, who wrote https://tools.ietf.org/html/ o Move Hannes Tschofenig, who wrote https://tools.ietf.org/html/
draft-tschofenig-oauth-audience in '13, from Acknowledgements to draft-tschofenig-oauth-audience in '13, from Acknowledgements to
Authors. Authors.
o Added IANA Considerations to register the "resource" parameter and o Added IANA Considerations to register the "resource" parameter and
"invalid_resource" error code. "invalid_resource" error code.
draft-campbell-oauth-resource-indicators-00 draft-campbell-oauth-resource-indicators-00
o Initial draft to define a resource parameter for OAuth 2.0. o Initial draft to define a resource parameter for OAuth 2.0.
 End of changes. 7 change blocks. 
14 lines changed or deleted 18 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/