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

One overarching goal of the work group for 18013-5 was to strive for 'no
failed transactions due to missing transmission capabilities" - because
we know that if the early ecosystem doesn't work too often, nobody will
rely on it. You'd be amused at the gyrations and arguments we had over
the years to find a balance.
This manifested itself as the principle that Readers should be able to
handle whatever mDL/mdoc showed up for verification.

The relevant table is below. I also always caution readers to make sure to
read any keywords and verbal forms in the context of the publishing
organization - there are subtle keyword differences between, e.g. ISO,
IETF, W3C, NIST, etc, that can make translation more complex.

Also, at the time 18013-5 was nearing publication deadlines, we were
satisfied with the 'proximity transaction' / 'no connectivity' modes (aka
device retrieval) but realized that we had to have something for 'online'
scenarios - and if it was not addressed in some way in the standard, there
would be a wild west situation of random implementations doing really weird
stuff. 18013-7 mitigates that issue.

Now that time has moved on, for the next version of 18013-5 and 18013-7
(hopefully arriving in 2025) we are able to add more explanatory text.
We are also taking steps to strongly signal that, now that we have 18013-7
online 'device retrieval' presentation, it's possible to cover almost all
scenarios using the "device retrieval" mode instead of "server retrieval"
mode.

Generally, around the ISO WG table, we "don't like" server retrieval - sure
that means absolutely nothing in the real world, but it is true. You can
observe manifestations of this for example in AAMVA's guidance to their
members that server retrieval is not to be used.
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". I note that
there were discussions in a non-ISO WG about API calls being "phone home"
and that this should be "fixed" - which I found quite amusing given the
noise about this.

Conformance to standards is voluntary - implementers make choices -
surveillance is not good - but just because a standard describes something
doesn't mean that the standards writers are acting in bad faith or that
anyone will choose to implement any of it. 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 to
improve whatever needs improving.


Does this clarify?

[image: image.png]

————————
*Andrew Hughes *CISM
m +1 250.888.9474
AndrewHughes3000@gmail.com



On Thu, Jun 5, 2025 at 8:36 AM Kim Hamilton Duffy <kim@identity.foundation>
wrote:

