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> 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> 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.
>>  >* Issuers <https://www.w3.org/TR/vc-data-model-2.0/#dfn-issuers> are
>> advised not to put the refreshService property
>> <https://www.w3.org/TR/vc-data-model-2.0/#dfn-property> in a verifiable
>> credential
>> <https://www.w3.org/TR/vc-data-model-2.0/#dfn-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> 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>
>>> 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/>*
>>>>
>>>