RE: No Phone Home statement by ACLU, EFF, Brave, CDT, etc.

Dear all,

 

The "No Phone Home" initiative emphasizes privacy from a human-centric perspective by advocating for digital identity systems that avoid centralized or federated verification processes, which inherently risk metadata logging and surveillance. 

 

Expanding upon this privacy concern, it is critical to integrate considerations for business confidentiality, particularly in a business-to-business (B2B) context. In such scenarios, centralized or federated look-up processes—used broadly to retrieve cryptographic material, trust lists, revocation data, or API endpoints (e.g., endpoints in DID documents, DPP systems, supply chains, Industry 4.0, or critical infrastructure)—can inadvertently facilitate metadata logging, leading to compromised confidentiality and potential surveillance vulnerabilities. 

 

Therefore, decentralizing these look-up registries through (qualified) DLT is crucial. This decentralization ensures the preservation of business confidentiality and prevents the emergence of monopolistic data aggregation platforms, analogous to a "Google of Supply Chain."

 

Moreover, implementing decentralized look-up mechanisms for decentralized identifiers (DIDs) with robust consensus algorithms significantly aligns with Zero Trust Architecture (ZTA) principles of "never trust, always verify," effectively mitigating risks associated with web-based infrastructure vulnerabilities, particularly in contexts vulnerable to interference from nation-state actors.

 

My Proposal:

 

I propose to consider developing a clear and distinct communication approach around the principle of "Elimination of Metadata Logging and Business Confidentiality Protection", specifically targeting B2B, Industry 4.0, Data Spaces, and Smart City contexts. While it's important to highlight these perspectives, we should avoid conflating the human-centric privacy perspective with business confidentiality aspects, to ensure clarity and prevent confusion among our audiences.

 

Given the significance of this topic, perhaps establishing a dedicated NoMetaDataLogging Manifesto would be beneficial. What are your thoughts on this proposal?

 

BR,
Carsten

 

From: Alan Karp <alanhkarp@gmail.com> 
Sent: Mittwoch, 11. Juni 2025 19:47
To: Oliver Terbu <o.terbu@gmail.com>
Cc: patrick.st-louis@opsecid.ca; Tobias Looker <tobias.looker@mattr.global>; Manu Sporny <msporny@digitalbazaar.com>; public-credentials@w3.org
Subject: Re: No Phone Home statement by ACLU, EFF, Brave, CDT, etc.

 

I agree with the concerns about phone home, but I wonder if there are legitimate uses.  One example in a different area is Identifier Based Encryption (IBE), which uses a central authority to generate key pairs.  The question there is if you can trust that authority to delete the private key after it's been given to the user.  That's not an issue in a corporation, which has the right to decrypt employees' work documents.

 

My question, then, is are there VCs issued by an organization that it has a legitimate right to track?  

 

--------------
Alan Karp

 

 

On Wed, Jun 11, 2025 at 9:22 AM Oliver Terbu <o.terbu@gmail.com <mailto:o.terbu@gmail.com> > wrote:

Thanks, Patrick, I appreciate your thoughtful response.

I agree with your core point: the ISO mDL carries a unique weight because it's designed specifically for personal identification data, which demands the highest bar for privacy. That said, it's worth noting that while the spec was originally designed with the mDL use case in mind, the data model and protocol are in fact agnostic to the specific claims included in a given ISO mdoc. This means the same technology could be used for a broader range of credentials including those not strictly tied to government-issued ID which further reinforces the need for robust privacy safeguards by default.

That's also why I personally think server retrieval should not be part of the spec, optional or not. For example, both the AAMVA implementation guidelines in the US and the EU Architecture Reference Framework (ARF) explicitly prohibit the use of server retrieval in ISO mdoc deployments. The fact that major regional authorities already disallow this feature reflects how serious the risk is perceived to be.

Importantly, the ISO working group is aware of these concerns and is taking steps to address them. The proposal is that in the next version of the specification, server retrieval will no longer be part of the normative specification, but will instead be moved to an informative annex. This reflects a clear direction toward de-emphasizing the feature and discouraging its use.

