How does an Issuer communicate a single-use (or similar) policy

[paulbastian]

Issuers should signal to the wallet if he assumes/requests a privacy-preserving presentation of its credentials by the wallet. This topic came up during the wg call around openid/OpenID4VC-HAIP#229.

As the main (or only) motivation for batch issuance was to enable such a policy, I had assumed that the presence of the batch issuance parameters in the issuer's metadata is that signal, as we don't have any other options today. We may define more fine-grained policies in the issuer metadata, but that train has passed for VCI 1.0.

Therefore, I propose (or actually @GarethCOliver during wg call) that we use the batch issuance parameters as a signal until we have better mechanisms in 1.0, and assume single use policy unless there is an out-of-band agreement between the issuer and the wallet

[Sakurann]

discussed in the WG. different issuers/governments/countries have different requirements, so the need for this feature seems to be there. no easy solution. Ideally, would like to solve in VCI 1.1. Might need a call with ETSI. OIDF members encouraged to comment on the ETSI documents. please keep discussing on the issue.

ESI(24)000274r3_ETSI_TC_ESI_technical_position_paper_on_engagement_with_Comm.docx

[paulbastian]

notes from IIW:

• policy is optional to use by the issuer
• ecosystems can define new policies
• policy is a signal, recommendation for the wallet, could be solved by some policies
• others argue the policy must be followed, otherwise it doesn't make sense
• VCI giving recommendations for a policy -> impl considerations?
• option A
  • define an extensible policy parameter in VCI
• option B
  • define no policies, instead write a comprehensive implementation consideration for the wallet's behavior that solves this
  • let's write one policy and see whether it fits all requirements
  • if this one isn't sufficient, we can create a policy parameter
• we try to make a PR until Monday that Paul can use for discussions input towards ETSI, @GarethCOliver to start a text

[GarethCOliver]

When presenting Credentials from the same Credential Dataset through a cryptographic scheme that does not provide non-correlation, it is RECOMMENDED the wallet does as follows:

• Credentials used for ‘anonymous’ presentations MUST NOT be re-used while there are Credentials available that have not been presented.
• Credentials used for ‘Identifying’ presentations MAY be used for other ‘Identifying’ presentations, but MUST NOT be used for ‘anonymous’ presentations.

A presentation is considered to be ‘identifying’ if the claims being revealed are sufficient to uniquely identify the Credential holder. A presentation is otherwise considered to be ‘anonymous’. A Wallet that is not able to determine the nature of a particular presentation MUST treat it as ‘anonymous’.

When a Wallet is making an anonymous Presentation and does not have a valid Credential from the Credential Dataset that satisfies the above rules the Wallet SHOULD attempt to fetch new Credentials. If it is unable to retrieve new Credentials then it MUST do one of the following.

• Abort the Presentation.
• Re-use a Credential, prioritising those that were previously used for anonymous Presentations. Credentials MUST be used in a rotation, so that each Credential is used the minimum number of times.

If ‘max_presentations’ is specified by the issuer then the Wallet MUST NOT re-use a Credential for an anonymous presentation more than that number of times.

When re-using a Credential in this way the Wallet SHOULD indicate this to the user as part of obtaining the user’s consent.
A credential is considered ‘presented’ when sent to the RP, even if an error subsequently occurs.
To optimize Credential re-use a Wallet MAY re-use a Credential that was previously presented to the same RP a short ago (i.e. within minutes). Such an RP is likely able to correlate the user session through other means, both in person and online.
Issuer policy configurations:

• Allow/forbid presenting to the same RP within a short time window
  • Rational: it is likely uncorrelatable, but there could be edge cases (e.g. I switch to incognito mode, revisit the same website and re-prove my age.) as such a particularly privacy-minded issuer may not wish to allow it.
• Allow/forbid re-use of Credentials when otherwise unable to make a presentation, and up to a maximum number.
  • Rational is that given this is an edge case, a particularly privacy-minded issuer may prefer to fail, while the ‘default’ case of rotating is likely equivalent and prioritizes user choice.
  • Set as max_presentations. If no value then there is no limit
• Indicator that the credential is always identifying, so always supports multiple presentations.
  • This is a more explicit way of showing this than the batch endpoint, as it is possible for an issuer to not support batch but to desire single-use, and similarly an issuer with many credentials may want to specify this for a particular one. In general this shouldn’t be used.

[paulbastian]

I would add:

• in the beginning mention batch issuance as recommended mechanism for credentials
• consider renaming 'anonymous/identifying' into 'non-correletable/correlatable', makes some sentences easier to comprehend in my brain
• how is the Wallet supposed to make the decision whether to abort the presentation or re-use a Credentials from anonymous/non-correletable presentations? This is the second issuer policy parameter?
• comparing this to the ETSI / ARF suggestions:
  • "only_once" -> second parameter set to "forbid"
  • "limited-time" -> I guess there is no equivalent, but this one also makes the least sense to me
  • "rotating_batch" -> second parameter set to "allow", additional "max_presentations" parameter to limit this further
  • "per-relying-party" -> relates to the first parameter?
• the second parameter is more clear to me, the first parameter could be avoided and just give the guidance that if second parameter is "allow"/rotating-batch, then start by sending the same credential to the RP it has seen before, as this likely creates less additional correlation