draft-ietf-oauth-rar-00.txt   draft-ietf-oauth-rar-01.txt 
Web Authorization Protocol T. Lodderstedt Web Authorization Protocol T. Lodderstedt
Internet-Draft yes.com Internet-Draft yes.com
Intended status: Standards Track J. Richer Intended status: Standards Track J. Richer
Expires: July 24, 2020 Bespoke Engineering Expires: 22 August 2020 Bespoke Engineering
B. Campbell B. Campbell
Ping Identity Ping Identity
January 21, 2020 19 February 2020
OAuth 2.0 Rich Authorization Requests OAuth 2.0 Rich Authorization Requests
draft-ietf-oauth-rar-00 draft-ietf-oauth-rar-01
Abstract Abstract
This document specifies a new parameter "authorization_details" that This document specifies a new parameter "authorization_details" that
is used to carry fine grained authorization data in the OAuth is used to carry fine grained authorization data in the OAuth
authorization request. authorization request.
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
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 July 24, 2020. This Internet-Draft will expire on 22 August 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions and Terminology . . . . . . . . . . . . . . . 4 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 4
2. Request parameter "authorization_details" . . . . . . . . . . 4 2. Request parameter "authorization_details" . . . . . . . . . . 4
2.1. Authorization data elements types . . . . . . . . . . . . 5 2.1. Authorization data elements types . . . . . . . . . . . . 6
2.2. Relationship to "scope" parameter . . . . . . . . . . . . 8 2.2. Relationship to "scope" parameter . . . . . . . . . . . . 8
2.2.1. Scope value "openid" and "claims" parameter . . . . . 8 2.2.1. Scope value "openid" and "claims" parameter . . . . . 9
2.3. Relationship to "resource" parameter . . . . . . . . . . 9 2.3. Relationship to "resource" parameter . . . . . . . . . . 9
3. Using "authorization_details" . . . . . . . . . . . . . . . . 11 3. Using "authorization_details" . . . . . . . . . . . . . . . . 11
3.1. Authorization Request . . . . . . . . . . . . . . . . . . 11 3.1. Authorization Request . . . . . . . . . . . . . . . . . . 11
3.2. Authorization Request Processing . . . . . . . . . . . . 14 3.2. Authorization Request Processing . . . . . . . . . . . . 14
3.3. Token Request . . . . . . . . . . . . . . . . . . . . . . 15 3.3. Token Request . . . . . . . . . . . . . . . . . . . . . . 15
3.4. Token Response . . . . . . . . . . . . . . . . . . . . . 15 3.4. Token Response . . . . . . . . . . . . . . . . . . . . . 15
3.4.1. Token Content . . . . . . . . . . . . . . . . . . . . 16 3.4.1. Token Content . . . . . . . . . . . . . . . . . . . . 16
3.5. Token Introspection Request . . . . . . . . . . . . . . . 18 3.5. Token Introspection Request . . . . . . . . . . . . . . . 18
3.6. Token Introspection Response . . . . . . . . . . . . . . 18 3.6. Token Introspection Response . . . . . . . . . . . . . . 18
4. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5. Implementation Considerations . . . . . . . . . . . . . . . . 20 5. Implementation Considerations . . . . . . . . . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 10. Normative References . . . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . 21 11. Informative References . . . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. Additional Examples . . . . . . . . . . . . . . . . 23 Appendix A. Additional Examples . . . . . . . . . . . . . . . . 23
A.1. OpenID Connect . . . . . . . . . . . . . . . . . . . . . 23 A.1. OpenID Connect . . . . . . . . . . . . . . . . . . . . . 24
A.2. Remote Electronic Signing . . . . . . . . . . . . . . . . 25 A.2. Remote Electronic Signing . . . . . . . . . . . . . . . . 25
A.3. Access to Tax Data . . . . . . . . . . . . . . . . . . . 26 A.3. Access to Tax Data . . . . . . . . . . . . . . . . . . . 26
A.4. eHealth . . . . . . . . . . . . . . . . . . . . . . . . . 27 A.4. eHealth . . . . . . . . . . . . . . . . . . . . . . . . . 27
Appendix B. Document History . . . . . . . . . . . . . . . . . . 29 Appendix B. Document History . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
The OAuth 2.0 authorization framework [RFC6749] defines the parameter The OAuth 2.0 authorization framework [RFC6749] defines the parameter
"scope" that allows OAuth clients to specify the requested scope, "scope" that allows OAuth clients to specify the requested scope,
skipping to change at page 6, line 7 skipping to change at page 6, line 12
available to the respective resource servers. The array MAY contain available to the respective resource servers. The array MAY contain
several elements of the same "type". several elements of the same "type".
2.1. Authorization data elements types 2.1. Authorization data elements types
This draft defines a set of common data elements that are designed to This draft defines a set of common data elements that are designed to
be usable across different types of APIs. These data elements MAY be be usable across different types of APIs. These data elements MAY be
combined in different ways depending on the needs of the API. Unless combined in different ways depending on the needs of the API. Unless
otherwise noted, all data elements are OPTIONAL. otherwise noted, all data elements are OPTIONAL.
type: "type": The type of resource request as a string. This field MAY
The type of resource request as a string. This field MAY define define which other elements are allowed in the request. This
which other elements are allowed in the request. This element is element is REQUIRED.
REQUIRED.
locations: "locations": An array of strings representing the location of the
An array of strings representing the location of the resource or resource or resource server. This is typically composed of URIs.
resource server. This is typically composed of URIs.
actions: "actions": An array of strings representing the kinds of actions to
An array of strings representing the kinds of actions to be taken be taken at the resource. The values of the strings are
at the resource. The values of the strings are determined by the determined by the API being protected.
API being protected.
datatypes: "datatypes": An array of strings representing the kinds of data
An array of strings representing the kinds of data being requested being requested from the resource.
from the resource.
identifier: "identifier": A string identifier indicating a specific resource
A string identifier indicating a specific resource available at available at the API.
the API.
When different element types are used in combination, the permissions When different element types are used in combination, the permissions
the client requests is the cartesian product of the values. In the the client requests is the cartesian product of the values. In the
following example following example
[ [
{ {
"type": "customer_information", "type": "customer_information",
"locations": [ "locations": [
"https://example.com/customers", "https://example.com/customers",
skipping to change at page 11, line 47 skipping to change at page 11, line 47
} }
3. Using "authorization_details" 3. Using "authorization_details"
3.1. Authorization Request 3.1. Authorization Request
The request parameter can be used to specify authorization The request parameter can be used to specify authorization
requirements in all places where the "scope" parameter is used for requirements in all places where the "scope" parameter is used for
the same purpose, examples include: the same purpose, examples include:
o Authorization requests as specified in [RFC6749], * Authorization requests as specified in [RFC6749],
o Access token requests as specified in [RFC6749], if also used as * Access token requests as specified in [RFC6749], if also used as
authorization requests, e.g. in the case of assertion grant types authorization requests, e.g. in the case of assertion grant types
[RFC7521], [RFC7521],
o Request objects as specified in [I-D.ietf-oauth-jwsreq], * Request objects as specified in [I-D.ietf-oauth-jwsreq],
o Device Authorization Request as specified in [RFC8628], * Device Authorization Request as specified in [RFC8628],
o Backchannel Authentication Requests as defined in [OpenID.CIBA]. * Backchannel Authentication Requests as defined in [OpenID.CIBA].
Parameter encoding is determined by the respective context. Parameter encoding is determined by the respective context.
In the context of an authorization request according to [RFC6749], In the context of an authorization request according to [RFC6749],
the parameter is encoded using the "application/x-www-form- the parameter is encoded using the "application/x-www-form-
urlencoded" format of the serialized JSON as shown in the following urlencoded" format of the serialized JSON as shown in the following
example: example:
GET /authorize?response_type=code GET /authorize?response_type=code
&client_id=s6BhdRkqt3 &client_id=s6BhdRkqt3
&state=af0ifjsldkj &state=af0ifjsldkj
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
&code_challenge_method=S256 &code_challenge_method=S256
&code_challenge=K2-ltc83acc4h0c9w6ESC_rEMTJ3bww-uCHaoeK1t8U &code_challenge=K2-ltc83acc4h0c9w6ESC_rEMTJ3bwc-uCHaoeK1t8U
&authorization_details=%5B%7B%22type%22%3A%22account%5Finformati &authorization_details=%5B%7B%22type%22%3A%22account%5Finformati
on%22%2C%22actions%22%3A%5B%22list%5Faccounts%22%2C%22read%5Fbal on%22%2C%22actions%22%3A%5B%22list%5Faccounts%22%2C%22read%5Fbal
ances%22%2C%22read%5Ftransactions%22%5D%2C%22locations%22%3A%5B% ances%22%2C%22read%5Ftransactions%22%5D%2C%22locations%22%3A%5B%
22https%3A%2F%2Fexample%2Ecom%2Faccounts%22%5D%7D%5D HTTP/1.1 22https%3A%2F%2Fexample%2Ecom%2Faccounts%22%5D%7D%5D HTTP/1.1
Host: server.example.com Host: server.example.com
Implementors MUST ensure to protect personal identifiable information Implementors MUST ensure to protect personal identifiable information
in transit. One way is to utilize encrypted request objects as in transit. One way is to utilize encrypted request objects as
defined in [I-D.ietf-oauth-jwsreq]. In the context of a request defined in [I-D.ietf-oauth-jwsreq]. In the context of a request
object, "authorization_details" is added as another top level JSON object, "authorization_details" is added as another top level JSON
element. element.
{ {
"iss": "s6BhdRkqt3", "iss": "s6BhdRkqt3",
"aud": "https://server.example.com", "aud": "https://server.example.com",
"response_type": "code", "response_type": "code",
"client_id": "s6BhdRkqt3", "client_id": "s6BhdRkqt3",
"redirect_uri": "https://client.example.com/cb", "redirect_uri": "https://client.example.com/cb",
"state": "af0ifjsldkj", "state": "af0ifjsldkj",
"code_challenge_method": "S256", "code_challenge_method": "S256",
"code_challenge": "K2-ltc83acc4h0c9w6ESC_rEMTJ3bww-uCHaoeK1t8U", "code_challenge": "K2-ltc83acc4h0c9w6ESC_rEMTJ3bwc-uCHaoeK1t8U",
"authorization_details": [ "authorization_details": [
{ {
"type": "account_information", "type": "account_information",
"actions": [ "actions": [
"list_accounts", "list_accounts",
"read_balances", "read_balances",
"read_transactions" "read_transactions"
], ],
"locations": [ "locations": [
"https://example.com/accounts" "https://example.com/accounts"
skipping to change at page 14, line 20 skipping to change at page 14, line 20
POST /as/par HTTP/1.1 POST /as/par HTTP/1.1
Host: as.example.com Host: as.example.com
Content-Type: application/x-www-form-urlencoded Content-Type: application/x-www-form-urlencoded
Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3 Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3
response_type=code& response_type=code&
client_id=s6BhdRkqt3 client_id=s6BhdRkqt3
&state=af0ifjsldkj &state=af0ifjsldkj
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
&code_challenge_method=S256 &code_challenge_method=S256
&code_challenge=K2-ltc83acc4h0c9w6ESC_rEMTJ3bww-uCHaoeK1t8U &code_challenge=K2-ltc83acc4h0c9w6ESC_rEMTJ3bwc-uCHaoeK1t8U
&authorization_details=%5B%7B%22type%22%3A%22account_information%22 &authorization_details=%5B%7B%22type%22%3A%22account_information%22
%2C%22actions%22%3A%5B%22list_accounts%22%2C%22read_balances%22%2C% %2C%22actions%22%3A%5B%22list_accounts%22%2C%22read_balances%22%2C%
22read_transactions%22%5D%2C%22locations%22%3A%5B%22https%3A%2F%2Fe 22read_transactions%22%5D%2C%22locations%22%3A%5B%22https%3A%2F%2Fe
xample.com%2Faccounts%22%5D%7D%2C%7B%22type%22%3A%22payment_initiat xample.com%2Faccounts%22%5D%7D%2C%7B%22type%22%3A%22payment_initiat
ion%22%2C%22actions%22%3A%5B%22initiate%22%2C%22status%22%2C%22canc ion%22%2C%22actions%22%3A%5B%22initiate%22%2C%22status%22%2C%22canc
el%22%5D%2C%22locations%22%3A%5B%22https%3A%2F%2Fexample.com%2Fpaym el%22%5D%2C%22locations%22%3A%5B%22https%3A%2F%2Fexample.com%2Fpaym
ents%22%5D%2C%22instructedAmount%22%3A%7B%22currency%22%3A%22EUR%22 ents%22%5D%2C%22instructedAmount%22%3A%7B%22currency%22%3A%22EUR%22
%2C%22amount%22%3A%22123.50%22%7D%2C%22creditorName%22%3A%22Merchan %2C%22amount%22%3A%22123.50%22%7D%2C%22creditorName%22%3A%22Merchan
t123%22%2C%22creditorAccount%22%3A%7B%22iban%22%3A%22DE021001001093 t123%22%2C%22creditorAccount%22%3A%7B%22iban%22%3A%22DE021001001093
07118603%22%7D%2C%22remittanceInformationUnstructured%22%3A%22Ref%2 07118603%22%7D%2C%22remittanceInformationUnstructured%22%3A%22Ref%2
skipping to change at page 17, line 41 skipping to change at page 17, line 41
"creditorAccount": { "creditorAccount": {
"iban": "DE02100100109307118603" "iban": "DE02100100109307118603"
}, },
"remittanceInformationUnstructured": "Ref Number Merchant" "remittanceInformationUnstructured": "Ref Number Merchant"
} }
], ],
"debtorAccount": { "debtorAccount": {
"iban": "DE40100100103307118608", "iban": "DE40100100103307118608",
"user_role": "owner" "user_role": "owner"
} }
] }
In this case, the AS added the following example claims: In this case, the AS added the following example claims:
o "sub": conveys the user on which behalf the client is asking for * "sub": conveys the user on which behalf the client is asking for
payment initation payment initation
o "txn": transaction id used to trace the transaction across the * "txn": transaction id used to trace the transaction across the
services of provider "example.com" services of provider "example.com"
o "debtorAccount": API-specific element containing the debtor * "debtorAccount": API-specific element containing the debtor
account. In the example, this account was not passed in the account. In the example, this account was not passed in the
authorization details but selected by the user during the authorization details but selected by the user during the
authorization process. The field "user_role" conveys the role the authorization process. The field "user_role" conveys the role the
user has with respect to this particuar account. In this case, user has with respect to this particuar account. In this case,
she is the owner. This data is used for access control at the she is the owner. This data is used for access control at the
payment API (the RS). payment API (the RS).
3.5. Token Introspection Request 3.5. Token Introspection Request
In case of opaque access tokens, the data provided to a certain RS is In case of opaque access tokens, the data provided to a certain RS is
skipping to change at page 21, line 23 skipping to change at page 21, line 23
SHOULD share this data with the resource servers on a "need to know" SHOULD share this data with the resource servers on a "need to know"
basis. basis.
8. Acknowledgements 8. Acknowledgements
We would would like to thank Daniel Fett, Sebastian Ebling, Dave We would would like to thank Daniel Fett, Sebastian Ebling, Dave
Tonge, Mike Jones, Nat Sakimura, and Rob Otto for their valuable Tonge, Mike Jones, Nat Sakimura, and Rob Otto for their valuable
feedback during the preparation of this draft. feedback during the preparation of this draft.
We would also like to thank Daniel Fett, Dave Tonge, Travis Spencer, We would also like to thank Daniel Fett, Dave Tonge, Travis Spencer,
Joergen Binningsboe, Aamund Bremer, Steinar Noem, and Aaron Parecki Jørgen Binningsbø, Aamund Bremer, Steinar Noem, and Aaron
for their valuable feedback to this draft. Parecki for their valuable feedback to this draft.
9. IANA Considerations 9. IANA Considerations
TBD TBD
o "authorization_details" as JWT claim * "authorization_details" as JWT claim
o "authorization_details_supported" and * "authorization_details_supported" and
"authorization_data_types_supported" as metadata parameters "authorization_data_types_supported" as metadata parameters
o "authorization_data_types" as dynamic client registration * "authorization_data_types" as dynamic client registration
parameter parameter
o establish authorization data type registry * establish authorization data type registry
o register type "openid_claims"
10. References * register type "openid_claims"
10.1. Normative References 10. Normative References
[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>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
RFC 6749, DOI 10.17487/RFC6749, October 2012, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
<https://www.rfc-editor.org/info/rfc6749>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>.
[RFC7521] Campbell, B., Mortimore, C., Jones, M., and Y. Goland, [RFC7521] Campbell, B., Mortimore, C., Jones, M., and Y. Goland,
"Assertion Framework for OAuth 2.0 Client Authentication "Assertion Framework for OAuth 2.0 Client Authentication
and Authorization Grants", RFC 7521, DOI 10.17487/RFC7521, and Authorization Grants", RFC 7521, DOI 10.17487/RFC7521,
May 2015, <https://www.rfc-editor.org/info/rfc7521>. May 2015, <https://www.rfc-editor.org/info/rfc7521>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, RFC 6749, DOI 10.17487/RFC6749, October 2012,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. <https://www.rfc-editor.org/info/rfc6749>.
[RFC8628] Denniss, W., Bradley, J., Jones, M., and H. Tschofenig, [RFC8628] Denniss, W., Bradley, J., Jones, M., and H. Tschofenig,
"OAuth 2.0 Device Authorization Grant", RFC 8628, "OAuth 2.0 Device Authorization Grant", RFC 8628,
DOI 10.17487/RFC8628, August 2019, DOI 10.17487/RFC8628, August 2019,
<https://www.rfc-editor.org/info/rfc8628>. <https://www.rfc-editor.org/info/rfc8628>.
10.2. Informative References [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
[CSC] Consortium, C. S., "Architectures and protocols for remote <https://www.rfc-editor.org/info/rfc7519>.
signature applications", Jun 2019,
<https://cloudsignatureconsortium.org/wp-
content/uploads/2019/07/CSC_API_V1_1.0.4.0.pdf>.
[ETSI] ETSI, "ETSI TS 119 432, Electronic Signatures and
Infrastructures (ESI); Protocols for remote digital
signature creation", Mar 2019,
<https://www.etsi.org/deliver/
etsi_ts/119400_119499/119432/01.01.01_60/
ts_119432v010101p.pdf>.
[I-D.ietf-oauth-jwsreq] 11. Informative References
Sakimura, N. and J. Bradley, "The OAuth 2.0 Authorization
Framework: JWT Secured Authorization Request (JAR)",
draft-ietf-oauth-jwsreq-20 (work in progress), October
2019.
[I-D.ietf-oauth-jwt-introspection-response] [I-D.ietf-oauth-jwt-introspection-response]
Lodderstedt, T. and V. Dzhuvinov, "JWT Response for OAuth Lodderstedt, T. and V. Dzhuvinov, "JWT Response for OAuth
Token Introspection", draft-ietf-oauth-jwt-introspection- Token Introspection", Work in Progress, Internet-Draft,
response-08 (work in progress), September 2019. draft-ietf-oauth-jwt-introspection-response-08, 20
September 2019, <https://tools.ietf.org/html/draft-ietf-
[I-D.ietf-oauth-resource-indicators] oauth-jwt-introspection-response-08>.
Campbell, B., Bradley, J., and H. Tschofenig, "Resource
Indicators for OAuth 2.0", draft-ietf-oauth-resource-
indicators-08 (work in progress), September 2019.
[I-D.ietf-oauth-security-topics]
Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett,
"OAuth 2.0 Security Best Current Practice", draft-ietf-
oauth-security-topics-13 (work in progress), July 2019.
[I-D.lodderstedt-oauth-par]
Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D.,
and F. Skokan, "OAuth 2.0 Pushed Authorization Requests",
draft-lodderstedt-oauth-par-01 (work in progress),
November 2019.
[OIDC] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and [OIDC] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
C. Mortimore, "OpenID Connect Core 1.0 incorporating C. Mortimore, "OpenID Connect Core 1.0 incorporating
errata set 1", Nov 2014, errata set 1", 8 November 2014,
<http://openid.net/specs/openid-connect-core-1_0.html>. <http://openid.net/specs/openid-connect-core-1_0.html>.
[I-D.ietf-oauth-jwsreq]
Sakimura, N. and J. Bradley, "The OAuth 2.0 Authorization
Framework: JWT Secured Authorization Request (JAR)", Work
in Progress, Internet-Draft, draft-ietf-oauth-jwsreq-20,
21 October 2019,
<https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20>.
[OpenID.CIBA] [OpenID.CIBA]
Fernandez, G., Walter, F., Nennker, A., Tonge, D., and B. Fernandez, G., Walter, F., Nennker, A., Tonge, D., and B.
Campbell, "OpenID Connect Client Initiated Backchannel Campbell, "OpenID Connect Client Initiated Backchannel
Authentication Flow - Core 1.0", January 2019, Authentication Flow - Core 1.0", 16 January 2019,
<https://openid.net/specs/openid-client-initiated- <https://openid.net/specs/openid-client-initiated-
backchannel-authentication-core-1_0.html>. backchannel-authentication-core-1_0.html>.
[I-D.lodderstedt-oauth-par]
Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D.,
and F. Skokan, "OAuth 2.0 Pushed Authorization Requests",
Work in Progress, Internet-Draft, draft-lodderstedt-oauth-
par-01, 3 November 2019, <https://tools.ietf.org/html/
draft-lodderstedt-oauth-par-01>.
[transaction-authorization]
Lodderstedt, T., "Transaction Authorization or why we need
to re-think OAuth scopes", 20 April 2019,
<https://medium.com/oauth-2/transaction-authorization-or-
why-we-need-to-re-think-oauth-scopes-2326e2038948>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259, Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017, DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>. <https://www.rfc-editor.org/info/rfc8259>.
[transaction-authorization] [ETSI] ETSI, "ETSI TS 119 432, Electronic Signatures and
Lodderstedt, T., "Transaction Authorization or why we need Infrastructures (ESI); Protocols for remote digital
to re-think OAuth scopes", Apr 2019, <https://medium.com/ signature creation", 20 March 2019,
oauth-2/transaction-authorization-or-why-we-need-to-re- <https://www.etsi.org/deliver/
think-oauth-scopes-2326e2038948>. etsi_ts/119400_119499/119432/01.01.01_60/
ts_119432v010101p.pdf>.
Appendix A. Additional Examples [CSC] Consortium, C. S., "Architectures and protocols for remote
signature applications", 1 June 2019,
<https://cloudsignatureconsortium.org/wp-
content/uploads/2019/07/CSC_API_V1_1.0.4.0.pdf>.
[I-D.ietf-oauth-resource-indicators]
Campbell, B., Bradley, J., and H. Tschofenig, "Resource
Indicators for OAuth 2.0", Work in Progress, Internet-
Draft, draft-ietf-oauth-resource-indicators-08, 11
September 2019, <https://tools.ietf.org/html/draft-ietf-
oauth-resource-indicators-08>.
[I-D.ietf-oauth-security-topics]
Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett,
"OAuth 2.0 Security Best Current Practice", Work in
Progress, Internet-Draft, draft-ietf-oauth-security-
topics-14, 10 February 2020, <https://tools.ietf.org/html/
draft-ietf-oauth-security-topics-14>.
Appendix A. Additional Examples
A.1. OpenID Connect A.1. OpenID Connect
These hypothetical examples try to encapsulate all details specific These hypothetical examples try to encapsulate all details specific
to the OpenID Connect part of an authorization process into an to the OpenID Connect part of an authorization process into an
authorization JSON object. authorization JSON object.
The top-level elements are based on the definitions given in [OIDC]: The top-level elements are based on the definitions given in [OIDC]:
o "claim_sets": names of predefined claim sets, replacement for * "claim_sets": names of predefined claim sets, replacement for
respective scope values, such as "profile" respective scope values, such as "profile"
o "max_age": Maximum Authentication Age * "max_age": Maximum Authentication Age
o "acr_values": array of ACR values * "acr_values": array of ACR values
o "claims": the "claims" JSON structure as defined in [OIDC] * "claims": the "claims" JSON structure as defined in [OIDC]
This is a simple request for some claim sets. This is a simple request for some claim sets.
[ [
{ {
"type": "openid", "type": "openid",
"locations": [ "locations": [
"https://op.example.com/userinfo" "https://op.example.com/userinfo"
], ],
"claim_sets": [ "claim_sets": [
skipping to change at page 26, line 28 skipping to change at page 26, line 28
"hash": "HZQzZmMAIWekfGH0/ZKW1nsdt0xg3H6bZYztgsMTLw0=", "hash": "HZQzZmMAIWekfGH0/ZKW1nsdt0xg3H6bZYztgsMTLw0=",
"label": "Contract Payment Protection Insurance" "label": "Contract Payment Protection Insurance"
} }
], ],
"hashAlgorithmOID": "2.16.840.1.101.3.4.2.1" "hashAlgorithmOID": "2.16.840.1.101.3.4.2.1"
} }
] ]
The top-level elements have the following meaning: The top-level elements have the following meaning:
o "credentialID": identifier of the certificate to be used for * "credentialID": identifier of the certificate to be used for
signing signing
o "documentDigests": array containing the hash of every document to * "documentDigests": array containing the hash of every document to
be signed ("hash" elements). Additionally, the corresponding be signed ("hash" elements). Additionally, the corresponding
"label" element identifies the respective document to the user, "label" element identifies the respective document to the user,
e.g. to be used in user consent. e.g. to be used in user consent.
o "hashAlgorithm": algomrithm that was used to calculate the hash * "hashAlgorithm": algomrithm that was used to calculate the hash
values. values.
The AS is supposed to ask the user for consent for the creation of The AS is supposed to ask the user for consent for the creation of
signatues for the documents listed in the structure. The client uses signatues for the documents listed in the structure. The client uses
the access token issued as result of the process to call the sign doc the access token issued as result of the process to call the sign doc
endpoint at the respective signing service to actually create the endpoint at the respective signing service to actually create the
signature. This access token is bound to the client, the user id and signature. This access token is bound to the client, the user id and
the hashes (and signature algorithm) as consented by the user. the hashes (and signature algorithm) as consented by the user.
A.3. Access to Tax Data A.3. Access to Tax Data
skipping to change at page 27, line 20 skipping to change at page 27, line 20
], ],
"actions":"read_tax_declaration", "actions":"read_tax_declaration",
"periods": ["2018"], "periods": ["2018"],
"duration_of_access": 30, "duration_of_access": 30,
"tax_payer_id": "23674185438934" "tax_payer_id": "23674185438934"
} }
] ]
The top-level elements have the following meaning: The top-level elements have the following meaning:
o "periods": determines the periods the client wants to access * "periods": determines the periods the client wants to access
o "duration_of_access": how long does the client intend to access * "duration_of_access": how long does the client intend to access
the data in days the data in days
o "tax_payer_id": identifier of the tax payer (if known to the * "tax_payer_id": identifier of the tax payer (if known to the
client) client)
A.4. eHealth A.4. eHealth
This example is inspired by an API used in the Norwegian eHealth This example is inspired by an API used in the Norwegian eHealth
system. system.
In this use case the physical therapist sits in front of her computer In this use case the physical therapist sits in front of her computer
using a local Electronic Health Records (EHR) system. She wants to using a local Electronic Health Records (EHR) system. She wants to
look at the electronic patient records of a certain patient and she look at the electronic patient records of a certain patient and she
skipping to change at page 29, line 6 skipping to change at page 29, line 6
"display": "Physical therapist" "display": "Physical therapist"
} }
] ]
} }
} }
} }
} }
] ]
Description of the elements: Description of the elements:
o "patient_identifier": the identifier of the patient composed of a * "patient_identifier": the identifier of the patient composed of a
system identifier in OID format (namespace) and the acutal value system identifier in OID format (namespace) and the acutal value
within this namespace. within this namespace.
o "reason_for_request": the reason why the user wants to access a * "reason_for_request": the reason why the user wants to access a
certain API certain API
o "requesting_entity": specification of the requester by means of * "requesting_entity": specification of the requester by means of
identity, role and organizational context. This data is provided identity, role and organizational context. This data is provided
to facilitate authorization and for auditing purposes. to facilitate authorization and for auditing purposes.
In this use case, the AS authenticates the requester, who is not the In this use case, the AS authenticates the requester, who is not the
patient, and approves access based on policies. patient, and approves access based on policies.
Appendix B. Document History Appendix B. Document History
[[ To be removed from the final specification ]] [[ To be removed from the final specification ]]
-01
* Minor fix-up in a few examples
* Use the newish RFC v3 XML and HTML format
-00 (WG draft) -00 (WG draft)
o inital WG revision * initial WG revision
-03 -03
o Reworked examples to illustrate privacy preserving use of * Reworked examples to illustrate privacy preserving use of
"authorization_details" "authorization_details"
o Added text on audience restriction * Added text on audience restriction
o Added description of relationship between "scope" and * Added description of relationship between "scope" and
"authorization_details" "authorization_details"
o Added text on token request & response and "authorization_details" * Added text on token request & response and "authorization_details"
o Added text on how authorization details are conveyed to RSs by * Added text on how authorization details are conveyed to RSs by
JWTs or token endpoint response JWTs or token endpoint response
o Added description of relationship between "claims" and * Added description of relationship between "claims" and
"authorization_details" "authorization_details"
o Added more example from different sectors * Added more example from different sectors
o Clarified string comparison to be byte-exact without collation * Clarified string comparison to be byte-exact without collation
-02 -02
o Added Security Considerations
o Added Privacy Considerations * Added Security Considerations
o Added notes on URI size and authorization details * Added Privacy Considerations
o Added requirement to return the effective authorization details * Added notes on URI size and authorization details
* Added requirement to return the effective authorization details
granted by the resource owner in the token response granted by the resource owner in the token response
o changed "authorization_details" structure from object to array * changed "authorization_details" structure from object to array
o added Justin Richer & Brian Campbell as Co-Authors * added Justin Richer & Brian Campbell as Co-Authors
-00 / -01 -00 / -01
o first draft * first draft
Authors' Addresses Authors' Addresses
Torsten Lodderstedt Torsten Lodderstedt
yes.com yes.com
Email: torsten@lodderstedt.net Email: torsten@lodderstedt.net
Justin Richer Justin Richer
Bespoke Engineering Bespoke Engineering
 End of changes. 75 change blocks. 
140 lines changed or deleted 145 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/