You're right to point out that refreshService in the VC context is typically framed for public or non-sensitive data, and that the spec includes privacy caveats. Still, I think it's fair to say that in practice, spec design choices can normalize patterns, even risky ones, especially when implementations chase convenience over security. That's why I drew the comparison: not to equate the features 1:1, but to highlight that every standards body faces similar trade-offs and pressures. If we criticize one model for enabling potential issuer tracking, we should acknowledge similar risks elsewhere, even if mitigated differently.

Also, while the refreshService feature includes guidance to avoid using it with non-public data, many of the core use cases described in the W3C VCDM ecosystem explicitly involve PII. For example, the Verifiable Credential Use Cases document includes: Citizenship by Parentage, Expert Dive Instructor, International Travel with Minor and Upgrade.

All of these clearly involve sensitive identity attributes. So while refreshService may be optional and caveated, its coexistence with these PII-heavy use cases reinforces the need for caution, much like with server retrieval in mDL.

To your final question, I agree it's hard to justify server retrieval for ISO mDL, and I don't see a compelling use case that outweighs the risk. I suspect the feature exists primarily to accommodate early use cases and legacy integration models, but that doesn't make it the right long-term architectural choice. I'd personally support its removal in a future revision, or at the very least, tighter constraints and clearer disincentives for its use.

Thanks again for the constructive exchange.

 

On Wed, 11 Jun 2025 at 18:01, Patrick St-Louis <patrick.st-louis@opsecid.ca <mailto:patrick.st-louis@opsecid.ca> > wrote:

Unlike other digital credential formats that may serve broader purposes, the ISO mDL's design is specifically focused on representing personal identification data. This singular and sensitive nature of the data it handles, in my opinion, justifies a heightened level of scrutiny regarding its privacy implications and potential for misuse. This makes it harder to justify optional features such as the server retrieval.

 

For the refreshService, it's clearly stated that this feature is only advised to be used when the credential is relaying public information. Not all use cases leveraging Verifiable Credentials are subject to the same threshold of privacy requirements.

 >  <https://www.w3.org/TR/vc-data-model-2.0/#dfn-issuers> Issuers are advised not to put the refreshService  <https://www.w3.org/TR/vc-data-model-2.0/#dfn-property> property in a  <https://www.w3.org/TR/vc-data-model-2.0/#dfn-verifiable-credential> verifiable credential that does not contain public information [...].

 

I think the feature comparison is somewhat valid between the server retrieval and the refresh service, as in both cases the consumer is receiving data directly from the issuer, aka "phoning home". However, as I mentioned, the additional use cases of Verificable Credential can make such a feature worthwhile in scenarios where no PII is concerned. What is the justification for such a feature in the ISO mDL? I understand it's optional and not recommended, however it's clearly being considered otherwise it would not exist in the first place.

 

Best regards,

Patrick

 

  _____  

 

 

 

On Wed, Jun 11, 2025 at 11:06 AM Oliver Terbu <o.terbu@gmail.com <mailto:o.terbu@gmail.com> > wrote:

I want to echo the importance of the No Phone Home message. This is a critical topic that deserves serious and sustained attention from the digital identity community. The privacy risks at stake are real, and we should continue to engage with them openly and transparently.

At the same time, we should take care not to undermine our shared goals by letting this important debate devolve into fragmented narratives across standards communities. Most of us, whether we work in ISO, or W3C, or elsewhere, are deeply committed to privacy-preserving design and have invested significant time and expertise into shaping technologies with that in mind. Disagreement is both natural and necessary, but mutual respect is essential if we want to make meaningful progress together.

That said, I'd like to respond to one of Manu's points:
> W3C also has global stakeholders, and if we tried to put something like mDL server retrieval in the W3C VC specification, we would have been formally objected into oblivion.

While I agree with the general sentiment of the concern, it's worth pointing out that the W3C VCDM 2.0 does include a feature, refreshService, that allows verifiers to re-contact the issuer to retrieve an updated version of a credential. Depending on how it's implemented, this feature could introduce privacy risks similar to those discussed in the context of Server Retrieval in ISO.

I also want to acknowledge and agree with Tobias' point that such privacy risks are not unique to one standards track. Across the ecosystem, whether it's VCs with refreshService, JSON-LD contexts, or Server Retrieval in ISO, there are design choices that, if misused or poorly governed, can expose users to tracking. It's important that we evaluate all specifications with equal scrutiny, rather than framing one model as fundamentally better than the other.

