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

I would suggest thinking about it as a separation of verification and then data consumption like:


  *   the scanning/verifying + issuer identity substantiation (not phoning home per VC spec)
  *   the relationship between the consumption app related to the verification

The app which consumes the data and validates that the skills info is applicable and assignable does this after the VC verification and issuer identity substantiation.

The relationships between the first responder, organizations that need information about what that person is doing where, and the application that could be storing and sharing that information has its own terms and policies for privacy and data storage outside of the verification of the credential.

This is analogous to an education credential being used on a job application platform. The credential is first verified and determined to be trusted without phoning home, and then the data about the individual that may be used for the job application is consumed and analyzed based on what was agreed to before the credential was shared.

This way, the alignment to the VC spec remains as intended.

From: Brent Shambaugh <brent.shambaugh@gmail.com>
Date: Saturday, May 3, 2025 at 10:46 AM
To: Adrian Gropper <agropper@healthurl.com>
Cc: Manu Sporny <msporny@digitalbazaar.com>, W3C Credentials CG <public-credentials@w3.org>
Subject: Re: When is "phone home" ok, if ever?
If it is permissible when they are acting in the capacity of the state they SHOULD be able to disable it when they are off duty. What does the law say about government employees surrendering rights?

It could be a slippery slope if private organizations can also track?

On Friday, May 2, 2025, Adrian Gropper <agropper@healthurl.com<mailto:agropper@healthurl.com>> wrote:
Is this licensed first responder use-case any different from the much more common use case of a licensed medical practitioner or CPA?

To answer these concerns we should consider trust and accountability. Is the potential penalty for misleading the client (as verifier of the VC) loss of license or loss of a job with a police department or hospital? What audit mechanisms are in place to protect the private right of action of the client as verifier?

As we digitize trust relationships, do we want to encourage individual reputation and responsibility (enforced by a licensing board) or do we want to introduce institutions as employers of the licensed professionals as proxies for reputation and responsibility?

Adrian

On Fri, May 2, 2025 at 4: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/


--
-Brent Shambaugh

GitHub: https://github.com/bshambaugh

Website: http://bshambaugh.org/

LinkedIN: https://www.linkedin.com/in/brent-shambaugh-9b91259

Skype: brent.shambaugh
Twitter: https://twitter.com/Brent_Shambaugh

WebID: http://bshambaugh.org/foaf.rdf#me