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

On Fri, May 2, 2025 at 5:40 PM Daniel Hardman <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.

Yes, you are correct. I didn't mean to imply that any sort of network
connection was necessary for basic functionality. It certainly is not
-- first responders often do their most time critical work when there
is no network connection present.

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

Yes, that is what the proposal was/is. This is best effort -- the
question is: "Who does the notification?".

It seems that many are, rightfully saying: "Definitely not the wallet."

Some are saying: "Definitely not the VC if it can't be done in a
privacy-preserving way."

So, that leaves the responsibility in the verifier's hands, which is
the entity that is responsible for auditing that first responders are
where they're supposed to be in all of the cases, anyway.

> (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?")

I don't think it was a minority position -- we are exploring NFC,
Bluetooth, and LEO... it's just that VC API had to pick something
concrete as a MUST implement, and HTTP seemed to be the one that most
could agree to. I'll also note that what we're discovering is that
each protocol has different needs and uses and there is only so much
that can be shared between them.

For example, for NFC, messages (in their entirety) can rarely be above
500 bytes, with a total back and forth needing to be below 1KB. So,
you end up needing to do some very different things in some of these
protocols.

That said, we've separated the digital credential, from the protocol
messages, and the protocol itself such that you could run VC API over
HTTP, LEO, and Bluetooth.

I think we ended up with the capability of what you had suggested
since the beginning, but got there in a different way. In any case,
like much of this stuff over the past decade or so... we do seem to be
converging on feature sets that many of us wanted since the beginning.
The mechanics are different (and debatable), but my hope is that we're
seeing the sort of ecosystem come together that we were hoping for
many years ago. Still lots of work to do, and progress is slower than
any of us would like, but we're getting there.

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

Yes, certainly, and an excellent point. So far, this is the strongest
argument in support of keeping the "phone home" details completely out
of the VC. One of the problems is when the behavior of a VC switches
from "not phoning home" to "phoning home" without the consent or
knowledge of the individual. Privacy violations happen when there is a
mismatch of expectations between the parties sharing information.

I was wondering if we could make these "phone home" details for first
responders always selectively disclosable in the VC, so there had to
be explicit consent each time when sending phone home details, but
that makes it more difficult to reason about these credentials to
individuals. Your "auto insurance" use case highlights the problem
there. "Why is my firefighter card asking me if it can phone home to
my employer!? I'm getting car insurance, not checking into a disaster
site!?"

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

Yes, I can confirm that to be our experience in speaking with these
communities as well.

> I'd say use automatic phone home on an anonymous credential that proves firefighter-hood, but not on the identifying credential that proves identity.

Interesting... the reason that the incident commanders are asking for
an automatic phone home is because they want to know exactly who went
into a wildfire and who came out so they know if they need to dispatch
responders or not. I'm not sure knowing someone is trapped, but not
knowing exactly who, helps them address their core concern.

I spoke a bit more to the specifics in the response to Alan, but to summarize:

* If someone is missing, ideally, they have their most recent position
and identity.

* They don't have the budget to attach tracking beacons on all first
responders (device plus data network costs are too high).

* They don't want multiple apps that first responders have to manage
on their phone, they want all of this to happen automatically as first
responders go about their primary job.

So, it seems like we're probably going to have to go back to them and say:

If you want real-time tracking, you're going to need some sort of
"first responder wallet" for "first responder use cases" and when that
thing is used, there is an understanding between you and your
employees on what happens (real-time tracking). This is not ideal
because "government wallets" are problematic when used in
non-government use cases. Real-time tracking of any kind in
non-governmental official use cases is typically a bad idea.

If you want check-in / check-out auditing, that's at the government
verifier, which is the thing that typically does that sort of auditing
today. Doing the auditing within the wallet/VC is viewed as a bad
practice because it is harmful to privacy.

Does that sound right?

-- manu

-- 
Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
https://www.digitalbazaar.com/

Received on Monday, 12 May 2025 16:13:20 UTC