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 > 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/ )
> 
> 
>