draft-ietf-oauth-resource-indicators-02.txt   draft-ietf-oauth-resource-indicators-03.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: August 1, 2019 Yubico Expires: January 21, 2020 Yubico
H. Tschofenig H. Tschofenig
Arm Limited Arm Limited
January 28, 2019 July 20, 2019
Resource Indicators for OAuth 2.0 Resource Indicators for OAuth 2.0
draft-ietf-oauth-resource-indicators-02 draft-ietf-oauth-resource-indicators-03
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 August 1, 2019. This Internet-Draft will expire on January 21, 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 2, line 28 skipping to change at page 2, line 28
4.2. OAuth Extensions Error Registration . . . . . . . . . . . 10 4.2. OAuth Extensions Error Registration . . . . . . . . . . . 10
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Normative References . . . . . . . . . . . . . . . . . . 10 5.1. Normative References . . . . . . . . . . . . . . . . . . 10
5.2. Informative References . . . . . . . . . . . . . . . . . 11 5.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11
Appendix B. Document History . . . . . . . . . . . . . . . . . . 12 Appendix B. Document History . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
Several years of deployment and implementation experience with The Several years of deployment and implementation experience with the
OAuth 2.0 Authorization Framework [RFC6749] has uncovered a need, in OAuth 2.0 Authorization Framework [RFC6749] has uncovered a need, in
some circumstances, for the client to explicitly signal to the some circumstances, for the client to explicitly signal to the
authorization server where it intends to use the access token it is authorization server where it intends to use the access token it is
requesting. requesting.
Knowing the protected resource (a.k.a. resource server, application, Knowing the protected resource (a.k.a. resource server, application,
API, etc.) that will process the access token enables the API, etc.) that will process the access token enables the
authorization server to construct the token as necessary for that authorization server to construct the token as necessary for that
entity. Properly encrypting the token (or content within the token) entity. Properly encrypting the token (or content within the token)
to a particular resource, for example, requires knowing which to a particular resource, for example, requires knowing which
resource will receive and decrypt the token. Furthermore, various resource will receive and decrypt the token. Furthermore, various
resources oftentimes have different requirements with respect to the resources oftentimes have different requirements with respect to the
data contained in, or referenced by, the token and knowing the data contained in, or referenced by, the token and knowing the
resource where the client intends to use the token allows the the resource where the client intends to use the token allows the
authorization server to mint the token accordingly. authorization server to mint the token accordingly.
Specific knowledge of the intended recipient(s) of the access token Specific knowledge of the intended recipient(s) of the access token
also helps facilitate improved security characteristics of the token also helps facilitate improved security characteristics of the token
itself. Bearer tokens, currently the most commonly utilized type of itself. Bearer tokens, currently the most commonly utilized type of
OAuth access token, allow any party in possession of a token to get OAuth access token, allow any party in possession of a token to get
access to the associated resources. To prevent misuse, several access to the associated resources. To prevent misuse, several
important security assumptions must hold, one of which is that an important security assumptions must hold, one of which is that an
access token must only be valid for use at a specific protected access token must only be valid for use at a specific protected
resource and for a specific scope of access. Section 5.2 of resource and for a specific scope of access. Section 5.2 of
skipping to change at page 4, line 6 skipping to change at page 4, line 6
"client" defined by The OAuth 2.0 Authorization Framework [RFC6749]. "client" defined by The OAuth 2.0 Authorization Framework [RFC6749].
2. Resource Parameter 2. Resource Parameter
In requests to the authorization server, a client MAY indicate the In requests to the authorization server, a client MAY indicate the
protected resource (a.k.a. resource server, application, API, etc.) protected resource (a.k.a. resource server, application, API, etc.)
to which it is requesting access by including the following parameter to which it is requesting access by including the following parameter
in the request. in the request.
resource resource
Indicates the target service or resource at which access is being Indicates the target service or resource to which access is being
requested. Its value MUST be an absolute URI, as specified by requested. Its value MUST be an absolute URI, as specified by
Section 4.3 of [RFC3986], which MAY include a query component but Section 4.3 of [RFC3986], which MAY include a query component but
MUST NOT include a fragment component. The "resource" parameter MUST NOT include a fragment component. The "resource" parameter
URI value is an identifier representing the identity of the URI value is an identifier representing the identity of the
resource, which MAY be a locator that corresponds to a network resource, which MAY be a locator that corresponds to a network
addressable location where the target resource is hosted. addressable location where the target resource is hosted.
Multiple "resource" parameters MAY be used to indicate that the Multiple "resource" parameters MAY be used to indicate that the
requested token is intended to be used at multiple resources. requested token is intended to be used at multiple resources.
The parameter value identifies a resource to which the client is The parameter value identifies a resource to which the client is
skipping to change at page 4, line 44 skipping to change at page 4, line 44
"https://api.example.com/app/" would be used as a more specific "https://api.example.com/app/" would be used as a more specific
value. Another example, for an API like SCIM [RFC7644] that has value. Another example, for an API like SCIM [RFC7644] that has
multiple endpoints such as "https://apps.example.com/scim/Users", multiple endpoints such as "https://apps.example.com/scim/Users",
"https://apps.example.com/scim/Groups", and "https://apps.example.com/scim/Groups", and
"https://apps.example.com/scim/Schemas" The client would use "https://apps.example.com/scim/Schemas" The client would use
"https://apps.example.com/scim/" as the resource so that the issued "https://apps.example.com/scim/" as the resource so that the issued
access token is valid for all the endpoints of the SCIM API. access token is valid for all the endpoints of the SCIM API.
The following error code is provided for an authorization server to The following error code is provided for an authorization server to
indicate problems with the requested resource(s) in response to an indicate problems with the requested resource(s) in response to an
authorization request or access token request. And can also be used authorization request or access token request. It can also be used
to inform the client that it has requested an invalid combination of to inform the client that it has requested an invalid combination of
resource and scope. resource and scope.
invalid_target invalid_target
The requested resource is invalid, unknown, or malformed. The requested resource is invalid, unknown, or malformed.
The authorization server SHOULD audience restrict issued access The authorization server SHOULD audience restrict issued access
tokens to the resource(s) indicated by the "resource" parameter. tokens to the resource(s) indicated by the "resource" parameter.
Audience restrictions can be communicated in JSON Web Tokens Audience restrictions can be communicated in JSON Web Tokens
skipping to change at page 5, line 21 skipping to change at page 5, line 21
resource. resource.
2.1. Authorization Request 2.1. Authorization Request
When the "resource" parameter is used in an authorization request to When the "resource" parameter is used in an authorization request to
the authorization endpoint, it indicates the identity of the the authorization endpoint, it indicates the identity of the
protected resource(s) to which access is being requested. When an protected resource(s) to which access is being requested. When an
access token will be returned directly from the authorization access token will be returned directly from the authorization
endpoint via the implicit flow (Section 4.2 of OAuth 2.0 [RFC6749]), endpoint via the implicit flow (Section 4.2 of OAuth 2.0 [RFC6749]),
the requested resource is applicable to that access token. In the the requested resource is applicable to that access token. In the
code flow (Section 4.1 of OAuth 2.0 [RFC6749]) where an an code flow (Section 4.1 of OAuth 2.0 [RFC6749]) where an intermediate
intermediate representation of the authorization grant (the representation of the authorization grant (the authorization code) is
authorization code) is returned from the authorization endpoint, the returned from the authorization endpoint, the requested resource is
requested resource is applicable to the full authorization grant. applicable to the full authorization grant.
For authorization requests sent as a JWTs, such as when using JWT For authorization requests sent as a JWTs, such as when using JWT
Secured Authorization Request [I-D.ietf-oauth-jwsreq], a single Secured Authorization Request [I-D.ietf-oauth-jwsreq], a single
"resource" parameter value is represented as a JSON string while "resource" parameter value is represented as a JSON string while
multiple values are represented as an array of strings. multiple values are represented as an array of strings.
If the client omits the "resource" parameter when requesting If the client omits the "resource" parameter when requesting
authorization, the authorization server MAY process the request with authorization, the authorization server MAY process the request with
no specific resource or by using a pre-defined default resource no specific resource or by using a pre-defined default resource
value. Alternatively, the authorization server MAY require clients value. Alternatively, the authorization server MAY require clients
to specify the resource(s) they intend to access and MAY fail to specify the resource(s) they intend to access and MAY fail
requests that omit the parameter with an "invalid_target" error. The requests that omit the parameter with an "invalid_target" error. The
authorization server might use this data to inform the user about the authorization server might use this data to inform the user about the
resources the client is going to access on her behalf, to meet policy resources the client is going to access on her behalf, to meet policy
decision (e.g. refuse the request due to unknown resources), and decision (e.g. refuse the request due to unknown resources), and
determine the set of resources that can be used in subsequent access determine the set of resources that can be used in subsequent access
token requests. token requests.
If the authorization server fails to parse the provided value(s) or If the authorization server fails to parse the provided value(s) or
does not consider the resource(s) acceptable, it should reject the does not consider the resource(s) acceptable, it should reject the
request with an an error response using the error code request with an error response using the error code "invalid_target"
"invalid_target" as the value of the "error" parameter and can as the value of the "error" parameter and can provide additional
provide additional information regarding the reasons for the error information regarding the reasons for the error using the
using the "error_description" and/or "error_uri" parameters. "error_description" and/or "error_uri" parameters.
An example of an authorization request where the client tells the An example of an authorization request where the client tells the
authorization server that it wants an access token for use at authorization server that it wants an access token for use at
"https://api.example.com/app/" is shown in Figure 1 below (extra line "https://api.example.com/app/" is shown in Figure 1 below (extra line
breaks and indentation are for display purposes only). breaks and indentation are for display purposes only).
GET /as/authorization.oauth2?response_type=token GET /as/authorization.oauth2?response_type=token
&client_id=example-client &client_id=example-client
&state=XzZaJlcwYew1u0QBrRv_Gw &state=XzZaJlcwYew1u0QBrRv_Gw
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Eorg%2Fcb &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Eorg%2Fcb
&resource=https%3A%2F%2Fapi.example.com%2Fapp%2F HTTP/1.1 &resource=https%3A%2F%2Fapi.example.com%2Fapp%2F HTTP/1.1
Host: authorization-server.example.com Host: authorization-server.example.com
Figure 1: Implicit Flow Authorization Request Figure 1: Implicit Flow Authorization Request
Below in Figure 2 is an example of an authorization request using the Below in Figure 2 is an example of an authorization request using the
"code" response type where the the client is requesting access to the "code" response type where the client is requesting access to the
resource owner's contacts and calendar data at resource owner's contacts and calendar data at
"https://cal.example.com/" and "https://contacts.example.com/" (extra "https://cal.example.com/" and "https://contacts.example.com/" (extra
line breaks and indentation are for display purposes only). line breaks and indentation are for display purposes only).
GET /as/authorization.oauth2?response_type=code GET /as/authorization.oauth2?response_type=code
&client_id=s6BhdRkqt3 &client_id=s6BhdRkqt3
&state=tNwzQ87pC6llebpmac_IDeeq-mCR2wLDYljHUZUAWuI &state=tNwzQ87pC6llebpmac_IDeeq-mCR2wLDYljHUZUAWuI
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Eorg%2Fcb &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Eorg%2Fcb
&scope=calendar%20contacts &scope=calendar%20contacts
&resource=https%3A%2F%2Fcal.example.com%2F &resource=https%3A%2F%2Fcal.example.com%2F
skipping to change at page 7, line 26 skipping to change at page 7, line 26
know. This further improves privacy as scope values give an 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 it improves
security as scope values may contain confidential data. As specified security as scope values may contain confidential data. As specified
in Section 5.1 of [RFC6749], the authorization server must indicate in Section 5.1 of [RFC6749], the authorization server must indicate
the access token's effective scope to the client in the "scope" the access token's effective scope to the client in the "scope"
response parameter value when it differs from the scope requested by response parameter value when it differs from the scope requested by
the client. 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 and response where the client tells the authorization token request (Figure 3) and response (Figure 4) where the client
server that it wants the access token for use at tells the authorization server that it wants the access token for use
"https://cal.example.com/" (extra line breaks and indentation are for at "https://cal.example.com/" (extra line breaks and indentation are
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
Authorization: Basic czZCaGRSa3F0Mzpoc3FFelFsVW9IQUU5cHg0RlNyNHlJ Authorization: Basic czZCaGRSa3F0Mzpoc3FFelFsVW9IQUU5cHg0RlNyNHlJ
Content-Type: application/x-www-form-urlencoded Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code grant_type=authorization_code
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Eorg%2Fcb &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Eorg%2Fcb
&code=10esc29BWC2qZB0acc9v8zAv9ltc2pko105tQauZ &code=10esc29BWC2qZB0acc9v8zAv9ltc2pko105tQauZ
&resource=https%3A%2F%2Fcal.example.com%2F &resource=https%3A%2F%2Fcal.example.com%2F
skipping to change at page 9, line 38 skipping to change at page 9, line 38
resources. The "resource" parameter enables a client to indicate the resources. The "resource" parameter enables a client to indicate the
protected resources where the requested access token will be used, protected resources where the requested access token will be used,
which in turn enables the authorization server to apply the which in turn enables the authorization server to apply the
appropriate audience restrictions to the token. appropriate audience restrictions to the token.
Some servers may host user content or be multi-tenant. In order to Some servers may host user content or be multi-tenant. In order to
avoid attacks that might confuse a client into sending an access avoid attacks that might confuse a client into sending an access
token to a resource that is user controlled or is owned by a token to a resource that is user controlled or is owned by a
different tenant, it is important to use a specific resource URI different tenant, it is important to use a specific resource URI
including a path component. This will cause any access token issued including a path component. This will cause any access token issued
for accessing the user controlled resource to have a invalid audience for accessing the user controlled resource to have an invalid
if replayed against the legitimate resource API. audience if replayed against the legitimate resource API.
Although multiple occurrences of the "resource" parameter may be Although multiple occurrences of the "resource" parameter may be
included in a request, using only a single "resource" parameter is included in a request, using only a single "resource" parameter is
encouraged. A bearer token that has multiple intended recipients encouraged. A bearer token that has multiple intended recipients
(audiences) can be used by any one of those recipients at any other. (audiences) indicating that the token is valid at more than one
Thus, a high degree of trust between the involved parties is needed protected resource can be used by any one of those protected
when using access tokens with multiple audiences. Furthermore an resources to access any of the other protected resources. Thus, a
high degree of trust between the involved parties is needed when
using access tokens with multiple audiences. Furthermore an
authorization server may be unwilling or unable to fulfill a token authorization server may be unwilling or unable to fulfill a token
request with multiple resources. request with multiple resources.
Whenever feasible, the "resource" parameter should correspond to the Whenever feasible, the "resource" parameter should correspond to the
network addressable location of the protected resource. This makes network addressable location of the protected resource. This makes
it possible for the client to validate that the resource being it possible for the client to validate that the resource being
requested controls the corresponding network location, reducing the requested controls the corresponding network location, reducing the
risk of malicious endpoints obtaining tokens meant for other risk of malicious endpoints obtaining tokens meant for other
resources. If the "resource" parameter contains an abstract resources. If the "resource" parameter contains an abstract
identifier, it is the client's responsibility to validate out of band identifier, it is the client's responsibility to validate out of band
that any network endpoint to which tokens are sent are the intended that any network endpoint to which tokens are sent are the intended
audience for that identifier. audience for that identifier.
4. IANA Considerations 4. IANA Considerations
4.1. OAuth Parameters Registration 4.1. OAuth Parameters Registration
This specification registers the following value in the IANA "OAuth This specification updates the following value in the IANA "OAuth
Parameters" registry [IANA.OAuth.Parameters] established by Parameters" registry [IANA.OAuth.Parameters] established by
[RFC6749]. [RFC6749].
o Parameter name: resource o Parameter name: resource
o Parameter usage location: authorization request, token request o Parameter usage location: authorization request, token request
[[TODO: draft-ietf-oauth-token-exchange will have already
registered this for 'token request' and this draft has a more
generalized usage and needs to somehow either update that
registration or do a partial registration and reference]]
o Change controller: IESG o Change controller: IESG
o Specification document(s): [[ this specification ]] o Specification document(s): [[ this specification ]]
4.2. OAuth Extensions Error Registration 4.2. OAuth Extensions Error Registration
This specification registers the following error in the IANA "OAuth This specification updates the following error in the IANA "OAuth
Extensions Error Registry" [IANA.OAuth.Parameters] established by Extensions Error Registry" [IANA.OAuth.Parameters] established by
[RFC6749]. [RFC6749].
o Error name: invalid_target o Error name: invalid_target
o Error usage location: implicit grant error response, token error o Error usage location: implicit grant error response, token error
response [[TODO: draft-ietf-oauth-token-exchange will have already response
registered this for 'token error response' and this draft has a
more generalized usage and needs to somehow either update that
registration or do a partial registration and reference]]
o Related protocol extension: resource parameter o Related protocol extension: resource parameter
o Change controller: IESG o Change controller: IESG
o Specification document(s): [[ this specification ]] o Specification document(s): [[ this specification ]]
5. References 5. References
5.1. Normative References 5.1. Normative References
[IANA.OAuth.Parameters] [IANA.OAuth.Parameters]
IANA, "OAuth Parameters", IANA, "OAuth Parameters",
skipping to change at page 11, line 28 skipping to change at page 11, line 23
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
5.2. Informative References 5.2. Informative References
[I-D.ietf-oauth-jwsreq] [I-D.ietf-oauth-jwsreq]
Sakimura, N. and J. Bradley, "The OAuth 2.0 Authorization Sakimura, N. and J. Bradley, "The OAuth 2.0 Authorization
Framework: JWT Secured Authorization Request (JAR)", Framework: JWT Secured Authorization Request (JAR)",
draft-ietf-oauth-jwsreq-16 (work in progress), April 2018. draft-ietf-oauth-jwsreq-19 (work in progress), June 2019.
[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
Framework: Bearer Token Usage", RFC 6750, Framework: Bearer Token Usage", RFC 6750,
DOI 10.17487/RFC6750, October 2012, DOI 10.17487/RFC6750, October 2012,
<https://www.rfc-editor.org/info/rfc6750>. <https://www.rfc-editor.org/info/rfc6750>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>. <https://www.rfc-editor.org/info/rfc7519>.
skipping to change at page 11, line 52 skipping to change at page 11, line 47
September 2015, <https://www.rfc-editor.org/info/rfc7644>. September 2015, <https://www.rfc-editor.org/info/rfc7644>.
[RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection",
RFC 7662, DOI 10.17487/RFC7662, October 2015, RFC 7662, DOI 10.17487/RFC7662, October 2015,
<https://www.rfc-editor.org/info/rfc7662>. <https://www.rfc-editor.org/info/rfc7662>.
Appendix A. Acknowledgements Appendix A. Acknowledgements
This specification was developed within the OAuth Working Group under This specification was developed within the OAuth Working Group under
the chairmanship of Hannes Tschofenig and Rifaat Shekh-Yusef with the chairmanship of Hannes Tschofenig and Rifaat Shekh-Yusef with
Eric Rescorla and Benjamin Kaduk serving as Security Area Directors. Eric Rescorla, Benjamin Kaduk and Roman Danyliw serving as Security
Area Directors. Additionally, the following individuals contributed
Additionally, the following individuals contributed ideas, feedback, ideas, feedback, and wording that helped shape this specification:
and wording that helped shape this specification:
Vittorio Bertocci, Sergey Beryozkin, William Denniss, Vladimir Vittorio Bertocci, Sergey Beryozkin, Roman Danyliw, William Denniss,
Dzhuvinov, George Fletcher, Dick Hardt, Phil Hunt, Michael Jones, Vladimir Dzhuvinov, George Fletcher, Dick Hardt, Phil Hunt, Michael
Torsten Lodderstedt, Anthony Nadalin, Justin Richer, Nat Sakimura, Jones, Torsten Lodderstedt, Anthony Nadalin, Justin Richer, Nat
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-03
o Editorial updates from AD review.
o Update draft-ietf-oauth-jwsreq ref to -19.
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
necessarily have to correspond to a network addressable location. necessarily have to correspond to a network addressable location.
draft-ietf-oauth-resource-indicators-01 draft-ietf-oauth-resource-indicators-01
o Significant rework of the main section of the document attempting o Significant rework of the main section of the document attempting
to clarify a number of things that came up at, around and after to clarify a number of things that came up at, around and after
 End of changes. 22 change blocks. 
45 lines changed or deleted 45 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/