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

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>
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,
>
> *[image: MATTR website] <https://mattr.global/>*
>
>
>
> *Tobias Looker*
>
> MATTR
>
> +64 273 780 461
> *tobias.looker@mattr.global <first.last@mattr.global>*
>
> *[image: MATTR website] <https://mattr.global/>*
>
> *[image: MATTR on LinkedIn] <https://www.linkedin.com/company/mattrglobal>*
>
> *[image: MATTR on Twitter] <https://twitter.com/mattrglobal>*
>
> *[image: MATTR on Github] <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>
> *Date: *Sunday, 8 June 2025 at 12:27 PM
> *To: *public-credentials@w3.org <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> 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/ <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/
> <https://www.linkedin.com/in/manusporny/>*
> Founder/CEO - Digital Bazaar, Inc.
> *https://www.digitalbazaar.com/ <https://www.digitalbazaar.com/>*
>