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

Joining back from some side discussions, I think it's clear that "phone home" needs a clearer definition. We all agree that t he issuer is authoritative for the status of credentials they issue — the difference is on how status checks occur, and what sort of tracking it enables.

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

On Wed, May 07, 2025 at 10:46 PM, < steve.e.magennis@gmail.com > wrote:

> 
> 
> 
> Perfect vs. Good Enough freshness I think is a fair topic to dissect. To
> be more precise though I think that the latency between the time a ground
> truth exists and the time an authoritative issuer makes an assertion is
> likely to be no better or worse than it is today. Adjudication of a drunk
> driving charge takes longer to resolve than issuing an amber alert because
> the value of latency is very different in each case. Practically speaking,
> once an authoritative source makes the information available (updates
> their system(s) of record) is when the freshness clock starts ticking, not
> necessarily when the ground truth occurs. How long it takes authoritative
> updates to get into the hands of a holder, or through some other route to
> a verifier, or even at all, I view as being fundamentally driven by what
> amount of freshness is required by a use case. I hope I didn’t imply that
> zero latency, period, is the ideal. I don’t think it is. I tend to view
> this more as a risk calculation that occurs at the point of verification,
> of the magnitude of a problem that could result if some or all of the
> verifiable information presented by a holder is out of date, relative to a
> potential authoritative update.
> 
> 
> 
> 
> 
> 
> 
> -S
> 
> 
> 
> 
> 
> 
> 
> *From:* Daniel Hardman < daniel. hardman@ gmail. com (
> daniel.hardman@gmail.com ) >
> *Sent:* Wednesday, May 7, 2025 8:26 PM
> *To:* steve. e. magennis@ gmail. com ( steve.e.magennis@gmail.com )
> *Cc:* Kim Hamilton < kimdhamilton@ gmail. com ( kimdhamilton@gmail.com ) >;
> Manu Sporny < msporny@ digitalbazaar. com ( msporny@digitalbazaar.com ) >;
> W3C Credentials CG < public-credentials@ w3. org (
> 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 (
> 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 3 rd 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 1 st responders fall into this later category.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> -S
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> *From:* Kim Hamilton < kimdhamilton@ gmail. com ( kimdhamilton@gmail.com )
>> >
>> *Sent:* Wednesday, May 7, 2025 1:38 PM
>> *To:* Daniel Hardman < daniel. hardman@ gmail. com (
>> daniel.hardman@gmail.com ) >
>> *Cc:* Manu Sporny < msporny@ digitalbazaar. com ( msporny@digitalbazaar.com
>> ) >; W3C Credentials CG < public-credentials@ w3. org (
>> 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 ( 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 (
>>> 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/ (
>>>> https://www.linkedin.com/in/manusporny/ )
>>>> Founder/CEO - Digital Bazaar, Inc.
>>>> https:/ / www. digitalbazaar. com/ ( https://www.digitalbazaar.com/ )
>>>> 
>>>> 
>>> 
>>> 
>>> 
>> 
>> 
> 
>