To be clear: I believe that Server Retrieval in ISO is a bad idea, but it's also a purely optional and rarely implemented feature. The same kind of nuance applies in the VCDM case.

From the VCDM 2.0 specification:
> Including the refresh service inside the verifiable credential enables either the holder or the verifier to perform future updates of the credential.

This capability is legitimate and can be useful. For example, in scenarios involving long-lived or revocable credentials. But if a verifier contacts a refresh endpoint during verification, although that is a very bad design choice by the issuer, that creates a vector for issuers to observe usage patterns.

The point is: no technology stack is free of trade-offs. We should be honest and consistent in how we assess privacy risks, even in systems we personally support, so we can improve them together.

Let's keep this discussion focused on raising the privacy bar across the board, without discrediting the shared values, expertise, and intent that unite our communities.

 

Thanks,

Oliver

 

On Sun, 8 Jun 2025 at 20:17, Tobias Looker <tobias.looker@mattr.global <mailto:tobias.looker@mattr.global> > wrote:

I too am supportive of the overarching message that I believe the no phone home statement is trying to make, but I'm also concerned at some of the discourse, including in this thread which mis-represents how certain technologies work such as ISO mDL.

 

> Then the ISO mDL WG optimized for vendor convenience over civil

liberties, which was (and still is) a terrible idea.

 

Following the same logic, one could also (wrongly) conclude the same about the VC WG in its decision to support data integrity proof types that do not support selective disclosure, which leaves End-Users in possible situations where revealing all details of a credential to all verifiers is the only option. A conclusion I might add which would be unfair to make, just like the one you've attempted to draw here.

 

There are also numerous other possible examples of possible "phone-home" vectors associated to W3C VC based credentials that aren't possible in mDL implementations such as issuers using unique @context URL's which when resolved by a Verifier during verification, could leak where a specific users credential is being verified. This isn't even a feature I might add that can be readily "switched on or off", it's just a consequence of how the underlying technology works and thus IMO is practically more dangerous than mDL server retrieval for the privacy risk being discussed. That being said though, short of not using the underlying technology of JSON-LD, did the VC WG take all reasonable steps to mitigate this risk? Yes, it did, including discussing these possible issues in the security and privacy considerations and what the residual risk cannot be addressed with technology alone is left for policy to decide how to handle.

 

> If an authoritarian government flips the server retrieval switch, it'll be people's lives at stake, not some technologist's feelings. Please treat this seriously, Andrew, and let the ISO WG know to take it seriously as well.

 

It's hurtful to imply people aren't treating this seriously which is certainly how I interpret this statement, in my experience across ISO, W3C and beyond, most WG members (if not all) have a strong sense of responsibility around how the technology they are working on could impact the lives of millions, if not billions of people.

 

This particular hypothetical scenario misses the fact that there are three parties involved in the mDL ecosystem: the Issuer, the Holder and the Verifier. The Issuer cannot just simply "flip a switch" on its own without BOTH holder  and verifier implementations in the ecosystem supporting such a feature.

 

> W3C also has global stakeholders, and if we tried to put something

like mDL server retrieval in the W3C VC specification, we would have

been formally objected into oblivion (and rightly so). This is why W3C

puts such a focus on WG transparency, horizontal review, public

review, and the formal objection process... but that's all a bit

beside the point.

 

Said with a lot of respect for the W3C, this just simply isn't the case, the FedCM API, as you know carries very similar/related tracking risks, and to be clear within the scope of that API's design and intended use, there isn't anything more than could be done. I don’t highlight this example to criticise that API at all, instead I’m just pointing out that the conclusion you’ve drawn around how the W3C would handle this can’t be predicted by highlighting where that risk has been accepted and managed while still resulting in a standard being published. 

 

As I said at the top of my email, I support the overarching intent of the “phone-home” message to the extent that it promotes open, honest conversation around the privacy risk identified, however limiting the discussion to one particular optional feature of one specific standard in this industry does the issue a dis-service. The reality is there are a broad set of risks across a range of technology in this space capable of creating privacy harms.

 

Thanks,


 <https://mattr.global/> 

 


Tobias Looker


