Support ETSI TS 119 472-3 - Attestation provider Reuse Policies

[vafeini]

ETSI TS 119 472-3 defines specific requirements on how attestation providers should advertice their policies regarding how the issued credential should be re-used when presented to relying parties

The specification extends a credential issuer's metadata (as defined in Openid4VCI section 12.2.4) as follows:

• Attribute credential_reuse_policy may optionally be present in the credential_metadata child parameter of each credential configuration in credential_configurations_supported
• Attribute credential_reuse_policy must be a json object that has an id member that identifies the reuse policy. Its value must be a json string
• Attribute credential_reuse_policy may contain an options attrubute defining extra details about the specific reuse policy. It is an array of json objects.

Important: Absence of the credential_reuse_policy parameter shall be understood as that the attestation provider does not limit the number of times that a Wallet Unit may present the PID/EAA.

Reuse policies as defined in ARF
ARF in Annex II defines 4 methods about how a wallet unit can control the presentation of attestation. These methods directly affect the issuance of the attestion (batch or single instance) and the triggering event for the attestation's re-issuance.

Method A - Once-only
Dectates that attestations will be issued in batches. The size of the batch is controled by the specific policy's details. Wallet unit must present each instance of the attestation only once to a Relying Party. There is a lower limit for the number of unused attestations. When this limit is reached wallet unit must request the issuance of a new batch.

Method B - Limited-time
Dectates that a single instance of the attestation is issued that can be used for a limited period. Until the instance expires, wallet unit presents this instance to any Relying Parties that request it. The Wallet Unit requests the re-issueance of the attestation some time before this instance expires. The time before expiration that re-issueance must be triggered is defined in the policy.

Method C - Rotating-batch
Dectates that attestations will be issued in batches. The size of the batch is controled by the specific policy's details. Wallet Unit presents each attestation instance in a batch once, in a random order. When all instances in the batch are presented once the Wallet Unit resuffles the batch in random order and start presenting in the batch again. The Wallet Unit requests the re-issueance of the attestation some time before this instance expires. The time before expiration that re-issueance must be triggered is defined in the policy.

Method D - Per-Relying Party
Dectates that attestation will be issued in batches. The size of the batch is controled by the specific policy's details. Wallet unit must present a different instance to each different Relying Party. The Wallet Unit keeps track of which instance it has presented to which Relying Party. Each time a RP asks for the specific attesation, the same instance should be presented to it. The Wallet Unit requests the re-issueance of the attestation upon the following events:
- Some time before this instance expires. The time before expiration that re-issueance must be triggered is defined in the policy.
- The size of unused instances reaches a lower limit. This lower limit is defined in policy

Method	Issuance	Presentation policy	Re-Issuance triggering event
Once-only (A)	Batch issuance, size controled by policy	Each instance presented only once	Lower limit of unused attestations reached
Limited-time (B)	Single instance for a limited period	Same instance presented multiple times	Attestation expiration time is approaching
Rotating-batch (C)	Batch issuance, size controled by policy	Present each instance in a batch once per Relying party in a random order. When all isntances presented once reset the batch and start over in randdom order.	Attestation expiration time is approaching
Per-Relying Party (D)	Batch issuance, size controled by policy	Present a different instance to each different Relying Party. Same instance should be presented to the same RP if RP request attesation multiple times.	Attestation expiration time is approaching - or - Lower limit of unused attestations reached

In the context of EUDIW the credential_reuse_policy is further specified to follow attestation reuse policies as they are defined is ARF Annex II:

• Value of the policy's id attribute must be arf_annex_ii
• Attribute options is mandatory to exist.
• Each json object in options array must contain a details attribute that is an array of json strings.
• Allowed values of details are: once_only, limited_time, rotating-batch, per-relying-party
• Attribute details is mandatory to contain either once_only or limited_time (but not both of them) and additionaly it might contain rotating-batch or per-relying-party or both.
• If details array contains one of once_only, rotating-batch, or per-relying-party then the json object must also contain attribute batch_size. Its value is numeric and specifies the size of the batch during issuance.
• If details array contains once_only then the json object must also contain attribute reissue_trigger_unused. Its value is numeric, should be lower than batch_size. It defines the lower limit for the number of unused attestations, that when reached wallet unit must request the issuance of a new batch.
• If details array contains one of limited-time, rotating-batch, or per-relying-party then the json object must also contain attribute reissue_trigger_lifetime_left. Its value is numeric and specifies the number of seconds before the expiration of the attestation. When this instant arrives wallet unit must request the re-issuance.

Processing rules

• When multiple policy options are defined (multiple elements in options array) they must not be overlapping, meaning that the values in the respective "details" attribute must be unique.
• The order of policy options must be respected as it is the intention of the issuer to prioritize attestation reuse alternatives.
• When multiple policy options are defined wallet must select the first that it can support.
  - In case of a single element in "options" array with its "details" array having multiple values, wallet should select the first supported by its configuration.
  - In case of muliple elements in "options" array, wallet should select the first option supported by its configuration.
• OpenId4VCI defines property [batch_credential_issuance](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#section-12.2.4-2.9.1) as the upper limit of a batch issuance size. According to ETSI TS 119 472-3 this property must be ignored if credential_reuse_policy is present for a credential configuration.

From the above the allowed combinations of values in the "details" array are:

1. ["once_only"]
2. ["once_only", "rotating-batch"]
3. ["once_only", "per-relying-party"]
4. ["once_only", "rotating-batch", "per-relying-party"]
5. ["limited-time"]
6. ["limited-time", "rotating-batch"]
7. ["limited-time", "per-relying-party"]
8. ["limited-time", "rotating-batch", "per-relying-party"]

SUMMARY: Reuse policy, if present, controls:
--> the type of issuance (batch or single instance)
--> the size of the batch (when reuse policy dectates it)
--> the time the wallet must trigger the attestation's re-issucance
--> the attestation's presentation strategy

Examples

Single option with multiple values in "details"

{
	"credential_reuse_policy": {
		"id": "arf_annex_ii",
		"options" : [{
			"details" : ["limited_time", "rotating-batch", "per-relying-party"],
			"batch_size": 5,						
			"reissue_trigger_unused": 2, 			
			"reissue_trigger_lifetime_left": 655433				
		}]
	}
}

Multiple elements in "options" array

{
	"credential_reuse_policy": {
		"id": "arf_annex_ii",
		"options" : [{
			"details" : ["limited_time"],			
			"reissue_trigger_lifetime_left": 885433
		},{
			"details" : ["once_only"],
			"batch_size": 10,						
			"reissue_trigger_unused": 4					
		},{
			"details" : ["rotating-batch"],
			"batch_size": 40,						
			"reissue_trigger_lifetime_left": 655433					
		},{
			"details" : ["per-relying-party"],
			"batch_size": 60,
			"reissue_trigger_unused": 10,
			"reissue_trigger_lifetime_left": 777543					
		}]
	}
}

Library must be updated to:

• Parse the reuse policy that might be included in credential configurations of issuer metadata.
• Define a configuration property about the caller's supported reuse policies.
• Validate that reuse policies included in issuer's metadata are supported
• Upon credential issuance request creation, validate that the batch size of the policy (if present) is respected by the passed ProofsSpecification. If reuse policy for credential is not present, fallback to current behavior that consults the batch_credential_issuance issuer metadata property.