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

Just to add one more nuance to the refreshService discussion:

While the spec advises against using refreshService for non-public data,
the mechanism itself does not technically prevent implementations from
using it in a pattern functionally similar to ISO server retrieval. For
example, a credential could contain a refreshService endpoint that, when
contacted by a verifier, results in the issuance or retrieval of a new
credential containing PII. In this case, the original credential
essentially acts as a bearer token (often a one-time token) containing no
PII, but still enabling that exchange.

This isn't a common pattern, but it is architecturally possible and that's
the key point. Just as with server retrieval in ISO mDL, the existence of
such a mechanism introduces latent privacy risks, even if those risks are
mitigated or discouraged in the guidance.

My intention isn't to draw a full equivalence, but to underscore that we
should assess both design and deployability when evaluating privacy
posture, not just normative text.

On Wed, 11 Jun 2025 at 18:19, 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/>*
>>>>
>>>