rfc9396.original		rfc9396.txt
	Web Authorization Protocol T. Lodderstedt		Internet Engineering Task Force (IETF) T. Lodderstedt
	Internet-Draft yes.com		Request for Comments: 9396 yes.com
	Intended status: Standards Track J. Richer		Category: Standards Track J. Richer
	Expires: 25 June 2023 Bespoke Engineering		ISSN: 2070-1721 Bespoke Engineering
	B. Campbell		B. Campbell
	Ping Identity		Ping Identity
	22 December 2022		May 2023
	OAuth 2.0 Rich Authorization Requests		OAuth 2.0 Rich Authorization Requests
	draft-ietf-oauth-rar-22
	Abstract		Abstract
	This document specifies a new parameter authorization_details that is		This document specifies a new parameter authorization_details that is
	used to carry fine-grained authorization data in OAuth messages.		used to carry fine-grained authorization data in OAuth messages.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This is an Internet Standards Track document.
	provisions of BCP 78 and BCP 79.
	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 https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		Internet Engineering Steering Group (IESG). Further information on
			Internet Standards is available in Section 2 of RFC 7841.
	This Internet-Draft will expire on 25 June 2023.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			https://www.rfc-editor.org/info/rfc9396.
	Copyright Notice		Copyright Notice
	Copyright (c) 2022 IETF Trust and the persons identified as the		Copyright (c) 2023 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents
	license-info) in effect on the date of publication of this document.		(https://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights		publication of this document. Please review these documents
	and restrictions with respect to this document. Code Components		carefully, as they describe your rights and restrictions with respect
	extracted from this document must include Revised BSD License text as		to this document. Code Components extracted from this document must
	described in Section 4.e of the Trust Legal Provisions and are		include Revised BSD License text as described in Section 4.e of the
	provided without warranty as described in the Revised BSD License.		Trust Legal Provisions and are provided without warranty as described
			in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction
	1.1. Conventions and Terminology . . . . . . . . . . . . . . . 4		1.1. Conventions and Terminology
	2. Request parameter "authorization_details" . . . . . . . . . . 4		2. Request Parameter "authorization_details"
	2.1. Authorization Details Types . . . . . . . . . . . . . . . 7		2.1. Authorization Details Types
	2.2. Common data fields . . . . . . . . . . . . . . . . . . . 8		2.2. Common Data Fields
	3. Authorization Request . . . . . . . . . . . . . . . . . . . . 11		3. Authorization Request
	3.1. Relationship to "scope" parameter . . . . . . . . . . . . 13		3.1. Relationship to the "scope" Parameter
	3.2. Relationship to "resource" parameter . . . . . . . . . . 14		3.2. Relationship to the "resource" Parameter
	4. Authorization Response . . . . . . . . . . . . . . . . . . . 14		4. Authorization Response
	5. Authorization Error Response . . . . . . . . . . . . . . . . 14		5. Authorization Error Response
	6. Token Request . . . . . . . . . . . . . . . . . . . . . . . . 15		6. Token Request
	6.1. Comparing authorization details . . . . . . . . . . . . . 15		6.1. Comparing Authorization Details
	7. Token Response . . . . . . . . . . . . . . . . . . . . . . . 18		7. Token Response
	7.1. Enriched authorization details in Token Response . . . . 19		7.1. Enriched Authorization Details in Token Response
	8. Token Error Response . . . . . . . . . . . . . . . . . . . . 22		8. Token Error Response
	9. Resource Servers . . . . . . . . . . . . . . . . . . . . . . 23		9. Resource Servers
	9.1. JWT-based Access Tokens . . . . . . . . . . . . . . . . . 23		9.1. JWT-Based Access Tokens
	9.2. Token Introspection . . . . . . . . . . . . . . . . . . . 25		9.2. Token Introspection
	10. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . 26		10. Metadata
	11. Implementation Considerations . . . . . . . . . . . . . . . . 27		11. Implementation Considerations
	11.1. Using authorization details in a certain deployment . . 27		11.1. Using Authorization Details in a Certain Deployment
	11.2. Minimal implementation support . . . . . . . . . . . . . 28		11.2. Minimal Implementation Support
	11.3. Use of Machine-readable Type Schemas . . . . . . . . . . 28		11.3. Use of Machine-Readable Type Schemas
	11.4. Large requests . . . . . . . . . . . . . . . . . . . . . 29		11.4. Large Requests
	12. Security Considerations . . . . . . . . . . . . . . . . . . . 30		12. Security Considerations
	13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 30		13. Privacy Considerations
	14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31		14. IANA Considerations
	15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31		14.1. OAuth Parameters Registration
	15.1. OAuth Parameters Registration . . . . . . . . . . . . . 31		14.2. JSON Web Token Claims Registration
	15.2. JSON Web Token Claims Registration . . . . . . . . . . . 31		14.3. OAuth Token Introspection Response Registration
	15.3. OAuth Token Introspection Response Registration . . . . 32		14.4. OAuth Authorization Server Metadata Registration
	15.4. OAuth Authorization Server Metadata Registration . . . . 32		14.5. OAuth Dynamic Client Registration Metadata Registration
	15.5. OAuth Dynamic Client Registration Metadata		14.6. OAuth Extensions Error Registration
	Registration . . . . . . . . . . . . . . . . . . . . . . 32		15. References
	15.6. OAuth Extensions Error Registration . . . . . . . . . . 32		15.1. Normative References
	16. Normative References . . . . . . . . . . . . . . . . . . . . 33		15.2. Informative References
	17. Informative References . . . . . . . . . . . . . . . . . . . 33		Appendix A. Additional Examples
	Appendix A. Additional Examples . . . . . . . . . . . . . . . . 35		A.1. OpenID Connect
	A.1. OpenID Connect . . . . . . . . . . . . . . . . . . . . . 35		A.2. Remote Electronic Signing
	A.2. Remote Electronic Signing . . . . . . . . . . . . . . . . 37		A.3. Access to Tax Data
	A.3. Access to Tax Data . . . . . . . . . . . . . . . . . . . 38		A.4. eHealth
	A.4. eHealth . . . . . . . . . . . . . . . . . . . . . . . . . 39		Acknowledgements
	Appendix B. Document History . . . . . . . . . . . . . . . . . . 42		Authors' Addresses
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45
	1. Introduction		1. Introduction
	The OAuth 2.0 authorization framework [RFC6749] defines the scope		"The OAuth 2.0 Authorization Framework" [RFC6749] defines the scope
	parameter that allows OAuth clients to specify the requested scope,		parameter that allows OAuth clients to specify the requested scope,
	i.e., the limited capability, of an access token. This mechanism is		i.e., the limited capability, of an access token. This mechanism is
	sufficient to implement static scenarios and coarse-grained		sufficient to implement static scenarios and coarse-grained
	authorization requests, such as "give me read access to the resource		authorization requests, such as "give me read access to the resource
	owner's profile" but it is not sufficient to specify fine-grained		owner's profile." However, it is not sufficient to specify fine-
	authorization requirements, such as "please let me transfer an amount		grained authorization requirements, such as "please let me transfer
	of 45 Euros to Merchant A" or "please give me read access to		an amount of 45 Euros to Merchant A" or "please give me read access
	directory A and write access to file X".		to directory A and write access to file X."
	This specification introduces a new parameter authorization_details		This specification introduces a new parameter authorization_details
	that allows clients to specify their fine-grained authorization		that allows clients to specify their fine-grained authorization
	requirements using the expressiveness of JSON [RFC8259] data		requirements using the expressiveness of JSON [RFC8259] data
	structures.		structures.
	For example, an authorization request for a credit transfer		For example, an authorization request for a credit transfer
	(designated as "payment initiation" in several open banking		(designated as "payment initiation" in several open banking
	initiatives) can be represented using a JSON object like this:		initiatives) can be represented using a JSON object like this:
	skipping to change at page 3, line 43 ¶		skipping to change at line 130 ¶
	"amount": "123.50"		"amount": "123.50"
	},		},
	"creditorName": "Merchant A",		"creditorName": "Merchant A",
	"creditorAccount": {		"creditorAccount": {
	"bic":"ABCIDEFFXXX",		"bic":"ABCIDEFFXXX",
	"iban": "DE02100100109307118603"		"iban": "DE02100100109307118603"
	},		},
	"remittanceInformationUnstructured": "Ref Number Merchant"		"remittanceInformationUnstructured": "Ref Number Merchant"
	}		}
	Figure 1: Example authorization request for a credit transfer.		Figure 1: Example of an Authorization Request for a Credit Transfer
	This object contains detailed information about the intended payment,		This object contains detailed information about the intended payment,
	such as amount, currency, and creditor, that are required to inform		such as amount, currency, and creditor, that is required to inform
	the user and obtain their consent. The authorization server (AS) and		the user and obtain their consent. The authorization server (AS) and
	the respective resource server (RS) (providing the payment initiation		the respective resource server (RS) (providing the payment initiation
	API) will together enforce this consent.		API) will together enforce this consent.
	For a comprehensive discussion of the challenges arising from new use		For a comprehensive discussion of the challenges arising from new use
	cases in the open banking and electronic signing spaces see		cases in the open banking and electronic signing spaces, see
	[transaction-authorization].		[Transaction-Auth].
	In addition to facilitating custom authorization requests, this		In addition to facilitating custom authorization requests, this
	specification also introduces a set of common data type fields for		specification also introduces a set of common data type fields for
	use across different APIs.		use across different APIs.
	1.1. Conventions and Terminology		1.1. Conventions and Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	This specification uses the terms "access token", "refresh token",		This specification uses the terms "access token", "refresh token",
	"authorization server", "resource server", "authorization endpoint",		"authorization server" (AS), "resource server" (RS), "authorization
	"authorization request", "authorization response", "token endpoint",		endpoint", "authorization request", "authorization response", "token
	"grant type", "access token request", "access token response", and		endpoint", "grant type", "access token request", "access token
	"client" defined by The OAuth 2.0 Authorization Framework [RFC6749].		response", and "client" defined by "The OAuth 2.0 Authorization
			Framework" [RFC6749].
	2. Request parameter "authorization_details"		2. Request Parameter "authorization_details"
	The request parameter authorization_details contains, in JSON		The request parameter authorization_details contains, in JSON
	notation, an array of objects. Each JSON object contains the data to		notation, an array of objects. Each JSON object contains the data to
	specify the authorization requirements for a certain type of		specify the authorization requirements for a certain type of
	resource. The type of resource or access requirement is determined		resource. The type of resource or access requirement is determined
	by the type field, which is defined as follows:		by the type field, which is defined as follows:
	type: An identifier for the authorization details type as a string.		type: An identifier for the authorization details type as a string.
	The value of the type field determines the allowable contents of		The value of the type field determines the allowable contents of
	the object which contains it and is unique for the described API		the object that contains it. The value is unique for the
	in the context of the AS. This field is REQUIRED.		described API in the context of the AS. This field is REQUIRED.
	An authorization_details array MAY contain multiple entries of the		An authorization_details array MAY contain multiple entries of the
	same type.		same type.
	This example shows an authorization_details of type		Figure 2 shows an authorization_details of type payment_initiation
	payment_initiation using the example data shown above:		using the example data shown above:
	[		[
	{		{
	"type": "payment_initiation",		"type": "payment_initiation",
	"actions": [		"actions": [
	"initiate",		"initiate",
	"status",		"status",
	"cancel"		"cancel"
	],		],
	"locations": [		"locations": [
	skipping to change at page 5, line 28 ¶		skipping to change at line 203 ¶
	"amount": "123.50"		"amount": "123.50"
	},		},
	"creditorName": "Merchant A",		"creditorName": "Merchant A",
	"creditorAccount": {		"creditorAccount": {
	"iban": "DE02100100109307118603"		"iban": "DE02100100109307118603"
	},		},
	"remittanceInformationUnstructured": "Ref Number Merchant"		"remittanceInformationUnstructured": "Ref Number Merchant"
	}		}
	]		]
	Figure 2: Example authorization_details for a credit transfer.		Figure 2: Example of "authorization_details" for a Credit Transfer
	This example shows a combined request asking for access to account		Figure 3 shows a combined request asking for access to account
	information and permission to initiate a payment:		information and permission to initiate a payment:
	[		[
	{		{
	"type": "account_information",		"type": "account_information",
	"actions": [		"actions": [
	"list_accounts",		"list_accounts",
	"read_balances",		"read_balances",
	"read_transactions"		"read_transactions"
	],		],
	skipping to change at page 6, line 39 ¶		skipping to change at line 242 ¶
	"amount": "123.50"		"amount": "123.50"
	},		},
	"creditorName": "Merchant A",		"creditorName": "Merchant A",
	"creditorAccount": {		"creditorAccount": {
	"iban": "DE02100100109307118603"		"iban": "DE02100100109307118603"
	},		},
	"remittanceInformationUnstructured": "Ref Number Merchant"		"remittanceInformationUnstructured": "Ref Number Merchant"
	}		}
	]		]
	Figure 3: Example authorization_details for a combined request.		Figure 3: Example of "authorization_details" for a Combined Request
	The JSON objects with type fields of account_information and		The JSON objects with type fields of account_information and
	payment_initiation represent the different authorization_details to		payment_initiation represent the different authorization_details to
	be used by the AS to ask for consent.		be used by the AS to ask for consent.
	Note: The AS will make this data subsequently available to the		| Note: The AS will make this data subsequently available to the
	respective resource servers (see Section 9).		| respective RSs (see Section 9).
	2.1. Authorization Details Types		2.1. Authorization Details Types
	Interpretation of the value of the type parameter, and the object		The AS controls the interpretation of the value of the type parameter
	fields that the type parameter allows, is under the control of the		as well as the object fields that the type parameter allows.
	AS. However, the value of the type parameter is also generally		However, the value of the type parameter is also generally documented
	documented and intended to be used by developers, it is RECOMMENDED		and intended to be used by developers. It is RECOMMENDED that API
	that API designers choose type values that are easily copied without		designers choose type values that are easily copied without
	ambiguity. For example, some glyphs have multiple Unicode code		ambiguity. For example, some glyphs have multiple Unicode code
	points for the same visual character, and a developer could		points for the same visual character, and a developer could
	potentially type a different character than what the AS has defined.		potentially type a different character than what the AS has defined.
	Possible means of reducing potential confusion are limiting the value		Possible means of reducing potential confusion are limiting the value
	to ASCII [RFC0020] characters, providing a machine-readable listing		to ASCII [RFC0020] characters, providing a machine-readable listing
	of data type values, or instructing developers to copy and paste		of data type values, or instructing developers to copy and paste
	directly from the documentation.		directly from the documentation.
	If an application or API is expected to be deployed across different		If an application or API is expected to be deployed across different
	servers, such as the case in an open standard, the API designer is		servers, such as the case in an open standard, the API designer is
	skipping to change at page 7, line 51 ¶		skipping to change at line 297 ¶
	{		{
	"path": "/myfiles/A/X",		"path": "/myfiles/A/X",
	"access": [		"access": [
	"read",		"read",
	"write"		"write"
	]		]
	}		}
	]		]
	}		}
	Figure 4: Example for authorization_details with a URL as type		Figure 4: Example of "authorization_details" with a URL as Type
	identifier.		Identifier
	2.2. Common data fields		2.2. Common Data Fields
	This specification defines a set of common data fields that are		This specification defines a set of common data fields that are
	designed to be usable across different types of APIs. This		designed to be usable across different types of APIs. This
	specification does not require the use of these common fields by an		specification does not require the use of these common fields by an
	API definition, but instead provides them as reusable generic		API definition but, instead, provides them as reusable generic
	components for API designers to make use of. The allowable values of		components for API designers to make use of. The allowable values of
	all fields are determined by the API being protected, as defined by a		all fields are determined by the API being protected, as defined by a
	particular "type" value.		particular "type" value.
	locations: An array of strings representing the location of the		locations: An array of strings representing the location of the
	resource or resource server. These strings are typically URIs		resource or RS. These strings are typically URIs identifying the
	identifying the location of the RS. This field can allow a client		location of the RS. This field can allow a client to specify a
	to specify a particular RS, as discussed in Section 12.		particular RS, as discussed in Section 12.
	actions: An array of strings representing the kinds of actions to be		actions: An array of strings representing the kinds of actions to be
	taken at the resource.		taken at the resource.
	datatypes: An array of strings representing the kinds of data being		datatypes: An array of strings representing the kinds of data being
	requested from the resource.		requested from the resource.
	identifier: A string identifier indicating a specific resource		identifier: A string identifier indicating a specific resource
	available at the API.		available at the API.
	privileges: An array of strings representing the types or levels of		privileges: An array of strings representing the types or levels of
	privilege being requested at the resource.		privilege being requested at the resource.
	When different common data fields are used in combination, the		When different common data fields are used in combination, the
	permissions the client requests are the product of all the values.		permissions the client requests are the product of all the values.
	The object represents a request for all action values listed within		The object represents a request for all actions values listed within
	the object to be used at all locations values listed within the		the object to be used at all locations values listed within the
	object for all datatype values listed within the object. In the		object for all datatypes values listed within the object. In the
	following example, the client is requesting read and write access to		following example, the client is requesting read and write access to
	both the contacts and photos belonging to customers in a		both the contacts and photos belonging to customers in a
	customer_information API. If this request is granted, the client		customer_information API. If this request is granted, the client
	would assume it would be able to use any combination of rights		would assume it would be able to use any combination of rights
	defined by the API, such as reading the photos and writing the		defined by the API, such as read access to the photos and write
	contacts.		access to the contacts.
	[		[
	{		{
	"type": "customer_information",		"type": "customer_information",
	"locations": [		"locations": [
	"https://example.com/customers"		"https://example.com/customers"
	],		],
	"actions": [		"actions": [
	"read",		"read",
	"write"		"write"
	],		],
	"datatypes": [		"datatypes": [
	"contacts",		"contacts",
	"photos"		"photos"
	]		]
	}		}
	]		]
	Figure 5: Example for authorization_details with common data fields.		Figure 5: Example of "authorization_details" with Common Data Fields
	If the client wishes to have finer control over its access, it can		If the client wishes to have finer control over its access, it can
	send multiple objects. In this example, the client is asking for		send multiple objects. In this example, the client is asking for
	read access to the contacts and write access to the photos in the		read access to the contacts and write access to the photos in the
	same API endpoint. If this request is granted, the client would not		same API endpoint. If this request is granted, the client would not
	be able to write to the contacts.		be able to write to the contacts.
	[		[
	{		{
	"type": "customer_information",		"type": "customer_information",
	skipping to change at page 10, line 32 ¶		skipping to change at line 391 ¶
	],		],
	"actions": [		"actions": [
	"write"		"write"
	],		],
	"datatypes": [		"datatypes": [
	"photos"		"photos"
	]		]
	}		}
	]		]
	Figure 6: Example for authorization_details with common data		Figure 6: Example of "authorization_details" with Common Data
	fields in multiple objects.		Fields in Multiple Objects
	An API MAY define its own extensions, subject to the type of the		An API MAY define its own extensions, subject to the type of the
	respective authorization object. It is anticipated that API		respective authorization object. It is anticipated that API
	designers will use a combination of common data fields defined in		designers will use a combination of common data fields defined in
	this specification as well as fields specific to the API itself. The		this specification as well as fields specific to the API itself. The
	following non-normative example shows the use of both common and API-		following non-normative example shows the use of both common and API-
	specific fields as part of two different fictitious API type values.		specific fields as part of two different fictitious API type values.
	The first access request includes the actions, locations, and		The first access request includes the actions, locations, and
	datatypes fields specified here as well as the API-specific		datatypes fields specified here as well as the API-specific
	geolocation field, indicating access to photos taken at the given		geolocation field, indicating access to photos taken at the given
	skipping to change at page 11, line 41 ¶		skipping to change at line 443 ¶
	{		{
	"type":"financial-transaction",		"type":"financial-transaction",
	"actions":[		"actions":[
	"withdraw"		"withdraw"
	],		],
	"identifier":"account-14-32-32-3",		"identifier":"account-14-32-32-3",
	"currency":"USD"		"currency":"USD"
	}		}
	]		]
	Figure 7: Example for authorization_details using common and		Figure 7: Example of "authorization_details" Using Common and
	extension data fields.		Extension Data Fields
	If this request is approved, the resulting access token's access		If this request is approved, the resulting access token's access
	rights will be the union of the requested types of access for each of		rights will be the union of the requested types of access for each of
	the two APIs, just as above.		the two APIs, just as above.
	3. Authorization Request		3. Authorization Request
	The authorization_details authorization request parameter can be used		The authorization_details authorization request parameter can be used
	to specify authorization requirements in all places where the scope		to specify authorization requirements in all places where the scope
	parameter is used for the same purpose, examples include:		parameter is used for the same purpose, examples include:
	* Authorization requests as specified in [RFC6749],		* authorization requests as specified in [RFC6749]
	* Device Authorization Request as specified in [RFC8628],
	* Backchannel Authentication Requests as defined in [OpenID.CIBA].		* device authorization requests as specified in [RFC8628]
			* backchannel authentication requests as defined in [OID-CIBA]
	In case of authorization requests as defined in [RFC6749],		In case of authorization requests as defined in [RFC6749],
	implementors MAY consider using pushed authorization requests		implementers MAY consider using pushed authorization requests
	[RFC9126] to improve the security, privacy, and reliability of the		[RFC9126] to improve the security, privacy, and reliability of the
	flow. See Section 12, Section 13, and Section 11.4 for details.		flow. See Sections 12, 13, and 11.4 for details.
	Parameter encoding is determined by the respective context. In the		Parameter encoding is determined by the respective context. In the
	context of an authorization request according to [RFC6749], the		context of an authorization request according to [RFC6749], the
	parameter is encoded using the application/x-www-form-urlencoded		parameter is encoded using the application/x-www-form-urlencoded
	format of the serialized JSON as shown in the following using the		format of the serialized JSON as shown in Figure 8, using the example
	example from Section 2 (line breaks for display purposes only):		from Section 2 (line breaks for display purposes only):
	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_rEMTJ3bwc-uCHaoeK1t8U		&code_challenge=K2-ltc83acc4h0c9w6ESC_rEMTJ3bwc-uCHaoeK1t8U
	&authorization_details=%5B%7B%22type%22%3A%22account%5Finfo		&authorization_details=%5B%7B%22type%22%3A%22account%5Finfo
	rmation%22%2C%22actions%22%3A%5B%22list%5Faccounts%22%2C%22		rmation%22%2C%22actions%22%3A%5B%22list%5Faccounts%22%2C%22
	read%5Fbalances%22%2C%22read%5Ftransactions%22%5D%2C%22loca		read%5Fbalances%22%2C%22read%5Ftransactions%22%5D%2C%22loca
	tions%22%3A%5B%22https%3A%2F%2Fexample%2Ecom%2Faccounts%22%		tions%22%3A%5B%22https%3A%2F%2Fexample%2Ecom%2Faccounts%22%
	5D%7D%2C%7B%22type%22%3A%22payment%5Finitiation%22%2C%22act		5D%7D%2C%7B%22type%22%3A%22payment%5Finitiation%22%2C%22act
	ions%22%3A%5B%22initiate%22%2C%22status%22%2C%22cancel%22%5		ions%22%3A%5B%22initiate%22%2C%22status%22%2C%22cancel%22%5
	D%2C%22locations%22%3A%5B%22https%3A%2F%2Fexample%2Ecom%2Fp		D%2C%22locations%22%3A%5B%22https%3A%2F%2Fexample%2Ecom%2Fp
	ayments%22%5D%2C%22instructedAmount%22%3A%7B%22currency%22%		ayments%22%5D%2C%22instructedAmount%22%3A%7B%22currency%22%
	3A%22EUR%22%2C%22amount%22%3A%22123%2E50%22%7D%2C%22credito		3A%22EUR%22%2C%22amount%22%3A%22123%2E50%22%7D%2C%22credito
	rName%22%3A%22Merchant%20A%22%2C%22creditorAccount%22%3A%7B%		rName%22%3A%22Merchant%20A%22%2C%22creditorAccount%22%3A%7B
	22iban%22%3A%22DE02100100109307118603%22%7D%2C%22remittance		%22iban%22%3A%22DE02100100109307118603%22%7D%2C%22remittanc
	InformationUnstructured%22%3A%22RefNumberMerchant%22%7D%5D HTTP/1.1		eInformationUnstructured%22%3A%22Ref%20Number%20Merchant%22
	Host: server.example.com		%7D%5D HTTP/1.1
			Host: server.example.com
	Figure 8: Example authorization request with authorization_details.		Figure 8: Example of Authorization Request with
			"authorization_details"
	Based on the data provided in the authorization_details parameter the		Based on the data provided in the authorization_details parameter,
	AS will ask the user for consent to the requested access permissions.		the AS will ask the user for consent to the requested access
			permissions.
	Note: the user may also grant a subset of the requested authorization		| Note: The user may also grant a subset of the requested
	details.		| authorization details.
	In this example, the client wants to get access to account		In Figure 9, the client wants to get access to account information
	information and initiate a payment:		and initiate a payment:
	[		[
	{		{
	"type": "account_information",		"type": "account_information",
	"actions": [		"actions": [
	"list_accounts",		"list_accounts",
	"read_balances",		"read_balances",
	"read_transactions"		"read_transactions"
	],		],
	"locations": [		"locations": [
	skipping to change at page 13, line 39 ¶		skipping to change at line 541 ¶
	"amount": "123.50"		"amount": "123.50"
	},		},
	"creditorName": "Merchant A",		"creditorName": "Merchant A",
	"creditorAccount": {		"creditorAccount": {
	"iban": "DE02100100109307118603"		"iban": "DE02100100109307118603"
	},		},
	"remittanceInformationUnstructured": "Ref Number Merchant"		"remittanceInformationUnstructured": "Ref Number Merchant"
	}		}
	]		]
	Figure 9: URL decoded authorization_details.		Figure 9: URL Decoded "authorization_details"
	3.1. Relationship to "scope" parameter		3.1. Relationship to the "scope" Parameter
	authorization_details and scope can be used in the same authorization		authorization_details and scope can be used in the same authorization
	request for carrying independent authorization requirements.		request for carrying independent authorization requirements.
	Combined use of authorization_details and scope is supported by this		Combined use of authorization_details and scope is supported by this
	specification in part to allow existing OAuth-based applications to		specification in part to allow existing OAuth-based applications to
	incrementally migrate towards using authorization_details		incrementally migrate towards using authorization_details
	exclusively. It is RECOMMENDED that a given API use only one form of		exclusively. It is RECOMMENDED that a given API use only one form of
	requirement specification.		requirement specification.
	skipping to change at page 14, line 17 ¶		skipping to change at line 566 ¶
	the AS combines these parameters are specific to the APIs being		the AS combines these parameters are specific to the APIs being
	protected and outside the scope of this specification.		protected and outside the scope of this specification.
	When gathering user consent, the AS MUST present the merged set of		When gathering user consent, the AS MUST present the merged set of
	requirements represented by the authorization request.		requirements represented by the authorization request.
	If the resource owner grants the client the requested access, the AS		If the resource owner grants the client the requested access, the AS
	will issue tokens to the client that are associated with the		will issue tokens to the client that are associated with the
	respective authorization_details (and scope values, if applicable).		respective authorization_details (and scope values, if applicable).
	3.2. Relationship to "resource" parameter		3.2. Relationship to the "resource" Parameter
	The resource authorization request parameter as defined in [RFC8707]		The resource authorization request parameter, as defined in
	can be used to further determine the resources where the requested		[RFC8707], can be used to further determine the resources where the
	scope can be applied. The resource parameter does not have any		requested scope can be applied. The resource parameter does not have
	impact on the way the AS processes the authorization_details		any impact on the way the AS processes the authorization_details
	authorization request parameter.		authorization request parameter.
	4. Authorization Response		4. Authorization Response
	This specification does not define extensions to the authorization		This specification does not define extensions to the authorization
	response.		response.
	5. Authorization Error Response		5. Authorization Error Response
	The AS MUST refuse to process any unknown authorization details type		The AS MUST refuse to process any unknown authorization details type
	or authorization details not conforming to the respective type		or authorization details not conforming to the respective type
	definition. The AS MUST abort processing and respond with an error		definition. The AS MUST abort processing and respond with an error
	invalid_authorization_details to the client if any of the following		invalid_authorization_details to the client if any of the following
	are true of the objects in authorization_details structure:		are true of the objects in the authorization_details structure:
	* Contains an unknown authorization details type value,		* contains an unknown authorization details type value,
	* An object of known type but containing unknown fields,
	* Contains fields of the wrong type for the authorization details		* is an object of known type but containing unknown fields,
			* contains fields of the wrong type for the authorization details
	type,		type,
	* Contains fields with invalid values for the authorization details
			* contains fields with invalid values for the authorization details
	type, or		type, or
	* Missing required fields for the authorization details type.
			* is missing required fields for the authorization details type.
	6. Token Request		6. Token Request
	The authorization_details token request parameter can be used to		The authorization_details token request parameter can be used to
	specify the authorization details a client wants the AS to assign to		specify the authorization details that a client wants the AS to
	an access token. The AS checks whether the underlying grant (in case		assign to an access token. The AS checks whether the underlying
	of grant types authorization_code, refresh_token, ...) or the		grant (in case of grant types authorization_code, refresh_token,
	client's policy (in case of grant type client_credential) allows the		etc.) or the client's policy (in case of grant type
	issuance of an access token with the requested authorization details.		client_credentials) allows the issuance of an access token with the
	Otherwise, the AS refuses the request with the error code		requested authorization details. Otherwise, the AS refuses the
	invalid_authorization_details (similar to invalid_scope).		request with the error code invalid_authorization_details (similar to
			invalid_scope).
	6.1. Comparing authorization details		6.1. Comparing Authorization Details
	Many actions in the OAuth protocol allow the AS and RS to make		Many actions in the OAuth protocol allow the AS and RS to make
	security decisions based on whether the request is asking for "more"		security decisions based on whether the request is asking for "more"
	or "less" than a previous, existing request. For example, upon		or "less" than a previous, existing request. For example, upon
	refreshing a token, the client can ask for a new access token with		refreshing a token, the client can ask for a new access token with
	"fewer permissions" than had been previously authorized by the		"fewer permissions" than had been previously authorized by the
	resource owner. The requested access token will convey the reduced		resource owner. The requested access token will convey the reduced
	permissions but the resource owner's previous authorization is		permissions, but the resource owner's previous authorization is
	unchanged by such requests. Since the semantics of the fields in the		unchanged by such requests. Since the semantics of the fields in the
	authorization_details will be implementation specific to a given API		authorization_details will be implementation specific to a given API
	or set of APIs, there is no standardized mechanism to compare two		or set of APIs, there is no standardized mechanism to compare two
	arbitrary authorization detail requests. Authorization servers		arbitrary authorization detail requests. An AS should not rely on
	should not rely on simple object comparison in most cases, as the		simple object comparison in most cases, as the intersection of some
	intersection of some fields within a request could have side effects		fields within a request could have side effects on the access rights
	on the access rights granted, depending on how the API has been		granted, depending on how the API has been designed and deployed.
	designed and deployed. This is a similar effect to the scope values		This is a similar effect to the scope values used with some APIs.
	used with some APIs.
	When comparing a new request to an existing request, authorization		When comparing a new request to an existing request, an AS can use
	servers can use the same processing techniques as used in granting		the same processing techniques as used in granting the request in the
	the request in the first place to determine if a resource owner needs		first place to determine if a resource owner needs to authorize the
	to authorize the request. The details of this comparison are		request. The details of this comparison are dependent on the
	dependent on the definition of the type of authorization request and		definition of the type of authorization request and outside the scope
	outside the scope of this specification, but common patterns can be		of this specification, but common patterns can be applied.
	applied.
	This shall be illustrated using our running example. The example		This shall be illustrated using our running example. The example
	authorization request in Section 3, if approved by the user, resulted		authorization request in Section 3, if approved by the user, resulted
	in the issuance of an authorization code associated with the		in the issuance of an authorization code associated with the
	privileges to		privileges to:
			* list accounts,
	* list accounts
	* access the balance of one or more accounts,		* access the balance of one or more accounts,
	* access the transactions of one or more accounts, and		* access the transactions of one or more accounts, and
	* to initiate, check the status of, and cancel a payment.
			* initiate, check the status of, and cancel a payment.
	The client could now request the AS to issue an access token assigned		The client could now request the AS to issue an access token assigned
	with the privilege to just access a list of accounts as follows:		with the privilege to just access a list of accounts as follows:
	[		[
	{		{
	"type": "account_information",		"type": "account_information",
	"actions": [		"actions": [
	"list_accounts"		"list_accounts"
	],		],
	"locations": [		"locations": [
	"https://example.com/accounts"		"https://example.com/accounts"
	]		]
	}		}
	]		]
	Figure 10: Example for authorization_details reduced privileges.		Figure 10: Example of "authorization_details" Reduced Privileges
	The example API is designed such that each field used by the		The example API is designed such that each field used by the
	account_information type contains additive rights, with each value		account_information type contains additive rights, with each value
	within the actions and locations arrays specifying a different		within the actions and locations arrays specifying a different
	element of access. To make a comparison in this instance, the AS		element of access. To make a comparison in this instance, the AS
	would perform the following steps:		would perform the following steps:
	* compare that the authorization code issued in the previous step		* verify that the authorization code issued in the previous step
	contains an authorization details object of type		contains an authorization details object of type
	account_information		account_information,
	* compare whether the approved list of actions contains
	list_account, and		* verify whether the approved list of actions contains
	* whether the locations value includes only previously-approved		list_accounts, and
	locations.
			* verify whether the locations value includes only previously
			approved locations.
	If all checks succeed, the AS would issue the requested access token		If all checks succeed, the AS would issue the requested access token
	with the reduced set of access.		with the reduced set of access.
	Note that this comparison is relevant to this specific API type		Note that this comparison is relevant to this specific API type
	definition. A different API type definition could have different		definition. A different API type definition could have different
	processing rules. For example, the value of an action could subsume		processing rules. For example, an actions value could subsume the
	the rights associated with another action value. For example, if a		rights associated with another actions value. For example, if a
	client initially asks for a token with write access, which implies		client initially asks for a token with write access, this implies
	both read and write access to this API:		both read and write access to this API:
	[		[
	{		{
	"type": "example_api",		"type": "example_api",
	"actions": [		"actions": [
	"write"		"write"
	]		]
	}		}
	]		]
	Figure 11: Example for authorization_details requesting "write"		Figure 11: Example of "authorization_details" Requesting "write"
	access to an API.		Access to an API
	Later that same client makes a refresh request for read access:		Later, that same client makes a refresh request for read access:
	[		[
	{		{
	"type": "example_api",		"type": "example_api",
	"actions": [		"actions": [
	"read"		"read"
	]		]
	}		}
	]		]
	Figure 12: Example for authorization_details requesting "read"		Figure 12: Example of "authorization_details" Requesting "read"
	access to an API.		Access to an API
	The AS would compare the type value and the action value to determine		The AS would compare the type value and the actions value to
	that the read access is already covered by the write access		determine that the read access is already covered by the write access
	previously granted to the client.		previously granted to the client.
	This same API could be designed with a possible value for privileges		This same API could be designed with a possible value for privileges
	of admin, used in this example to denote that the resulting token is		of admin, used in this example to denote that the resulting token is
	allowed to perform any functions on the resources. If that client is		allowed to perform any of the functions on the resources. If that
	then granted such admin privileges to the API:		client is then granted such admin privileges to the API, the
			authorization_details would be as follows:
	[		[
	{		{
	"type": "example_api",		"type": "example_api",
	"privileges": [		"privileges": [
	"admin"		"admin"
	]		]
	}		}
	]		]
	Figure 13: Example for authorization_details requesting "admin"		Figure 13: Example of "authorization_details" with "admin" Access
	access to an API.		to an API
	The AS would compare the type value and find the privileges value		The AS would compare the type value and find that the privileges
	subsumes any aspects of read or write access that had been granted to		value subsumes any aspects of read or write access that had been
	the client previously. Note that other API definitions can use		granted to the client previously. Note that other API definitions
	privileges such that values do not subsume one another.		can use privileges such that values do not subsume one another.
	The next example shows how the client can use the common data element		The next example shows how the client can use the common data element
	locations (see Section 2.2) to request the issuance of an access		locations (see Section 2.2) to request the issuance of an access
	token restricted to a certain resource server. In our running		token restricted to a certain RS. In our running example, the client
	example, the client may ask for all permissions of the approved grant		may ask for all permissions of the approved grant of type
	of type payment_iniation applicable to the resource server residing		payment_initiation applicable to the RS residing at
	at https://example.com/payments as follows:		https://example.com/payments as follows:
	[		[
	{		{
	"type": "payment_initiation",		"type": "payment_initiation",
	"locations": [		"locations": [
	"https://example.com/payments"		"https://example.com/payments"
	]		]
	}		}
	]		]
	Figure 14: Example for authorization_details requesting an		Figure 14: Example of "authorization_details" Requesting an
	audience restricted access token.		Audience-Restricted Access Token
	7. Token Response		7. Token Response
	In addition to the token response parameters as defined in [RFC6749],		In addition to the token response parameters as defined in [RFC6749],
	the authorization server MUST also return the authorization_details		the AS MUST also return the authorization_details as granted by the
	as granted by the resource owner and assigned to the respective		resource owner and assigned to the respective access token.
	access token.
	The authorization details assigned to the access token issued in a		The authorization details assigned to the access token issued in a
	token response are determined by the authorization_details parameter		token response are determined by the authorization_details parameter
	of the corresponding token request. If the client does not specify		of the corresponding token request. If the client does not specify
	the authorization_details token request parameters, the AS determines		the authorization_details token request parameters, the AS determines
	the resulting authorization_details at its discretion.		the resulting authorization_details at its discretion.
	The AS MAY omit values in the authorization_details to the client.		The AS MAY omit values in the authorization_details to the client.
	For our running example, this would look like this:		For our running example, it would look like this:
	HTTP/1.1 200 OK		HTTP/1.1 200 OK
	Content-Type: application/json		Content-Type: application/json
	Cache-Control: no-store		Cache-Control: no-store
	{		{
	"access_token": "2YotnFZFEjr1zCsicMWpAA",		"access_token": "2YotnFZFEjr1zCsicMWpAA",
	"token_type": "example",		"token_type": "example",
	"expires_in": 3600,		"expires_in": 3600,
	"refresh_token": "tGzv3JOkF0XG5Qx2TlKWIA",		"refresh_token": "tGzv3JOkF0XG5Qx2TlKWIA",
	skipping to change at page 19, line 38 ¶		skipping to change at line 813 ¶
	},		},
	"creditorName": "Merchant A",		"creditorName": "Merchant A",
	"creditorAccount": {		"creditorAccount": {
	"iban": "DE02100100109307118603"		"iban": "DE02100100109307118603"
	},		},
	"remittanceInformationUnstructured": "Ref Number Merchant"		"remittanceInformationUnstructured": "Ref Number Merchant"
	}		}
	]		]
	}		}
	Figure 15: Example token response.		Figure 15: Example Token Response
	7.1. Enriched authorization details in Token Response		7.1. Enriched Authorization Details in Token Response
	The authorization details attached to the access token MAY differ		The authorization details attached to the access token MAY differ
	from what the client requests. In addition to the user authorizing		from what the client requests. In addition to the user authorizing
	less than what the client requested, there are some use cases where		less than what the client requested, there are some use cases where
	the authorization server enriches the data in an authorization		the AS enriches the data in an authorization details object. Whether
	details object. Whether enrichment is allowed and specifics of how		enrichment is allowed and specifics of how it works are necessarily
	it works are necessarily part of the definition of the respective		part of the definition of the respective authorization details type.
	authorization details type.
	As one example, a client may ask for access to account information		As one example, a client may ask for access to account information
	but leave the decision about the specific accounts it will be able to		but leave the decision about the specific accounts it will be able to
	access to the user. The user would, during the course of the		access to the user. During the course of the authorization process,
	authorization process, select the subset of their accounts that they		the user would select the subset of their accounts that they want to
	want to allow the client to access. As one design option to convey		allow the client to access. As one design option to convey the
	the selected accounts, the authorization server could add this		selected accounts, the AS could add this information to the
	information to the respective authorization details object.		respective authorization details object.
	In that example, the requested authorization detail parameter might		In that example, the requested authorization_details parameter might
	look like the following. In this example the empty arrays serve as		look like the following. In this example, the empty arrays serve as
	placeholders for where data will be added during enrichment by the		placeholders for where data will be added during enrichment by the
	AS. This example is illustrative only and is not intended to suggest		AS. This example is illustrative only and is not intended to suggest
	a preference for designing the specifics of any authorization details		a preference for designing the specifics of any authorization details
	type this way.		type this way.
	"authorization_details": [		"authorization_details": [
	{		{
	"type": "account_information",		"type": "account_information",
	"access": {		"access": {
	"accounts": [],		"accounts": [],
	"balances": [],		"balances": [],
	"transactions": []		"transactions": []
	},		},
	"recurringIndicator":true		"recurringIndicator":true
	}		}
	]		]
	Figure 16: Example for requested authorization_details.		Figure 16: Example of Requested "authorization_details"
	The authorization server then would expand the authorization details		The AS then would expand the authorization details object and add the
	object and add the respective account identifiers.		respective account identifiers.
	HTTP/1.1 200 OK		HTTP/1.1 200 OK
	Content-Type: application/json		Content-Type: application/json
	Cache-Control: no-store		Cache-Control: no-store
	{		{
	"access_token":"2YotnFZFEjr1zCsicMWpAA",		"access_token":"2YotnFZFEjr1zCsicMWpAA",
	"token_type":"example",		"token_type":"example",
	"expires_in":3600,		"expires_in":3600,
	"refresh_token":"tGzv3JokF0XG5Qx2TlKWIA",		"refresh_token":"tGzv3JokF0XG5Qx2TlKWIA",
	skipping to change at page 21, line 45 ¶		skipping to change at line 896 ¶
	{		{
	"maskedPan":"123456xxxxxx1234"		"maskedPan":"123456xxxxxx1234"
	}		}
	]		]
	},		},
	"recurringIndicator":true		"recurringIndicator":true
	}		}
	]		]
	}		}
	Figure 17: Example for enriched authorization_details.		Figure 17: Example of Enriched "authorization_details"
	For another example, the client is asking for access to a medical		For another example, the client is asking for access to a medical
	record but does not know the record number at request time. In this		record but does not know the record number at request time. In this
	example, the client specifies the type of access it wants but doesn't		example, the client specifies the type of access it wants but doesn't
	specify the location or identifier of that access.		specify the location or identifier of that access.
	{		{
	"authorization_details": [		"authorization_details": [
	{		{
	"type": "medical_record",		"type": "medical_record",
	"sens": [ "HIV", "ETH", "MART" ],		"sens": [ "HIV", "ETH", "MART" ],
	"actions": [ "read" ],		"actions": [ "read" ],
	"datatypes": [ "Patient", "Observation", "Appointment" ]		"datatypes": [ "Patient", "Observation", "Appointment" ]
	}		}
	]}		]}
	Figure 18: Example for requested authorization_details.		Figure 18: Example of Requested "authorization_details"
	When the user interacts with the AS, they select which of the medical		When the user interacts with the AS, they select which of the medical
	records they are responsible for giving to the client. This		records they are responsible for giving to the client. This
	information gets returned with the access token.		information gets returned with the access token.
	{		{
	"access_token":"2YotnFZFEjr1zCsicMWpAA",		"access_token":"2YotnFZFEjr1zCsicMWpAA",
	"token_type":"example",		"token_type":"example",
	"expires_in":3600,		"expires_in":3600,
	"refresh_token":"tGzv3JokF0XG5Qx2TlKWIA",		"refresh_token":"tGzv3JokF0XG5Qx2TlKWIA",
	skipping to change at page 22, line 38 ¶		skipping to change at line 936 ¶
	"type": "medical_record",		"type": "medical_record",
	"sens": [ "HIV", "ETH", "MART" ],		"sens": [ "HIV", "ETH", "MART" ],
	"actions": [ "read" ],		"actions": [ "read" ],
	"datatypes": [ "Patient", "Observation", "Appointment" ],		"datatypes": [ "Patient", "Observation", "Appointment" ],
	"identifier": "patient-541235",		"identifier": "patient-541235",
	"locations": [ "https://records.example.com/" ]		"locations": [ "https://records.example.com/" ]
	}		}
	]		]
	}		}
	Figure 19: Example for enriched authorization_details.		Figure 19: Example of Enriched "authorization_details"
	Note: the client needs to be aware upfront of the possibility that a		| Note: The client needs to be aware upfront of the possibility
	certain authorization details object can be enriched. It is assumed		| that a certain authorization details object can be enriched.
	that this property is part of the definition of the respective		| It is assumed that this property is part of the definition of
	authorization details type.		| the respective authorization details type.
	8. Token Error Response		8. Token Error Response
	The Token Error Response MUST conform to the rules given in		The Token Error Response MUST conform to the rules given in
	Section 5.		Section 5.
	9. Resource Servers		9. Resource Servers
	In order to enable the RS to enforce the authorization details as		In order to enable the RS to enforce the authorization details as
	approved in the authorization process, the AS MUST make this data		approved in the authorization process, the AS MUST make this data
	available to the RS. The AS MAY add the authorization_details field		available to the RS. The AS MAY add the authorization_details field
	to access tokens in JWT format or to Token Introspection responses.		to access tokens in JSON Web Token (JWT) format or to token
			introspection responses.
	9.1. JWT-based Access Tokens		9.1. JWT-Based Access Tokens
	If the access token is a JWT [RFC7519], the AS is RECOMMENDED to add		If the access token is a JWT [RFC7519], the AS is RECOMMENDED to add
	the authorization_details object, filtered to the specific audience,		the authorization details object, filtered to the specific audience,
	as a top-level claim.		as a top-level claim.
	The AS will typically also add further claims to the JWT the RS		The AS will typically also add further claims to the JWT that the RS
	requires for request processing, e.g., user id, roles, and		requires request processing, e.g., user ID, roles, and transaction-
	transaction-specific data. What claims the particular RS requires is		specific data. What claims the particular RS requires is defined by
	defined by the RS-specific policy with the AS.		the RS-specific policy with the AS.
	The following shows the contents of an example JWT for the payment		The following shows the contents of an example JWT for the payment
	initiation example above:		initiation example above:
	{		{
	"iss": "https://as.example.com",		"iss": "https://as.example.com",
	"sub": "24400320",		"sub": "24400320",
	"aud": "a7AfcPcsl2",		"aud": "a7AfcPcsl2",
	"exp": 1311281970,		"exp": 1311281970,
	"acr": "psd2_sca",		"acr": "psd2_sca",
	skipping to change at page 24, line 40 ¶		skipping to change at line 1005 ¶
	},		},
	"remittanceInformationUnstructured": "Ref Number Merchant"		"remittanceInformationUnstructured": "Ref Number Merchant"
	}		}
	],		],
	"debtorAccount": {		"debtorAccount": {
	"iban": "DE40100100103307118608",		"iban": "DE40100100103307118608",
	"user_role": "owner"		"user_role": "owner"
	}		}
	}		}
	Figure 20: Example for authorization_details in JWT-based access		Figure 20: Example of "authorization_details" in JWT-Based Access
	token.		Token
	In this case, the AS added the following example claims to the JWT-		In this case, the AS added the following example claims to the JWT-
	based access token:		based access token:
	* sub: conveys the user on which behalf the client is asking for		sub: indicates the user for which the client is asking for payment
	payment initiation		initiation.
	* 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
	* debtorAccount: API-specific field containing the debtor account.
	In the example, this account was not passed in the		debtorAccount: API-specific field containing the debtor account. In
	authorization_details but selected by the user during the		the example, this account was not passed in the
			authorization_details but was 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 particular account. In this case,		user has with respect to this particular account. In this case,
	they are the owner. This data is used for access control at the		they are the owner. This data is used for access control at the
	payment API (the RS).		payment API (the RS).
	9.2. Token Introspection		9.2. Token Introspection
	Token introspection [RFC7662] provides a means for an RS to query the		Token introspection [RFC7662] provides a means for an RS to query the
	AS to determine information about an access token. If the AS		AS to determine information about an access token. If the AS
	includes authorization detail information for the token in its		includes authorization detail information for the token in its
	skipping to change at page 26, line 40 ¶		skipping to change at line 1074 ¶
	},		},
	"remittanceInformationUnstructured": "Ref Number Merchant"		"remittanceInformationUnstructured": "Ref Number Merchant"
	}		}
	],		],
	"debtorAccount": {		"debtorAccount": {
	"iban": "DE40100100103307118608",		"iban": "DE40100100103307118608",
	"user_role": "owner"		"user_role": "owner"
	}		}
	}		}
	Figure 21: Example for authorization_details in introspection		Figure 21: Example of "authorization_details" in Introspection
	response.		Response
	10. Metadata		10. Metadata
	To advertise its support for this feature, the supported list of		To advertise its support for this feature, the supported list of
	authorization details types is included in the AS metadata response		authorization details types is included in the AS metadata response
	[RFC8414] using the metadata parameter		[RFC8414] using the metadata parameter
	authorization_details_types_supported, which is a JSON array.		authorization_details_types_supported, which is a JSON array.
	This is illustrated by the following example:		This is illustrated by the following example:
	{		{
	...		...
	"authorization_details_types_supported":[		"authorization_details_types_supported":[
	"payment_initiation",		"payment_initiation",
	"account_information"		"account_information"
	]		]
	}		}
	Figure 22: Example for server metadata about the supported		Figure 22: Example of Server Metadata about the Supported
	authorization details.		Authorization Details
	Clients MAY indicate the authorization details types they will use		Clients MAY indicate the authorization details types they will use
	when requesting authorization with the client registration metadata		when requesting authorization with the client registration metadata
	parameter authorization_details_types, which is a JSON array.		parameter authorization_details_types, which is a JSON array.
	This is illustrated by the following example:		This is illustrated by the following example:
	{		{
	...		...
	"authorization_details_types":[		"authorization_details_types":[
	"payment_initiation"		"payment_initiation"
	]		]
	}		}
	Figure 23: Example for server metadata about authorization details.		Figure 23: Example of Server Metadata about Authorization Details
	The registration of authorization details types with the AS is out of		The registration of authorization details types with the AS is
	scope of this specification.		outside the scope of this specification.
	11. Implementation Considerations		11. Implementation Considerations
	11.1. Using authorization details in a certain deployment		11.1. Using Authorization Details in a Certain Deployment
	Using authorization details in a certain deployment will require the		Using authorization details in a certain deployment will require the
	following steps:		following steps:
	* Define authorization details types		* Define authorization details types.
	* Publish authorization details types in the OAuth server metadata
			* Publish authorization details types in the OAuth server metadata.
	* Determine how authorization details are shown to the user in the		* Determine how authorization details are shown to the user in the
	user consent prompt		user consent prompt.
	* (if needed) Enrich authorization details in the user consent
	process (e.g. add selected accounts or set expirations)
	* (if needed) Determine how authorization details are reflected in
	access token content or introspection responses
	* Determine how the resource server(s) process(s) the authorization
	details or token data derived from authorization details
	* (if needed) Entitle clients to use certain authorization details
	types
	11.2. Minimal implementation support		* If needed, enrich authorization details in the user consent
			process (e.g., add selected accounts or set expirations).
	General authorization server implementations supporting this		* If needed, determine how authorization details are reflected in
	specification should provide the following basic functions:		access token content or introspection responses.
			* Determine how the RSs process the authorization details or token
			data derived from authorization details.
			* If needed, entitle clients to use certain authorization details
			types.
			11.2. Minimal Implementation Support
			General AS implementations supporting this specification should
			provide the following basic functions:
	* Support advertisement of supported authorization details types in		* Support advertisement of supported authorization details types in
	OAuth server metadata		OAuth server metadata
	* Accept authorization_details parameter in authorization requests
	in conformance with this specification		* Accept the authorization_details parameter in authorization
			requests in conformance with this specification
	* Support storage of consented authorization details as part of a		* Support storage of consented authorization details as part of a
	grant		grant
	* Implement default behavior for adding authorization details to		* Implement default behavior for adding authorization details to
	access tokens and token introspection responses in order to make		access tokens and token introspection responses in order to make
	them available to resource servers (similar to scope values).		them available to RSs (similar to scope values). This should work
	This should work with any grant type, especially		with any grant type, especially authorization_code and
	authorization_code and refresh_token.		refresh_token.
	Processing and presentation of authorization details will vary		Processing and presentation of authorization details will vary
	significantly among different authorization details types.		significantly among different authorization details types.
	Implementations should therefore support customization of the		Implementations should therefore support customization of the
	respective behavior. In particular, implementations should:		respective behavior. In particular, implementations should allow
			deployments to:
	* allow deployments to determine presentation of the authorization		* determine presentation of the authorization details;
	details
	* allow deployments to modify requested authorization details in the		* modify requested authorization details in the user consent
	user consent process, e.g. adding fields		process, e.g., adding fields; and
	* allow deployments to merge requested and pre-existing
	authorization details		* merge requested and preexisting authorization details.
	One approach to supporting such customization would be to have a		One approach to supporting such customization would be to have a
	mechanism allowing the registration of extension modules, each of		mechanism allowing the registration of extension modules, each of
	them responsible for rendering the respective user consent and any		them responsible for rendering the respective user consent and any
	transformation needed to provide the data needed to the resource		transformation needed to provide the data needed to the RS by way of
	server by way of structured access tokens or token introspection		structured access tokens or token introspection responses.
	responses.
	11.3. Use of Machine-readable Type Schemas		11.3. Use of Machine-Readable Type Schemas
	Implementations might allow deployments to use machine-readable		Implementations might allow deployments to use machine-readable
	schema languages for defining authorization details types to		schema languages for defining authorization details types to
	facilitate creating and validating authorization details objects		facilitate creating and validating authorization details objects
	against such schemas. For example, if an authorization details type		against such schemas. For example, if an authorization details type
	were defined using JSON Schemas [JSON.Schema], the JSON Schema		were defined using JSON Schemas [JSON.Schema], the JSON Schema
	identifier could be used as type value in the respective		identifier could be used as type value in the respective
	authorization details objects.		authorization details objects.
	Note however that type values are identifiers understood by the AS		Note, however, that type values are identifiers understood by the AS
	and, to the extent necessary, the client and RS. This specification		and, to the extent necessary, the client and RS. This specification
	makes no assumption that a type value point to a machine-readable		makes no assumption that a type value would point to a machine-
	schema format, or that any party in the system (such as the client,		readable schema format or that any party in the system (such as the
	AS, or RS) dereference or process the contents of the type field in		client, AS, or RS) would dereference or process the contents of the
	any specific way.		type field in any specific way.
	11.4. Large requests		11.4. Large Requests
	Authorization request URIs containing authorization_details in a		Authorization request URIs containing authorization_details in a
	request parameter or a request object can become very long.		request parameter or a request object can become very long.
	Implementers should therefore consider using the request_uri		Therefore, implementers should consider using the request_uri
	parameter as defined in [RFC9101] in combination with the pushed		parameter as defined in [RFC9101] in combination with the pushed
	request object mechanism as defined in [RFC9126] to pass		request object mechanism as defined in [RFC9126] to pass
	authorization_details in a reliable and secure manner. Here is an		authorization_details in a reliable and secure manner. Here is an
	example of such a pushed authorization request that sends the		example of such a pushed authorization request that sends the
	authorization request data directly to the AS via an HTTPS-protected		authorization request data directly to the AS via an HTTPS-protected
	connection:		connection:
	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
	skipping to change at page 29, line 47 ¶		skipping to change at line 1232 ¶
	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
	0Number%20Merchant%22%7D%5D		0Number%20Merchant%22%7D%5D
	Figure 24: Example for large request including authorization_details.		Figure 24: Example of Large Request including "authorization_details"
	12. Security Considerations		12. Security Considerations
	The authorization_details parameter is sent through the user agent in		The authorization_details parameter is sent through the user agent in
	case of an OAuth authorization request, which makes them vulnerable		case of an OAuth authorization request, which makes them vulnerable
	to modifications by the user. If integrity of the		to modifications by the user. If the integrity of the
	authorization_details is a concern, clients MUST protect		authorization_details is a concern, clients MUST protect
	authorization_details against tampering and swapping. This can be		authorization_details against tampering and swapping. This can be
	achieved by signing the request using signed request objects as		achieved by signing the request using signed request objects as
	defined in [RFC9101] or using the request_uri authorization request		defined in [RFC9101] or using the request_uri authorization request
	parameter as defined in [RFC9101] in conjunction with [RFC9126] to		parameter as defined in [RFC9101] in conjunction with [RFC9126] to
	pass the URI of the request object to the authorization server.		pass the URI of the request object to the AS.
	All string comparisons in an authorization_details parameter are to		All string comparisons in an authorization_details parameter are to
	be done as defined by [RFC8259]. No additional transformation or		be done as defined by [RFC8259]. No additional transformation or
	normalization is to be done in evaluating equivalence of string		normalization is to be done in evaluating equivalence of string
	values.		values.
	The common data field locations allows a client to specify where it		The common data field locations allows a client to specify where it
	intends to use a certain authorization, i.e., it is possible to		intends to use a certain authorization, i.e., it is possible to
	unambiguously assign permissions to resource servers. In situations		unambiguously assign permissions to RSs. In situations with multiple
	with multiple resource servers, this prevents unintended client		RSs, this prevents unintended client authorizations (e.g., a read
	authorizations (e.g. a read scope value potentially applicable for an		scope value potentially applicable for an email as well as a cloud
	email as well as a cloud service) through audience restriction.		service) through audience restriction.
	The AS MUST properly sanitized and handle the data passed in the		The AS MUST properly sanitize and handle the data passed in the
	authorization_details in order to prevent injection attacks.		authorization_details in order to prevent injection attacks.
	The Security Considerations of [RFC6749], [RFC7662], and [RFC8414]		The Security Considerations of [RFC6749], [RFC7662], and [RFC8414]
	also apply.		also apply.
	13. Privacy Considerations		13. Privacy Considerations
	It is especially important for implementers to design and use		It is especially important for implementers to design and use
	authorization details in a privacy-preserving manner.		authorization details in a privacy-preserving manner.
	Any sensitive personal data included in authorization_details must be		Any sensitive personal data included in authorization_details must be
	prevented from leaking, e.g., through referrer headers.		prevented from leaking, e.g., through referrer headers.
	Implementation options include encrypted request objects as defined		Implementation options include encrypted request objects as defined
	in [RFC9101] or transmission of authorization_details via end-to-end		in [RFC9101] or transmission of authorization_details via end-to-end
	encrypted connections between client and authorization server by		encrypted connections between client and AS by utilizing [RFC9126]
	utilizing [RFC9126] and the request_uri authorization request		and the request_uri authorization request parameter as defined in
	parameter as defined in [RFC9101]. The latter does not require		[RFC9101]. The latter does not require application-level encryption,
	application level encryption but it requires another message exchange		but it requires another message exchange between the client and the
	between client and AS.		AS.
	Even if the request data is encrypted, an attacker could use the		Even if the request data is encrypted, an attacker could use the AS
	authorization server to learn the user's data by injecting the		to learn the user's data by injecting the encrypted request data into
	encrypted request data into an authorization request on a device		an authorization request on a device under their control and use the
	under their control and use the authorization server's user consent		AS's user consent screens to show the (decrypted) user data in the
	screens to show the (decrypted) user data in the clear.		clear. Implementations need to consider this attack vector and
	Implementations need to consider this attack vector and implement		implement appropriate countermeasures, e.g., by only showing portions
	appropriate countermeasures, e.g. by only showing portions of the		of the data or, if possible, determining whether the assumed user
	data or, if possible, determining whether the assumed user context is		context is still the same (after user authentication).
	still the same (after user authentication).
	The AS needs to take into consideration the privacy implications when		The AS needs to take into consideration the privacy implications when
	sharing authorization_details with the client or resource servers.		sharing authorization_details with the client or RSs. The AS should
	The AS should share this data with those parties on a "need to know"		share this data with those parties on a "need to know" basis as
	basis as determined by local policy.		determined by local policy.
	14. Acknowledgements
	We would like to thank Daniel Fett, Sebastian Ebling, Dave Tonge,
	Mike Jones, Nat Sakimura, and Rob Otto for their valuable feedback
	during the preparation of this specification.
	We would also like to thank Vladimir Dzhuvinov, Takahiko Kawasaki,
	Daniel Fett, Dave Tonge, Travis Spencer, Joergen Binningsboe, Aamund
	Bremer, Steinar Noem, Francis Pouatcha, Jacob Ideskog, Hannes
	Tschofenig, and Aaron Parecki for their valuable feedback to this
	specification.
	15. IANA Considerations		14. IANA Considerations
	15.1. OAuth Parameters Registration		14.1. OAuth Parameters Registration
	This specification requests registration of the following parameter		The following parameter has been registered in the "OAuth Parameters"
	in the "OAuth Parameters" registry [IANA.OAuth.Parameters]		registry [IANA.OAuth.Parameters] established by [RFC6749].
	established by [RFC6749].
	Name: authorization_details		Name: authorization_details
	Parameter Usage Location: authorization request, token request,		Parameter Usage Location: authorization request, token request,
	token response		token response
	Change Controller: IETF		Change Controller: IETF
	Specification Document(s): [[ this document ]]
	15.2. JSON Web Token Claims Registration		Reference: RFC 9396
	This specification requests registration of the following value in		14.2. JSON Web Token Claims Registration
	the IANA "JSON Web Token Claims" registry established by [RFC7519].
			The following value has been registered in the IANA "JSON Web Token
			Claims" registry established by [RFC7519].
	Claim Name: authorization_details		Claim Name: authorization_details
	Claim Description: The claim authorization_details contains a JSON		Claim Description: The claim authorization_details contains a JSON
	array of JSON objects representing the rights of the access token.		array of JSON objects representing the rights of the access token.
	Each JSON object contains the data to specify the authorization		Each JSON object contains the data to specify the authorization
	requirements for a certain type of resource.		requirements for a certain type of resource.
	Change Controller: IETF		Change Controller: IETF
	Specification Document(s): Section 9.1 of [[ this document ]]
	15.3. OAuth Token Introspection Response Registration		Reference: Section 9.1 of RFC 9396
	This specification requests registration of the following value in		14.3. OAuth Token Introspection Response Registration
	the IANA "OAuth Token Introspection Response" registry established by
	[RFC7662].		The following value has been registered in the IANA "OAuth Token
			Introspection Response" registry established by [RFC7662].
	Name: authorization_details		Name: authorization_details
	Description: The member authorization_details contains a JSON array		Description: The member authorization_details contains a JSON array
	of JSON objects representing the rights of the access token. Each		of JSON objects representing the rights of the access token. Each
	JSON object contains the data to specify the authorization		JSON object contains the data to specify the authorization
	requirements for a certain type of resource.		requirements for a certain type of resource.
	Change Controller: IETF		Change Controller: IETF
	Specification Document(s): Section 9.2 of [[ this document ]]
	15.4. OAuth Authorization Server Metadata Registration		Reference: Section 9.2 of RFC 9396
	This specification requests registration of the following values in		14.4. OAuth Authorization Server Metadata Registration
	the IANA "OAuth Authorization Server Metadata" registry of
	[IANA.OAuth.Parameters] established by [RFC8414].		The following values have been registered in the IANA "OAuth
			Authorization Server Metadata" registry of [IANA.OAuth.Parameters]
			established by [RFC8414].
	Metadata Name: authorization_details_types_supported		Metadata Name: authorization_details_types_supported
	Metadata Description: JSON array containing the authorization		Metadata Description: JSON array containing the authorization
	details types the AS supports		details types the AS supports
	Change Controller: IETF		Change Controller: IETF
	Specification Document(s): Section 10 of [[ this document ]]
	15.5. OAuth Dynamic Client Registration Metadata Registration		Reference: Section 10 of RFC 9396
	This specification requests registration of the following value in		14.5. OAuth Dynamic Client Registration Metadata Registration
	the IANA "OAuth Dynamic Client Registration Metadata" registry of
	[IANA.OAuth.Parameters] established by [RFC7591].		The following value has been registered in the IANA "OAuth Dynamic
			Client Registration Metadata" registry of [IANA.OAuth.Parameters]
			established by [RFC7591].
			Client Metadata Name: authorization_details_types
			Client Metadata Description: Indicates what authorization details
			types the client uses.
	Metadata Name: authorization_details_types
	Metadata Description: Indicates what authorization details types the
	client uses.
	Change Controller: IETF		Change Controller: IETF
	Specification Document(s): Section 10 of [[ this document ]]
	15.6. OAuth Extensions Error Registration		Reference: Section 10 of RFC 9396
	This specification requests registration of the following value in		14.6. OAuth Extensions Error Registration
	the IANA "OAuth Extensions Error" registry of [IANA.OAuth.Parameters]
	established by [RFC6749].		The following value has been registered in the IANA "OAuth Extensions
			Error Registry" of [IANA.OAuth.Parameters] established by [RFC6749].
			Name: invalid_authorization_details
			Usage Location: token endpoint, authorization endpoint
			Protocol Extension: OAuth 2.0 Rich Authorization Requests
	Error name: invalid_authorization_details
	Error usage location: token endpoint, authorization endpoint
	Related protocol extension: OAuth 2.0 Rich Authorization Requests
	Change Controller: IETF		Change Controller: IETF
	Reference: Section 5 of [[ this document ]]
	16. Normative References		Reference: Section 5 of RFC 9396
			15. References
			15.1. 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>.
	[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 33, line 42 ¶		skipping to change at line 1421 ¶
	[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>.
	[RFC8707] Campbell, B., Bradley, J., and H. Tschofenig, "Resource		[RFC8707] Campbell, B., Bradley, J., and H. Tschofenig, "Resource
	Indicators for OAuth 2.0", RFC 8707, DOI 10.17487/RFC8707,		Indicators for OAuth 2.0", RFC 8707, DOI 10.17487/RFC8707,
	February 2020, <https://www.rfc-editor.org/info/rfc8707>.		February 2020, <https://www.rfc-editor.org/info/rfc8707>.
	17. Informative References		15.2. Informative References
	[CSC] Consortium, C. S., "Architectures and protocols for remote		[CSC] Cloud Signature Consortium, "Architectures and protocols
	signature applications", 1 June 2019,		for remote signature applications", Version 1.0.4.0, June
	<https://cloudsignatureconsortium.org/wp-		2019, <https://cloudsignatureconsortium.org/wp-
	content/uploads/2019/07/CSC_API_V1_1.0.4.0.pdf>.		content/uploads/2020/01/CSC_API_V1_1.0.4.0.pdf>.
	[ETSI] ETSI, "ETSI TS 119 432, Electronic Signatures and		[ETSI] ETSI, "Electronic Signatures and Infrastructures (ESI);
	Infrastructures (ESI); Protocols for remote digital		Protocols for remote digital signature creation", V1.1.1,
	signature creation", 20 March 2019,		ETSI TS 119 432, March 2019,
	<https://www.etsi.org/deliver/		<https://www.etsi.org/deliver/
	etsi_ts/119400_119499/119432/01.01.01_60/		etsi_ts/119400_119499/119432/01.01.01_60/
	ts_119432v010101p.pdf>.		ts_119432v010101p.pdf>.
	[IANA.OAuth.Parameters]		[IANA.OAuth.Parameters]
	IANA, "OAuth Parameters",		IANA, "OAuth Parameters",
	<https://www.iana.org/assignments/oauth-parameters>.		<https://www.iana.org/assignments/oauth-parameters>.
	[JSON.Schema]		[JSON.Schema]
	json-schema.org, "JSON Schema",		OpenJS Foundation, "JSON Schema",
	<https://json-schema.org/>.		<https://json-schema.org/>.
			[OID-CIBA] Fernandez, G., Walter, F., Nennker, A., Tonge, D., and B.
			Campbell, "OpenID Connect Client-Initiated Backchannel
			Authentication Flow - Core 1.0", 1 September 2021,
			<https://openid.net/specs/openid-client-initiated-
			backchannel-authentication-core-1_0.html>.
	[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", 8 November 2014,		errata set 1", 8 November 2014,
	<https://openid.net/specs/openid-connect-core-1_0.html>.		<https://openid.net/specs/openid-connect-core-1_0.html>.
	[OpenID.CIBA]
	Fernandez, G., Walter, F., Nennker, A., Tonge, D., and B.
	Campbell, "OpenID Connect Client Initiated Backchannel
	Authentication Flow - Core 1.0", 16 January 2019,
	<https://openid.net/specs/openid-client-initiated-
	backchannel-authentication-core-1_0.html>.
	[RFC0020] Cerf, V., "ASCII format for network interchange", STD 80,		[RFC0020] Cerf, V., "ASCII format for network interchange", STD 80,
	RFC 20, DOI 10.17487/RFC0020, October 1969,		RFC 20, DOI 10.17487/RFC0020, October 1969,
	<https://www.rfc-editor.org/info/rfc20>.		<https://www.rfc-editor.org/info/rfc20>.
	[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",		[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
	RFC 6749, DOI 10.17487/RFC6749, October 2012,		RFC 6749, DOI 10.17487/RFC6749, October 2012,
	<https://www.rfc-editor.org/info/rfc6749>.		<https://www.rfc-editor.org/info/rfc6749>.
	[RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and		[RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and
	P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",		P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",
	skipping to change at page 35, line 10 ¶		skipping to change at line 1482 ¶
	[RFC9101] Sakimura, N., Bradley, J., and M. Jones, "The OAuth 2.0		[RFC9101] Sakimura, N., Bradley, J., and M. Jones, "The OAuth 2.0
	Authorization Framework: JWT-Secured Authorization Request		Authorization Framework: JWT-Secured Authorization Request
	(JAR)", RFC 9101, DOI 10.17487/RFC9101, August 2021,		(JAR)", RFC 9101, DOI 10.17487/RFC9101, August 2021,
	<https://www.rfc-editor.org/info/rfc9101>.		<https://www.rfc-editor.org/info/rfc9101>.
	[RFC9126] Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D.,		[RFC9126] Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D.,
	and F. Skokan, "OAuth 2.0 Pushed Authorization Requests",		and F. Skokan, "OAuth 2.0 Pushed Authorization Requests",
	RFC 9126, DOI 10.17487/RFC9126, September 2021,		RFC 9126, DOI 10.17487/RFC9126, September 2021,
	<https://www.rfc-editor.org/info/rfc9126>.		<https://www.rfc-editor.org/info/rfc9126>.
	[transaction-authorization]		[Transaction-Auth]
	Lodderstedt, T., "Transaction Authorization or why we need		Lodderstedt, T., "Transaction Authorization or why we need
	to re-think OAuth scopes", 20 April 2019,		to re-think OAuth scopes", 20 April 2019,
	<https://medium.com/oauth-2/transaction-authorization-or-		<https://medium.com/oauth-2/transaction-authorization-or-
	why-we-need-to-re-think-oauth-scopes-2326e2038948>.		why-we-need-to-re-think-oauth-scopes-2326e2038948>.
	Appendix A. Additional Examples		Appendix A. Additional Examples
	A.1. OpenID Connect		A.1. OpenID Connect
	OpenID Connect [OIDC] specifies the JSON-based claims request		OpenID Connect [OIDC] specifies the JSON-based claims request
	parameter that can be used to specify the claims a client (acting as		parameter that can be used to specify the claims a client (acting as
	OpenID Connect Relying Party) wishes to receive in a fine-grained and		an OpenID Connect Relying Party) wishes to receive in a fine-grained
	privacy-preserving way as well as assign those claims to certain		and privacy-preserving way as well as assign those claims to certain
	delivery mechanisms, i.e. ID Token or userinfo response.		delivery mechanisms, i.e., ID Token or userinfo response.
	The combination of the scope value openid and the additional		The combination of the scope value openid and the additional
	parameter claims can be used beside authorization_details in the same		parameter claims can be used beside authorization_details in the same
	way as every non-OIDC scope value.		way as every non-OIDC scope value.
	Alternatively, there could be an authorization details type for		Alternatively, there could be an authorization details type for
	OpenID Connect. This section gives an example of what such an		OpenID Connect. This section gives an example of what such an
	authorization details type could look like, but defining this		authorization details type could look like, but defining this
	authorization details type is outside the scope of this		authorization details type is outside the scope of this
	specification.		specification.
	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 field are based on the definitions given in [OIDC]:		The top-level fields are based on the definitions given in [OIDC]:
	* claim_sets: names of predefined claim sets, replacement for		claim_sets: the names of predefined claim sets, replacement for
	respective scope values, such as profile		respective scope values, such as profile
	* max_age: Maximum Authentication Age
	* acr_values: requested Authentication Context Class Reference (ACR)		max_age: Maximum Authentication Age
	values.
	* claims: the claims JSON structure as defined in [OIDC]		acr_values: requested Authentication Context Class Reference (ACR)
			values
			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": [
	"email",		"email",
	"profile"		"profile"
	]		]
	}		}
	]		]
	Figure 25: Example for OpenID Connect request utilizing		Figure 25: Example of OpenID Connect Request Utilizing
	authorization_details.		"authorization_details"
	Note: locations specifies the location of the userinfo endpoint since		| Note: locations specifies the location of the userinfo endpoint
	this is the only place where an access token is used by a client (RP)		| since this is the only place where an access token is used by a
	in OpenID Connect to obtain claims.		| client (Relying Party) in OpenID Connect to obtain claims.
	A more sophisticated example is shown in the following		A more sophisticated example is shown in Figure 26.
	[		[
	{		{
	"type": "openid",		"type": "openid",
	"locations": [		"locations": [
	"https://op.example.com/userinfo"		"https://op.example.com/userinfo"
	],		],
	"max_age": 86400,		"max_age": 86400,
	"acr_values": "urn:mace:incommon:iap:silver",		"acr_values": "urn:mace:incommon:iap:silver",
	"claims": {		"claims": {
	skipping to change at page 37, line 37 ¶		skipping to change at line 1580 ¶
	},		},
	"id_token": {		"id_token": {
	"auth_time": {		"auth_time": {
	"essential": true		"essential": true
	}		}
	}		}
	}		}
	}		}
	]		]
	Figure 26: Advanced example for OpenID Connect request utilizing		Figure 26: Advanced Example of OpenID Connect Request Utilizing
	authorization_details.		"authorization_details"
	A.2. Remote Electronic Signing		A.2. Remote Electronic Signing
	The following example is based on the concept laid out for remote		The following example is based on the concept laid out for remote
	electronic signing in ETSI TS 119 432 [ETSI] and the CSC API for		electronic signing in ETSI TS 119 432 [ETSI] and the Cloud Signature
	remote signature creation [CSC].		Consortium (CSC) API for remote signature creation [CSC].
	[		[
	{		{
	"type": "sign",		"type": "sign",
	"locations": [		"locations": [
	"https://signing.example.com/signdoc"		"https://signing.example.com/signdoc"
	],		],
	"credentialID": "60916d31-932e-4820-ba82-1fcead1c9ea3",		"credentialID": "60916d31-932e-4820-ba82-1fcead1c9ea3",
	"documentDigests": [		"documentDigests": [
	{		{
	skipping to change at page 38, line 26 ¶		skipping to change at line 1610 ¶
	},		},
	{		{
	"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"
	}		}
	]		]
	Figure 27: Example for electronic signing.		Figure 27: Example of Electronic Signing
	The top-level fields have the following meaning:		The top-level fields have the following meaning:
	* credentialID: identifier of the certificate to be used for signing		credentialID: identifier of the certificate to be used for signing
	* documentDigests: array containing the hash of every document to be
			documentDigests: array containing the hash of every document to be
	signed (hash fields). Additionally, the corresponding label field		signed (hash fields). Additionally, the corresponding label field
	identifies the respective document to the user, e.g. to be used in		identifies the respective document to the user, e.g., to be used
	user consent.		in user consent.
	* hashAlgorithm: algorithm that was used to calculate the hash
	values.		hashAlgorithm: algorithm that was used to calculate the hash 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
	signatures for the documents listed in the structure. The client		signatures for the documents listed in the structure. The client
	uses the access token issued as a result of the process to call the		uses the access token issued as a result of the process to call the
	sign doc endpoint at the respective signing service to actually		document signature API at the respective signing service to actually
	create the signature. This access token is bound to the client, the		create the signature. This access token is bound to the client, the
	user id and the hashes (and signature algorithm) as consented by the		user ID and the hashes (and signature algorithm) as consented by the
	user.		user.
	A.3. Access to Tax Data		A.3. Access to Tax Data
	This example is inspired by an API allowing third parties to access		This example is inspired by an API allowing third parties to access
	citizen's tax declarations and income statements, for example, to		citizen's tax declarations and income statements, for example, to
	determine their creditworthiness.		determine their creditworthiness.
	[		[
	{		{
	skipping to change at page 39, line 18 ¶		skipping to change at line 1650 ¶
	"locations": [		"locations": [
	"https://taxservice.govehub.no.example.com"		"https://taxservice.govehub.no.example.com"
	],		],
	"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"
	}		}
	]		]
	Figure 28: Example for tax data access.		Figure 28: Example of Tax Data Access
	The top-level fields have the following meaning:		The top-level fields have the following meaning:
	* periods: determines the periods the client wants to access		periods: the periods the client wants to access
	* duration_of_access: how long does the client intend to access the
	data in days		duration_of_access: how long the clients intend to access the data
	* tax_payer_id: identifier of the taxpayer (if known to the client)		in days
			tax_payer_id: identifier of the taxpayer (if known to the client)
	A.4. eHealth		A.4. eHealth
	These two examples are inspired by requirements for APIs used in the		These two examples are inspired by requirements for APIs used in the
	Norwegian eHealth system.		Norwegian eHealth system.
	In this use case, the physical therapist sits in front of their		In this use case, the physical therapist sits in front of their
	computer using a local Electronic Health Records (EHR) system. They		computer using a local Electronic Health Records (EHR) system. They
	want to look at the electronic patient records of a certain patient		want to look at the electronic patient records of a certain patient,
	and they also want to fetch the patients journal entries in another		and they also want to fetch the patient's journal entries in another
	system, perhaps at another institution or a national service. Access		system, perhaps at another institution or a national service. Access
	to this data is provided by an API.		to this data is provided by an API.
	The information necessary to authorize the request at the API is only		The information necessary to authorize the request at the API is only
	known by the EHR system, and must be presented to the API.		known by the EHR system and must be presented to the API.
	In the first example, the authorization details object contains the		In the first example, the authorization details object contains the
	identifier of an organization. In this case, the API needs to know		identifier of an organization. In this case, the API needs to know
	if the given organization has the lawful basis for processing		if the given organization has the lawful basis for processing
	personal health information to give access to sensitive data.		personal health information to give access to sensitive data.
	"authorization_details": {		"authorization_details": {
	"type": "patient_record",		"type": "patient_record",
	"requesting_entity": {		"requesting_entity": {
	"type": "Practitioner",		"type": "Practitioner",
	skipping to change at page 40, line 26 ¶		skipping to change at line 1702 ¶
	"identifier": {		"identifier": {
	"system": "urn:oid:2.16.578.1.12.4.1.2.101",		"system": "urn:oid:2.16.578.1.12.4.1.2.101",
	"type": "ENH",		"type": "ENH",
	"value": "[organizational number]"		"value": "[organizational number]"
	}		}
	}		}
	}		}
	}		}
	}		}
	Figure 29: eHealth Example.		Figure 29: eHealth Example
	In the second example, the API requires more information to authorize		In the second example, the API requires more information to authorize
	the request. In this case, the authorization details object contains		the request. In this case, the authorization details object contains
	additional information about the health institution and the current		additional information about the health institution and the current
	profession the user has at the time of the request. The additional		profession the user has at the time of the request. The additional
	level of detail could be used for both authorization and data		level of detail could be used for both authorization and data
	minimization.		minimization.
	[		[
	{		{
	skipping to change at page 41, line 43 ¶		skipping to change at line 1768 ¶
	"code": "36682004",		"code": "36682004",
	"display": "Physical therapist"		"display": "Physical therapist"
	}		}
	]		]
	}		}
	}		}
	}		}
	}		}
	]		]
	Figure 30: Advanced eHealth example.		Figure 30: Advanced eHealth Example
	Description of the fields:		Description of the fields:
	* 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 actual value		system identifier in OID format (namespace) and the actual value
	within this namespace.		within this namespace.
	* reason_for_request: the reason why the user wants to access a
	certain API
	* requesting_entity: specification of the requester by means of		reason_for_request: the reason why the user wants to access a
			certain API.
			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		Acknowledgements
	[[ To be removed from the final specification ]]
	-22
	* Add clarifying language around the geolocation example and
	Section 6.1 per Paul Wouters' ballot comment
	-21
	* incorporated feedback from Robert Wilton and É (U+00C9)ric Vyncke
	-20
	* incorporated feedback from Murray Kucherawy
	-19
	* incorporated feedback from Lars Eggert
	-18
	* IANA Considerations cleanup
	-17
	* incorporated feedback from Genart review
	-16
	* incorporated feedback from Sec Dir review
	-15
	* Editorial updates from Roman Danyliw's AD review
	* Other editorial updates
	-14
	* Added clarification regarding authorization details types matching
	* Removed duplicate text on use of "scope" and "resource" parameters
	alongside "authorization_details"
	* Replaced duplicate error response description in Section 8 with
	reference to Section 5
	-13
	* Editorial updates from Roman Danyliw's AD review
	* Removed normative language from field definitions.
	-12
	* Clarify introspection response.
	* Editorial updates
	-11
	* Updated IANA registrations adding authorization_details parameter
	-10
	* Updated IANA registrations
	-09
	* Incorporated feedback by Hannes as document shepherd
	-08
	* formatting in authorization details type section
	* added example for privileges common data element
	-07
	* incorporated review feedback from WGLC
	* fixed wording in token introspection section
	* added privacy considerations re authorization details in token
	response
	-06
	* removed use of resource indicators to filter authorization details
	in token response
	-05
	* added authorization_details token request parameter and discussion
	on authorization details comparison
	* added privileges field to authorization details (to align with
	GNAP)
	* added IANA text and changed metadata parameter names
	* added text about use of machine-readable type schemas, e.g. JSON
	Schema
	* added text on how authorization details are determined for access
	token issued with token response
	* added token error response and further error conditions to
	authorization error response
	-04
	* restructured draft for better readability
	* simplified normative text about use of the resource parameter with
	authorization_details
	* added implementation considerations for deployments and products
	* added type union language from GNAP
	* added recommendation to use PAR to cope with large requests and
	for request protection
	-03
	* Updated references to current revisions or RFC numbers
	* Added section about enrichment of authorization details objects by
	the AS
	* Clarified processing of unknown authorization details parameters
	* clarified dependencies between resource and authorization_details
	parameters
	-02
	* Clarify "type" parameter processing
	-01
	* Minor fix-up in a few examples
	-00 (WG draft)
	* initial WG revision
	-03
	* Reworked examples to illustrate privacy preserving use of
	authorization_details
	* Added text on audience restriction
	* Added description of relationship between scope and
	authorization_details
	* Added text on token request & response and authorization_details
	* Added text on how authorization details are conveyed to RSs by
	JWTs or token introspection endpoint response
	* Added description of relationship between claims and
	authorization_details
	* Added more example from different sectors
	* Clarified string comparison to be byte-exact without collation
	-02
	* Added Security Considerations
	* Added Privacy Considerations
	* 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
	* changed authorization_details structure from object to array
	* added Justin Richer & Brian Campbell as Co-Authors
	-00 / -01		We would like to thank Daniel Fett, Sebastian Ebling, Dave Tonge,
			Mike Jones, Nat Sakimura, and Rob Otto for their valuable feedback
			during the preparation of this specification.
	* first draft		We would also like to thank Vladimir Dzhuvinov, Takahiko Kawasaki,
			Daniel Fett, Dave Tonge, Travis Spencer, Joergen Binningsboe, Aamund
			Bremer, Steinar Noem, Francis Pouatcha, Jacob Ideskog, Hannes
			Tschofenig, and Aaron Parecki for their valuable feedback to this
			specification.
	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
	Email: ietf@justin.richer.org		Email: ietf@justin.richer.org
End of changes. 186 change blocks.
	596 lines changed or deleted		482 lines changed or added
This html diff was produced by rfcdiff 1.48.