Investigate avoiding Issuers of UNTP credentials tracking users

[absoludity]

In a LinkedIn comment, Tobias Looker expressed a concern with VC's generally that the issuer of a credential can insert or include data to track use of the credential.

put simply they can place targeted (user specific) URL's inside the VC that the verifier will resolve at verification time thus revealing back to the issuer who's VC is being verified where. This includes but not limited to using URL's in the @ context element of a VC or the associated branding/rendering information for a VC. As I said prior I find this much more dangerous than server retrieval as it can't be turned on or off, its implicitly built into the technology, thus even determining whether tracking or surveillance is occurring would be quite hard.

I then followed up with the comment:

I've just been learning the tooling around VC's etc. over the past months, but regarding the use of issuer-targeted @ context elements of a VC being used to track and not being able to be turned off: yes, if an issuer is untrustworthy, they can issue credentials (with enveloped signatures) that force the use of their targeted context URLs (but that should be easy to determine by looking at the context URLs). But other non-enveloped signature types sign the transformed data, so AFAIUI, the actual URL where the context is defined is not relevant (so your tool could provide and cache the context data in-line, for example), as the signature matches the transformed (expanded) data. Of course, that decision is the issuers. Issuer cooperation impacts on privacy is outlined in the VCDM doc (at https://www.w3.org/TR/vc-data-model-2.0/#issuer-cooperation-impacts-on-privacy ). I see a world where I have to pay a premium price for a credential that is less trackable :)

@zachzeus then asked if we could perhaps investigate whether UNTP itself could take steps to ensure that issuers can't track users easily (or have less ways to be able to track users.

[absoludity]

Just from a very initial look, currently the only restriction we have on the context of the credential is that the first two items are what we expect - the VC context and our UNTP-specific context. There is nothing stopping a credential being issued with a "ghost" third context which is empty (or non-empty) that causes a ping at a targeted URL.

As I mentioned above, that could be avoided by restricting signing to particular non-enveloped methods which are based on transforms of the data. So when a device receives/imports a credential, it could fetch any extra contexts then (which would be tracked) and store that context within the imported credential without affecting the signature. But that's not a great option - we don't want to force certain signing options unnecessarily. Another option may be to include that context file (still downloaded on import) with any verified presentation or credential that is being verified so that the IRI is already dereferenced in the graph? (need to think about that more and try a poc, but it may mean we may be able to fetch the extra context just once per device on import of the credential).

And the original poster's comment was not restricted to context URLs either. They mention branding/rendering information as well as another possibility where a URL in a credential may be followed for display. The approach mentioned above, if it works, should work for any data that would be fetched: fetch it on import of the credential once only, then include its data dereferenced already with whatever credential or presentation is required for verifying.

But even then it relies on the verifier being trusted (for eg., issuers could pay so that verifiers always ping the URL even though it's not required for verification). To avoid that, something like the original idea where a non-enveloped signature is used so the credential owner's device can remove the URL during import without breaking the signature.

I think this requires more than 20m thought, and some POCs :)

[onthebreeze]

There are probably three ways a user interaction could be tracked

1. The QR on the box includes a hosted verifier service (as well as a link to the VC that the service will verify). This makes for a clean user experience because I can just scan the QR with camera and will be shown a verified credential.
2. Alternatively I could have an app that is VC aware and so it will use the verifier of the users choice (or could be in-app). But unless it's a very light VC, my app still needs to GET the VC itself even if it's using it's own verifier. So that still a ping to wherever the VC is stored. In the typical person to person VC scenario, the holder has the VC in their wallet and presents it to the verifier and so the verifier does not need to ping the issuer. But when the "holder" is an inanimate object (eg a battery or a bottle of wine), it isnt a wallet holder than can do a presentation. The only way around that is to embed the whole VC in the data carrier - which wont always be feasible.
3. Some more malicious vector like an LD @context that the app needs to get that is like a ping home.

I'm leaving revocation status check out of this because the bitstring status list is part of the spec and is designed to avoid tracking.

I think the more fundamental question here is "why does the VC community want to prevent call-hime user tracking and does that rationale apply to the traded goods use case?"

• As you'd know there's LOTS of discussion about tracking users. It is all focussed on mitigating the risk that an issuer of a personal (eg a government drivers license) to a private holder (eg you or me) can track our use of that credential whenever we present it (eg to buy alcohol). In this case, issuer is government, holder is a private person
• But in the trade case, the issuer is a manufacturer, the holder is an inanimate object with a QR code on it. So the privacy question is not the same IMHO. The manufacturer could put any QR on the box that would ping a website of their choice when scanned.

So I think we might need some pragmatism for the trade use case

[absoludity]

Yep, makes sense, and I think this is the reason for the Issuer cooperation impacts on privacy section in the VCDM doc