Re: When is "phone home" ok, if ever?

Beautifully put, Daniel. The question of how long the data over which any digital signature is valid will vary dramatically with the issuer, the context, and the verifier’s requirements. But the step function between the value of the unsigned data we have today (and all the fraud and attack surfaces that exposes) and the value of signed data is so huge that just solving that problem is a huge leap forward.

=Drummond

From: Daniel Hardman <daniel.hardman@gmail.com>
Date: Wednesday, May 7, 2025 at 8:28 PM
To: steve.e.magennis@gmail.com <steve.e.magennis@gmail.com>
Cc: Kim Hamilton <kimdhamilton@gmail.com>, Manu Sporny <msporny@digitalbazaar.com>, W3C Credentials CG <public-credentials@w3.org>
Subject: Re: When is "phone home" ok, if ever?
> The only way a verifier can resolve uncertainty between the information Alice presents and what the issuer currently intends to be the factual state of the information is with a phone home step

Even if you consult an issuer in real-time, there is no such thing as *perfect* freshness; there is only *good enough* freshness, because in the time it takes a phone home response to traverse the internet, data can become stale. A phone home therefore doesn't guarantee that a verifier is computing against the issuer's *current* intentions -- only that it is computing against the issuer's intentions *when the issuer decided how to answer their question*.

A possible reaction to this is: "Fine, but in our use case, good enough freshness means as close to zero latency as possible!" This sounds rational, but freshness isn't free, and after exploring this issue in telco (where sub-second timing is the norm for many things) I have become dubious. I predict that across verticals, in almost all contexts, processes that *trigger* status changes take longer than the processes that *communicate* those changes to verifiers. When Alice is pulled over for drunk driving on May 1, perhaps she meets criteria for having her driver's license revoked. How long does it take for the legal system to adjudicate the assertion that she meets those criteria? Days or weeks. Even pre-emptive suspensions (which law enforcement can sometimes do before court proceedings unfold) require paperwork from law enforcement to the DMV, and that takes days. So let's say that on May 15, a suspension or revocation event propagates through the DMV's database, Will it substantially improve freshness (now already two weeks later than Alice's infraction) if the data propagation happens in milliseconds versus a minute or an hour? This may be why suspension and revocation dates on driver's licenses are only precise to the day. If I fetch status on a given driver's license in the morning, there's no need to fetch again before midnight. So apply similar logic to first responders. If the city dispatch office that empowers and coordinates first responders demands that the world react to the revocation of their fired medic's identity badge with freshness that's measured in seconds or even minutes, I would ask whether the staff in the city dispatch office RUNS, not walks, to their computer terminal to perform the revocation. If the answer is no, then the leisurely pace of the issuer shows what the true freshness requirement is.

If you (mostly) buy this argument, then I think that VCs can (mostly) achieve realistic freshness requirements without phone home.

Setting aside the practical argument above, I would also say that if (near) perfect freshness is truly desirable, why sign assertions at all? The issuer can simply publish unsigned assertions and say, "check with me to confirm". Now freshness and phone home are as perfect as possible. You don't need an issuer to have an identifier with resolvable key state, and you don't need the VC data model. (A new standard for phone-home-able assertions instead of verifiable credentials could reuse many constructs from the VC spec, but be far simpler.)

We sign a will because we won't be present when it's verified, and we sign a mortgage so that we can be held accountable for it through a process we don't control. Signing but contradicting these two qualities seems nonsensical to me.



On Wed, May 7, 2025 at 6:57 PM <steve.e.magennis@gmail.com<mailto:steve.e.magennis@gmail.com>> wrote:
A little bit off the main topic, but wanted to comment on:
Verifiers must also be able to inquire about the current status of a credential without revealing to the issuer


I think tension occurs here because usually a holder is presenting information to a verifier that has been attested to by some other party. To put another way, the issuer, not the holder is the data of record and therefore is the sole authoritative source of the state of the data of record at any given time. For example say an employer attested at some point that Alice was an employee of theirs and issued her a credential to that effect. At some later point if the employer stipulated that Alice was no longer an employee, then Alice is no longer an employee from the perspective of a verifier regardless of what the credential she possesses says. The only way a verifier can resolve uncertainty between the information Alice presents and what the issuer currently intends to be the factual state of the information is with a phone home step, or 3rd party involvement. I see most use cases leverage an expiration date as an alternative to phoning home which is low risk in many situations but is definitely not the same as knowing. I’ve also seen some folks try to implement a chain of update events to held credentials where the issuer has both the desire to maintain current data state and sufficient influence over the holder to insist they update the credentials they hold. In most situations I’ve come across either the level of risk using an expiration date is tolerable or some party has sufficient influence over the holder to insist they keep their credentials current at all times. I suspect 1st responders fall into this later category.

-S

From: Kim Hamilton <kimdhamilton@gmail.com<mailto:kimdhamilton@gmail.com>>
Sent: Wednesday, May 7, 2025 1:38 PM
To: Daniel Hardman <daniel.hardman@gmail.com<mailto:daniel.hardman@gmail.com>>
Cc: Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>>; W3C Credentials CG <public-credentials@w3.org<mailto:public-credentials@w3.org>>
Subject: Re: When is "phone home" ok, if ever?

Daniel's point (also touched on by Kerri and Filip) is the essential missing distinction in this discussion. I'd also like to chime in with my supporting thoughts:

1. Auditing is a separate concern/function from verifying.

Put differently, there seems to be a belief that, in order to satisfy issuer auditing requirements, verification must be designed that the issuer can also take a peak while verification is occurring.

2. Standards about making choices (to quote Mike Jones)

Both the spec and Verifiable Credentials Use Cases<https://w3c.github.io/vc-use-cases/#verify-credential> doc are brutally clear that verification must be possible without phoning home. From the use cases doc:

​Verifiers must also be able to inquire about the current status of a credential without revealing to the issuer
1. The entity requesting that status
2. The credential for which status is being checked
3. The subject of the credential being checked


In short, it must be possible to fully verify a credential without leaking usage data to the issuer or anyone else. This is to avoid the so-called "phone home" problem.

The date on that document is 17 April 2025. Has something changed in the last 2 weeks that we are deciding to deviate from this principle, which has been present (at minimum) for the 9 years I've been thinking about/using this spec?

It's pretty clear that verification of a credential is not intended to be burdened with otherwise valid auditing requirements mentioned above; keep these concerns separate.

Sneaking new use cases and requirements into an otherwise mature spec makes it harder to reason about, not just for implementors but for privacy & legal experts.

In short, auditing is a separate behavior / use case, and let's just handle it appropriately, while not compromising the existing spec.

Kim





Sent via Superhuman<https://sprh.mn/?vip=kimdhamilton@gmail.com>


On Wed, May 07, 2025 at 11:40 AM, Daniel Hardman <daniel.hardman@gmail.com<mailto:daniel.hardman@gmail.com>> wrote:
Why can't phone home just be a separate behavior from verification? That is, particular verifiers phone home not to verify a credential, but because a governance framework that constrains their behaviors in certain contexts says that they should, in addition to verifying, also notify a stakeholder (not necessarily the issuer) that a credential has been used? Conceptually, this is not different from the verifier sharing a log of their activity, and it could totally be done without complicating the standardized VC interactions. It would be an attribute of a usage pattern under a particular governance, not an attribute of the credentials themselves.

On Fri, May 2, 2025 at 2:42 PM Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>> wrote:
Starting the weekend off with a charged question that I expect this
community to have some strong feelings about. :)

