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

Two quick thoughts:

* Active tracking beacon sounds quite out of scope for Verifiable Credentials; so no, not a legitimate use case

* VC 2.0 spec ( https://www.w3.org/TR/vc-data-model-2.0/#verification ) does not seem to welcome such use cases

Credential status specifications MUST NOT enable tracking of individuals, such as an issuer ( https://www.w3.org/TR/vc-data-model-2.0/#dfn-issuers ) being notified (either directly or indirectly) when a verifier ( https://www.w3.org/TR/vc-data-model-2.0/#dfn-verifier ) is interested in a specific holder ( https://www.w3.org/TR/vc-data-model-2.0/#dfn-holders ) or subject ( https://www.w3.org/TR/vc-data-model-2.0/#dfn-subjects ). Unacceptable approaches include "phoning home," such that every use of a credential contacts the issuer ( https://www.w3.org/TR/vc-data-model-2.0/#dfn-issuers ) of the credential to check the status for a specific individual, or "pseudonymity reduction," such that every use of the credential causes a request for information from the issuer ( https://www.w3.org/TR/vc-data-model-2.0/#dfn-issuers ) that the issuer ( https://www.w3.org/TR/vc-data-model-2.0/#dfn-issuers ) can use to deduce verifier ( https://www.w3.org/TR/vc-data-model-2.0/#dfn-verifier ) interest in a specific individual.

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

On Fri, May 02, 2025 at 2:42 PM, Daniel Hardman < daniel.hardman@gmail.com > wrote:

> 
> One other observation: in a true crisis, the *qualifications* of a first
> responder are far more important than the *identity* of the first
> responder, insofar as access is concerned. (That is, it may be quite
> important to track the identity of each first responder so they themselves
> can be rescued, but not so much so you can decide whether to let them into
> a building.) Given this distinction, I'd say use automatic phone home on
> an anonymous credential that proves firefighter-hood, but not on the
> identifying credential that proves identity.
> 
> On Fri, May 2, 2025 at 3:40 PM Daniel Hardman < daniel. hardman@ gmail. com
> ( daniel.hardman@gmail.com ) > wrote:
> 
> 
>> First, a practical observation: in disaster situations, a "phone home"
>> that accomplishes a verification upon which access depends is probably
>> risky, because disasters and guaranteed internet connections don't always
>> go together. I wouldn't want firefighters who are trying to pull me out of
>> a high-rise in Myanmar after an earthquake to have to be verified by phone
>> home over the internet before they can get through an access gate to reach
>> me. On the other hand, a "phone home" that simply notifies the issuer (or
>> a different party that the issuer designates) on a best-effort basis
>> (e.g., so the first responders can be counted) might be okay. The
>> intermediate position -- best effort to do prior verification, with denial
>> if verification works but returns a "not OK" result, combined with a
>> "default to allow access if verification is impossible" can be gimmicked
>> by attackers and may be unwise.
>> 
>> (Aside: a possible response to this is "well, we don't have to use the
>> internet for the phone home; we could use LoRa or LEO satellites or
>> shortwave radio" -- to which I would say, "Yes! That's why I argued that
>> VC API was setting its sights too low to define verification interactions
>> only over HTTP. And it's why DIDComm always described proving interactions
>> without reference to HTTP constructs. But it seems that this is a minority
>> position?")
>> 
>> Regarding the observation that the imagined scenarios all presuppose
>> careful prior consent, I would say that it's important to keep prior
>> consent *in a use case* distinct from prior consent *in a credential*.
>> Part of the value prop of VCs is supposed to be that the holder can use
>> them with arbitrary verifiers. This means that although
>> proof-of-firefighter-hood might carry prior consent for phone-home during
>> a crisis response, it might be wrong to assume it also carries prior
>> consent for phone-home when applying for a discount on auto insurance.
>> 
>> 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/ )
>> 
>> 
>> 
> 
>