> Andrew, I was curious why it’s “recommended” in ISO 18013-5 but not
> optional. You mention several reasons. Can you elaborate? It wasn’t clear
> to me from the spec.
>
> Kim Hamilton Duffy Executive Director Decentralized
> <https://identity.foundation/>Identity <https://identity.foundation/>
> Foundation (DIF) <https://identity.foundation/> Email: kim@identity
> .foundation
>
>
> On Thu, Jun 5, 2025 at 7:25 AM Andrew Hughes <andrewhughes3000@gmail.com>
> wrote:
>
>> Server retrieval in ISO 18013-5 is not required for conformance. It is
>> recommended (for several reasons) which, using language from other
>> standards bodies vocabularies means "SHOULD".
>>
>> If you can point out to all of us where server retrieval is "mandatory to
>> implement", we'd be grateful, and will gladly be corrected.
>> andrew.
>> ————————
>> *Andrew Hughes *CISM
>> m +1 250.888.9474
>> AndrewHughes3000@gmail.com
>>
>>
>>
>> On Thu, Jun 5, 2025 at 7:01 AM Manu Sporny <msporny@digitalbazaar.com>
>> wrote:
>>
>>> On Wed, Jun 4, 2025 at 3:24 PM Matteo Frigo <matteof@google.com> wrote:
>>> > We believe that a zero-knowledge presentation of the credential, like
>>> the scheme we presented to this forum a few weeks ago, would solve this
>>> problem.
>>>
>>> It would, I don't think you would get much push back on that concept.
>>>
>>> The "No Phone Home" statement is about something slightly different,
>>> though, Matteo. It is calling attention to the fact that a global
>>> standards organization has created a mechanism that explicitly
>>> mandates phoning home in verifiers, and that functionality can be
>>> turned on and off dynamically, without the user's knowledge. Even if a
>>> ZK presentation system were to exist, the ability of this alternate
>>> system to exist and be adopted is still out there.
>>>
>>> So, we're talking about two related, but mostly independent things.
>>>
>>> > Are people aware of any attacks that we have not considered?
>>>
>>> The approach that you and Abhi presented is very exciting to many of
>>> us. Many of us do see how it technically addresses one of the biggest
>>> problems we're all facing (the ECDSA infrastructure problem). That
>>> said, it is very early days and the number of people that understand
>>> the processes, optimization points, and cryptography are quite small.
>>> It is difficult for many of us to do an analysis because we're all
>>> having to come up to speed to understand the entire stack.
>>>
>>> We are meeting to discuss the approach regularly on Fridays in this
>>> community, but its slow going because of the lack of access to experts
>>> with the particular approach and having to slog through all the
>>> optimization variations.
>>>
>>> I still need to formulate the questions we need to ask of you and Abhi
>>> on what the optimization pain points are.
>>>
>>> The biggest issue, however, is the time it is going to take to get
>>> nation state cryptographic standards organizations to pick it up and
>>> use it... any of it. I see the timeline for doing this in years,
>>> unless they decide to fast track your proposal in the EU or US. You
>>> would have a better understanding of what is going on to make this
>>> happen, though my interactions w/ the US side of things are not
>>> showing that they're anywhere close to accepting any ZK approaches
>>> just yet (they want to see full post-quantum resistance... that is ZK
>>> applied to a post-quantum signature).
>>>
>>> So, the biggest "attack" I see right now is the very slow speed at
>>> which nation state standardization bodies work and the general lack of
>>> interest they seem to have in privacy preserving cryptography. A
>>> number of key individuals I have spoke with care about high-stakes use
>>> cases, and for those, they don't see the point in privacy preserving
>>> cryptographic protocols. So, unless there is more pressure on use of
>>> ZK to protect citizen privacy from the legislative layer... which the
>>> EU digital wallet stuff might create... I don't see this moving
>>> quickly.
>>>
>>> > Irrespective of this specific server-retrieval attack, if one is
>>> worried about the issuer instructing the relying party to track certain
>>> users, it seems to me that any non-ZK presentation is vulnerable to this
>>> kind of attack, and that this is not a MDOC-specific problem.
>>>
>>> Server retrieval is an ISO-18013-5 specific problem. It is true that
>>> other digital credential formats could decide to implement server
>>> retrieval, but the main point is that they have very specifically NOT
>>> done so because they knew how dangerous and privacy invasive dynamic
>>> server retrieval would be to an ecosystem. mDL is unique in mandating
>>> server retrieval for verifiers, and that's the primary thing that some
>>> people were concerned about during IIW.
>>>
>>> > For example, a sufficiently malicious issuer who wants to instruct
>>> relying parties to track certain users could keep generating (r, s) ECDSA
>>> signatures until hash(r,s)=0xdeadbeef, and this particular hash would be
>>> used by relying parties to phone home the issuer.
>>>
>>> That's a different attack than server retrieval. It is possible, but
>>> the main point of the "no phone home" statement is about server
>>> retrieval... not failures at the cryptographic layer, which as you
>>> say, are important to protect against as well.
>>>
>>> > Even with BBS+, if the issuer has a choice of which key to use for the
>>> BBS signature, a sufficiently malicious issuer could use a particular key
>>> for all users it wants to track, and instruct relying parties to track
>>> users that present that key.
>>>
>>> Yes, legitimate attack that we should protect against, but again, this
>>> is not dynamic server retrieval. Dynamic server retrieval is about a
>>> standard explicitly telling a verifier how to phone home. It is
>>> standardizing phone home, which is the primary concern the "no phone
>>> home" statement is attempting to address. It's instructing governments
>>> to NOT adopt technology that does this because not using the feature
>>> is "privacy by policy". What that group is arguing for is more along
>>> the lines of "privacy by cryptography", which is what the solution you
>>> and Abhi are pushing for... as are many of the rest of us. The
>>> statement is saying that "privacy by policy" is a dangerous way to
>>> design identity systems.
>>>
>>> Does that make sense, Matteo? I don't think most would disagree with
>>> many of your assertions, but your assertions are about something other
>>> than dynamic server retrieval.
>>>
>>> -- manu
>>>
>>> --
>>> Manu Sporny - https://www.linkedin.com/in/manusporny/
>>> Founder/CEO - Digital Bazaar, Inc.
>>> https://www.digitalbazaar.com/
>>>
>>>