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

Thank you for the clarification, Robin. Ad hoc changes related to VCs can
be made as issuance, verification, or both. The system can depend on wide
area, local area, or just proximity communication. Accountability can be
based on a variety of logging architectures over various timescales and
changes to the network access.

All of this makes sense to me but I still have trouble linking ad-hoc to
the VC data models or protocols other than to imagine that the devices
managing VCs would need to have mandated disaster-preparedness features
such as the ability of mobiles to dial 911 even when the SIM card is
invalid.

Adrian

On Wed, May 7, 2025 at 6:35 AM Robin Wilton <wilton@isoc.org> wrote:

> Hi Adrian,
>
> One difference can be illustrated if we think of the way in which
> first-response personnel are organised in order to deal with a large scale
> crisis.
>
> First, there’s usually a pre-defined structure (Gold, Silver, Bronze
> commanders, supported by other roles such as scribe, runner, comms, etc.).
> As you can see, this is a heavily role-based concept.
> Second, given that we are talking about major incident response here
> (which could be national in scope… see recent power cuts in the Iberian
> peninsula), the scapoe of the incident could well mean that key staff
> simply are not able to attend, physically, to take up their role.
>
> By contrast with the licensed medical practitioner/CPA case, that means
> any role-based authN/authZ system needs to be capable of raising/lowering
> the level of someone’s credentials/privileges on an *ad hoc* basis, to
> adapt to the absence of any key staff. This also introduces a potential
> point of failure, if the missing staff are precisely the ones who are
> authorized to make those changes.
>
> UK CPNI (Centre for the Protection of National Infrastructure)
> stakeholders considered some of these issues in relation to the anthrax
> scares of 2001 - but since the CPNI has now been replaced by the NPSA
> (National Protective Security Agency) I don’t know how much organisational
> memory there would be of those earlier deliberations.
>
> Good luck with the design… …  ;^,
>
> R
>
> Robin Wilton, Senior Director - Internet Trust
> wilton@isoc.org
>
> [image: image001.png]
> internetsociety.org | @internetsociety
>
>
>
> On 3 May 2025, at 00:16, Adrian Gropper <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>
> 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/
>>
>>
>