Digital credential API should support requests for directed identifiers

[pkotwicz]

I am using the definition of directed identifier from here: https://github.com/samuelgoto/WebID/blob/master/glossary.md#directed-identifier

The reason for the proposal is:

• Captchas can increasingly be solved by artificial-intelligence-powered-bots
• The digital credential API might be used for the "captcha use case" (For instance, to ensure that all responders to a government surveys are unique humans)
  • In the scenario that a website uses the digital credential API for a "captcha use case", there should be a better credential for the website to request than the user's government id (ex social security number in the US).

I am proposing that wallets which implement the digital credential API support requests for a "directed identifier". (An identifier which is unique for the user, but is different for a given user for each relying party. For additional privacy, we can make the directed identifier change over time (ex be different each month))

[timcappalli]

@pkotwicz this wouldn't be something that would be in scope for the DC API itself.

OpenID for Verifiable Presentations (OID4VP), one of the credential exchange protocols which can be used with the API, supports many credential and identifier types, which can level pairwise identifiers. SIOPv2 is one example where the identifier can be pairwise.

Also, in most cases, identity wallets don't implement the Digital Credentials API, or even interface with it directly (similarly, native passkey providers do not implement or directly interface with the WebAuthn API). See layering diagram for more details.

[bc-pi]

Directed identifiers don't really make a lot of sense in the vaunted "three party model" where the credential is typically issued with no conception of where it will be used.

[dlongley]

(An identifier which is unique for the user, but is different for a given user for each relying party. For additional privacy, we can make the directed identifier change over time (ex be different each month))

It seems use cases with these requirements could make use of, for example, the pseudonym features provided by BBS-signed Verifiable Credentials:

https://w3c.github.io/vc-di-bbs/#pseudonyms-with-hidden-pid

There are probably some other approaches as well, but I think these features should be provided at a different layer (i.e., by credentials themselves), not specifically integrated via more specialized browser API surface.

[dwaite]

There is a BBS extension which will allow for directed identifiers (also known as pseudonyms in more traditional federation circles), and there is a RSA-based mechanism provided through zk-DLEQ, similar to how IETF privacypass works.

The privacypass architecture has been specifically specialized and deployed as a captcha replacement. That usage does not require any user attributes to be shared nor are two passes capable of being correlated via a common directed identifier - each presented pass only proves that you are a real user, not any specific user.

[samuelgoto]

Directed identifiers don't really make a lot of sense in the vaunted "three party model" where the credential is typically issued with no conception of where it will be used.

This is generally the case, but there are ZKP schemes where the holder can shard identifiers while still proving to the verifier that it is tied to a single user of the issuer.

The other mechanism that I heard could be used here is a "one-time throw-away" credential, so that the identifier isn't directed per-se, but can't be used to correlate the user across verifiers.

It feels very unsatisfying if we can't construct the system in such a way that we can't shard identifies.

[swcurran]

We talked a lot about this at DICE last week -- IIW Europe. Notably, achieving unlinkability (non-correlation) using anonymous credentials (such as BBS-based VCs) and using "batch issuance" of one-time use (or one-verifier use) credentials using a conventional signature (non-ZKP). The latter approach is being used or planned in a number of production implementations.

With BBS, an identifier is derived at presentation time by the holder by combining data from the source credential and data (a string -- perhaps their domain) given by the verifier (relying party) in requesting the presentation. The verifier always uses the same data for all requests, and can verify that the identifier is from the issued credential. Every verifier provides different data, and so gets a different identifier -- a directed identifier if you will.

With batch issuance, at issue time the holder generates a set of keypairs for holder binding, and sends the public keys to the issuer. The issuer generates a credential per key which in turn results in a different signature per credential. The holder tracks their usage of the credentials, using them one-time, or perhaps one-time per verifier. When the run out, they contact the issuer to get another batch. Since each verifier (relying party) gets a different holder binding key and signature, they get what amounts to a directed identifier.

This becomes a trade-off in cryptographic scheme vs. data management complexity for the issuer and holder -- moving the problem from the cryptography to the developer.

We held a session at DICE on this, facilitated using this slide deck. It also covers other anonymous credential features such as selective disclosure, predicates (e.g., "Older than..."), holder binding and revocation.

The result was pretty much what @samuelgoto noted -- some thought the batch process was crazy complex and ugly, others thought it was easy ("the issuer just puts a loop around its issue routine" was heard twice :-) ) and very reasonable. Opinions differed on the maturity and acceptability of "fancy cryptographic schemes". All agreed that one or the other approach is a MUST for privacy reasons. No one wants a single super-cookie for each person used across the internet.

All agreed it would be preferred to have the more elegant solution of a derived identifier -- if it was feasible.

[dwaite]

... When the run out, they contact the issuer to get another batch. Since each verifier (relying party) gets a different holder binding key and signature, they get what amounts to a directed identifier...

... some thought the batch process was crazy complex and ugly, others thought it was easy ("the issuer just puts a loop around its issue routine" was heard twice :-) ) and very reasonable...

Batch issuance is very easy and can be done in a loop (and can be done with parallelized signing algorithms).

Batch issuance with persistent credentials with a different holder public key per verifier has some significant negative side effects around directed identifiers. Perhaps the biggest one is that the private key which signifies the relationship the holder has with the verifier must be persisted. If this private key goes away (say, it is bound to hardware which gets lost, stolen, or simply falls victim to equipment upgrades), you will lose the relationship to the verifier.

The secondary one is that the verifier has no way to detect classes of abuse from multiple credentials (with different holder keys) being used by a holder with the verifier as different 'identifiers'.

[dwaite]

A directed identifier is fundamentally an identifier, and sharing one is both enabling a credential to act as a tracking vector (e.g. not "I'm of age to purchase alcohol" but "I'm of age and you can match me in a purchase history database") and enabling digital credentials to be potentially misused by unauthorized verifiers as an authentication mechanism.

The API surface may not allow much either way in its current form, but this would be something to consider in the threat/harm modeling.