MATTR


+64 273 780 461
 <mailto:first.last@mattr.global> tobias.looker@mattr.global



 <https://mattr.global/> 

 <https://www.linkedin.com/company/mattrglobal> 

 <https://twitter.com/mattrglobal> 

 <https://github.com/mattrglobal> 


This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it – please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.

 

From: Manu Sporny <msporny@digitalbazaar.com <mailto:msporny@digitalbazaar.com> >
Date: Sunday, 8 June 2025 at 12:27 PM
To: public-credentials@w3.org <mailto:public-credentials@w3.org>  <public-credentials@w3.org <mailto:public-credentials@w3.org> >
Subject: Re: No Phone Home statement by ACLU, EFF, Brave, CDT, etc.

EXTERNAL EMAIL: This email originated outside of our organisation. Do not click links or open attachments unless you recognise the sender and know the content is safe.


On Thu, Jun 5, 2025 at 12:05 PM Andrew Hughes
<andrewhughes3000@gmail.com <mailto:andrewhughes3000@gmail.com> > wrote:
> This manifested itself as the principle that Readers should be able to handle whatever mDL/mdoc showed up for verification.

Then the ISO mDL WG optimized for vendor convenience over civil
liberties, which was (and still is) a terrible idea.

Before going further, I'll note for those that don't know, that I've
known Andrew for a long time and think highly of him and respect him.
He's always tried to explain the motivations of the closed door
sessions in the ISO mDL WG to the vast majority of us that don't have
access, and for that we are thankful.

There is, however, a part of this narrative that I find objectionable,
so please allow me to provide an alternate perspective.

> Some people have chosen to criticize the motivations of people working in the ISO WG - this is not only offensive, but very hurtful and not conducive to collaboration

If an authoritarian government flips the server retrieval switch,
it'll be people's lives at stake, not some technologist's feelings.
Please treat this seriously, Andrew, and let the ISO WG know to take
it seriously as well.

What you are seeing is a step-up of efforts; the world is calling the
ISO mDL WG out (as well as any other WG that thinks that latent server
retrieval is a good idea). Look at the list of signatories to the "No
Phone Home" website:

https://nophonehome.com/

These are global experts in privacy, civil liberties, cryptography,
and technological architecture. They're all sounding the alarm,
because years of efforts to suggest changes to ISO mDL have not had
the effect on the ISO mDL WG that we would have liked to see.

> Generally, around the ISO WG table, we "don't like" server retrieval - sure that means absolutely nothing in the real world, but it's true.

Well, yes, those are hollow words. Those notions mean absolutely
nothing in practice because, despite the ISO mDL WG generally thinking
that server retrieval is a bad idea, it exists; to be toggled on and
off as a matter of policy.

> This manifested itself as the principle that Readers should be able to handle whatever mDL/mdoc showed up for verification.

On the one hand it's optional, and on the other hand, you have to
implement it to handle whatever shows up for verification. Some are
saying they won't implement it, but it's not those folks we're worried
about -- we're worried about the ones that do implement it (because
they're the ones that are going to win the contract with the
government).

> However, ISO truly has stakeholders from around the world, and has to accommodate a wide range of requirements. There are real world requirements for OpenID Connect style and other server retrieval / federated access models - which have been pejoratively labelled "phone home".

W3C also has global stakeholders, and if we tried to put something
like mDL server retrieval in the W3C VC specification, we would have
been formally objected into oblivion (and rightly so). This is why W3C
puts such a focus on WG transparency, horizontal review, public
review, and the formal objection process... but that's all a bit
beside the point.

If the general feeling in the ISO mDL WG is that server retrieval is a
bad idea, and that there are better alternatives that don't contact
the issuer directly to receive the digital credential, then remove the
feature. You don't have to wait since it's been asserted that no one
has implemented it. Furthermore, if no one has implemented it, that's
a perfect reason to remove the feature. Again, at W3C, that feature
would have never survived its way to publication if no one implemented
it.

None of us are "trying to kill mDL", as has been exaggerated on some
of the more heated social media threads about this topic -- we're
asking for server retrieval to be removed. That's it. Since you agree
with us, let us help you do it; how can we help?

-- manu

--
Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
https://www.digitalbazaar.com/