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

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