As we presented earlier this year, some of us are working with first
responders (fire fighters, emergency medical technicians, law
enforcement, and support personnel) to deploy verifiable credentials
for large scale disaster response scenarios.

The first and simplest use case is a "digital badge" for a first
responder that identifies who they are to security personnel that are
trying to secure a particular area during a wildfire, earthquake,
hurricane, or other large scale disaster. It can also be useful for
citizens that need to check a first responder's credentials that might
need to enter their property or their home.

For this use case, some of these first responder organizations are
wondering if we can implement a form of "phone home", with the consent
of the responder, to "check in" when their badge is verified. There
are even requests for an "active tracking beacon" for firefighters
going into dangerous areas that might need to be rescued themselves if
they get into trouble.

So, the "phone home" here is opt-in/consent-based and viewed by both
the responders and their agencies as a safety feature that could save
lives. This feature would exist on the physical badges (VC barcodes)
and digital badges (VCs). It could probably be implemented as a
ping-back mechanism, where a verifier scanning the badge would call an
HTTP endpoint with the VC that was scanned and possibly geocoordinates
(for rescue/audit purposes) and a VC for the entity performing the
scan (for auditability purposes). It could be "turned off" by choosing
NOT to selectively disclose the pingback location (but that would
probably only work in the digital  badge version).

Now, clearly, this sort of functionality is something we've
collectively warned against for a very long time. Implementing this
for something like a driver's license is a horror show of potential
privacy and civil liberty violations. However, implementing this for a
first responder that's running into a wildfire to save a town feels
different.

If we think this is a legitimate use case, standardizing it might
allow digital wallets to warn people before presentation of the
digital credential. So, rather than organizations implementing this
anyway, but in a proprietary way where the "phone home" is hidden,
this would be a way of announcing the privacy danger if the badge is
used w/o consent or selective disclosure.

So, some questions for this community:

1. Is this a legitimate use case?
2. Is this sort of feature worth standardizing?
3. Is there a more privacy-preserving way to accomplish this feature?
4. Should there be wallet guidance around this feature? If so, what
should it be?
5. Should there be verifier guidance around this feature? If so, what
should it be?
6. What horrible, civil liberties destroying outcome are we most afraid of here?

Interested to... oh, wait a sec... *puts on a flame retardant suit*...

Interested to hear everyone's thoughts. :)

-- manu

--
Manu Sporny - https://www.linkedin.com/in/manusporny/

Founder/CEO - Digital Bazaar, Inc.
https://www.digitalbazaar.com/