rfc9396v1.txt		rfc9396.txt
	skipping to change at line 54 ¶		skipping to change at line 54 ¶
	in the Revised BSD License.		in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction		1. Introduction
	1.1. Conventions and Terminology		1.1. Conventions and Terminology
	2. Request Parameter "authorization_details"		2. Request Parameter "authorization_details"
	2.1. Authorization Details Types		2.1. Authorization Details Types
	2.2. Common Data Fields		2.2. Common Data Fields
	3. Authorization Request		3. Authorization Request
	3.1. Relationship to "scope" Parameter		3.1. Relationship to the "scope" Parameter
	3.2. Relationship to "resource" Parameter		3.2. Relationship to the "resource" Parameter
	4. Authorization Response		4. Authorization Response
	5. Authorization Error Response		5. Authorization Error Response
	6. Token Request		6. Token Request
	6.1. Comparing Authorization Details		6.1. Comparing Authorization Details
	7. Token Response		7. Token Response
	7.1. Enriched Authorization Details in Token Response		7.1. Enriched Authorization Details in Token Response
	8. Token Error Response		8. Token Error Response
	9. Resource Servers		9. Resource Servers
	9.1. JWT-Based Access Tokens		9.1. JWT-Based Access Tokens
	9.2. Token Introspection		9.2. Token Introspection
	10. Metadata		10. Metadata
	11. Implementation Considerations		11. Implementation Considerations
	11.1. Using authorization details in a Certain Deployment		11.1. Using Authorization Details in a Certain Deployment
	11.2. Minimal Implementation Support		11.2. Minimal Implementation Support
	11.3. Use of Machine-Readable Type Schemas		11.3. Use of Machine-Readable Type Schemas
	11.4. Large Requests		11.4. Large Requests
	12. Security Considerations		12. Security Considerations
	13. Privacy Considerations		13. Privacy Considerations
	14. IANA Considerations		14. IANA Considerations
	14.1. OAuth Parameters Registration		14.1. OAuth Parameters Registration
	14.2. JSON Web Token Claims Registration		14.2. JSON Web Token Claims Registration
	14.3. OAuth Token Introspection Response Registration		14.3. OAuth Token Introspection Response Registration
	14.4. OAuth Authorization Server Metadata Registration		14.4. OAuth Authorization Server Metadata Registration
	skipping to change at line 155 ¶		skipping to change at line 155 ¶
	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		"OPTIONAL" in this document are to be interpreted as described in
	BCP 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"		response", and "client" defined by "The OAuth 2.0 Authorization
	[RFC6749].		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.
	skipping to change at line 203 ¶		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 of authorization_details for a Credit Transfer		Figure 2: Example of "authorization_details" for a Credit Transfer
	Figure 3 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",
	skipping to change at line 242 ¶		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 of 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 line 297 ¶		skipping to change at line 297 ¶
	{		{
	"path": "/myfiles/A/X",		"path": "/myfiles/A/X",
	"access": [		"access": [
	"read",		"read",
	"write"		"write"
	]		]
	}		}
	]		]
	}		}
	Figure 4: Example of 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 of 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 line 391 ¶		skipping to change at line 391 ¶
	],		],
	"actions": [		"actions": [
	"write"		"write"
	],		],
	"datatypes": [		"datatypes": [
	"photos"		"photos"
	]		]
	}		}
	]		]
	Figure 6: Example of 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
	skipping to change at line 443 ¶		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 of 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
	skipping to change at line 494 ¶		skipping to change at line 494 ¶
	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%22remittanc		%22iban%22%3A%22DE02100100109307118603%22%7D%2C%22remittanc
	eInformationUnstructured%22%3A%22Ref%20Number%20Merchant%22		eInformationUnstructured%22%3A%22Ref%20Number%20Merchant%22
	%7D%5D HTTP/1.1		%7D%5D HTTP/1.1
	Host: server.example.com		Host: server.example.com
	Figure 8: Example of Authorization Request with authorization_details		Figure 8: Example of Authorization Request with
			"authorization_details"
	Based on the data provided in the authorization_details parameter,		Based on the data provided in the authorization_details parameter,
	the AS will ask the user for consent to the requested access		the AS will ask the user for consent to the requested access
	permissions.		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 Figure 9, the client wants to get access to account information		In Figure 9, the client wants to get access to account 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",
	skipping to change at line 540 ¶		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 line 565 ¶		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		The resource authorization request parameter, as defined in
	[RFC8707], can be used to further determine the resources where the		[RFC8707], can be used to further determine the resources where the
	requested scope can be applied. The resource parameter does not have		requested scope can be applied. The resource parameter does not have
	any 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
	skipping to change at line 605 ¶		skipping to change at line 606 ¶
	* is 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 that a client wants the AS to		specify the authorization details that a client wants the AS to
	assign to an access token. The AS checks whether the underlying		assign to an access token. The AS checks whether the underlying
	grant (in case of grant types authorization_code, refresh_token,		grant (in case of grant types authorization_code, refresh_token,
	etc.) or the client's policy (in case of grant type		etc.) or the client's policy (in case of grant type
	client_credential) allows the issuance of an access token with the		client_credentials) allows the issuance of an access token with the
	requested authorization details. Otherwise, the AS refuses the		requested authorization details. Otherwise, the AS refuses the
	request with the error code invalid_authorization_details (similar to		request with the error code invalid_authorization_details (similar to
	invalid_scope).		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,
	skipping to change at line 665 ¶		skipping to change at line 664 ¶
	"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 of 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		* verify whether the approved list of actions contains
	list_account, and		list_accounts, and
	* whether the locations value includes only previously approved		* verify whether the locations value includes only previously
	locations.		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, this 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 of 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 of 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 of the functions on the resources. If that		allowed to perform any of the functions on the resources. If that
	client is 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 of 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 that the privileges		The AS would compare the type value and find that the privileges
	value subsumes any aspects of read or write access that had been		value subsumes any aspects of read or write access that had been
	granted to the client previously. Note that other API definitions		granted to the client previously. Note that other API definitions
	can use 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_initiation 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 of 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, it would look like this:		For our running example, it would look like this:
	skipping to change at line 821 ¶		skipping to change at line 820 ¶
	]		]
	}		}
	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. During the course of the authorization process,		access to the user. During the course of the authorization process,
	the user would select the subset of their accounts that they want to		the user would select the subset of their accounts that they want to
	allow the client to access. As one design option to convey the		allow the client to access. As one design option to convey 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 of 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 line 898 ¶		skipping to change at line 896 ¶
	{		{
	"maskedPan":"123456xxxxxx1234"		"maskedPan":"123456xxxxxx1234"
	}		}
	]		]
	},		},
	"recurringIndicator":true		"recurringIndicator":true
	}		}
	]		]
	}		}
	Figure 17: Example of 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 of 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 line 938 ¶		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 of 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 JSON Web Token (JWT) format or to Token		to access tokens in JSON Web Token (JWT) format or to token
	Introspection responses.		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 that the RS		The AS will typically also add further claims to the JWT that the RS
	requires request processing, e.g., user id, roles, and transaction-		requires request processing, e.g., user ID, roles, and transaction-
	specific data. What claims the particular RS requires is defined by		specific data. What claims the particular RS requires is 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",
	skipping to change at line 1007 ¶		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 of authorization_details in JWT-Based Access Token		Figure 20: Example of "authorization_details" in JWT-Based Access
			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		debtorAccount: API-specific field containing the debtor account. In
	the example, this account was not passed in the		the example, this account was not passed in the
	authorization_details but was selected by the user during 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
	skipping to change at line 1075 ¶		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 of authorization_details in Introspection Response		Figure 21: Example of "authorization_details" in Introspection
			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 of 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 of Server Metadata about authorization details		Figure 23: Example of Server Metadata about Authorization Details
	The registration of authorization details types with the AS is		The registration of authorization details types with the AS is
	outside the 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		* If needed, enrich authorization details in the user consent
	process (e.g., add selected accounts or set expirations).		process (e.g., add selected accounts or set expirations).
	* If needed, determine how authorization details are reflected in		* If needed, determine how authorization details are reflected in
	access token content or introspection responses.		access token content or introspection responses.
	* Determine how the resource servers process the authorization		* Determine how the RSs process the authorization details or token
	details or token data derived from authorization details.		data derived from authorization details.
	* If needed, entitle clients to use certain authorization details		* If needed, entitle clients to use certain authorization details
	types.		types.
	11.2. Minimal Implementation Support		11.2. Minimal Implementation Support
	General authorization server implementations supporting this		General AS implementations supporting this specification should
	specification should provide the following basic functions:		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 the authorization_details parameter in authorization		* Accept the authorization_details parameter in authorization
	requests in conformance with this specification		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 allow		respective behavior. In particular, implementations should allow
	deployments to:		deployments to:
	* determine presentation of the authorization details;		* determine presentation of the authorization details;
	* modify requested authorization details in the user consent		* modify requested authorization details in the user consent
	process, e.g., adding fields; and		process, e.g., adding fields; and
	* merge requested and preexisting 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.
	skipping to change at line 1233 ¶		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 of 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 the 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		scope value potentially applicable for an email as well as a cloud
	an email as well as a cloud service) through audience restriction.		service) through audience restriction.
	The AS MUST properly sanitize 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		but it requires another message exchange between the client and the
	exchange between the client and the 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. IANA Considerations		14. IANA Considerations
	14.1. OAuth Parameters Registration		14.1. OAuth Parameters Registration
	The following parameter has been registered in the "OAuth Parameters"		The following parameter has been registered in the "OAuth Parameters"
	registry [IANA.OAuth.Parameters] established by [RFC6749].		registry [IANA.OAuth.Parameters] established by [RFC6749].
	Name: authorization_details		Name: authorization_details
	skipping to change at line 1428 ¶		skipping to change at line 1426 ¶
	[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>.
	15.2. Informative References		15.2. Informative References
	[CSC] Cloud Signature Consortium, "Architectures and protocols		[CSC] Cloud Signature Consortium, "Architectures and protocols
	for remote signature applications", Version 1.0.4.0, June		for remote signature applications", Version 1.0.4.0, June
	2019, <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, "Electronic Signatures and Infrastructures (ESI);		[ETSI] ETSI, "Electronic Signatures and Infrastructures (ESI);
	Protocols for remote digital signature creation", V1.1.1,		Protocols for remote digital signature creation", V1.1.1,
	ETSI TS 119 432, 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",
	skipping to change at line 1542 ¶		skipping to change at line 1540 ¶
	"https://op.example.com/userinfo"		"https://op.example.com/userinfo"
	],		],
	"claim_sets": [		"claim_sets": [
	"email",		"email",
	"profile"		"profile"
	]		]
	}		}
	]		]
	Figure 25: Example of 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 Figure 26.		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,
	skipping to change at line 1583 ¶		skipping to change at line 1581 ¶
	"id_token": {		"id_token": {
	"auth_time": {		"auth_time": {
	"essential": true		"essential": true
	}		}
	}		}
	}		}
	}		}
	]		]
	Figure 26: Advanced Example of 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 Cloud Signature		electronic signing in ETSI TS 119 432 [ETSI] and the Cloud Signature
	Consortium (CSC) API for remote signature creation [CSC].		Consortium (CSC) API for remote signature creation [CSC].
	[		[
	{		{
	"type": "sign",		"type": "sign",
	skipping to change at line 1628 ¶		skipping to change at line 1626 ¶
	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		identifies the respective document to the user, e.g., to be used
	in 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.
	[		[
	{		{
End of changes. 70 change blocks.
	140 lines changed or deleted		138 lines changed or added
This html diff was produced by rfcdiff 1.48.