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

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

I nodded my head through most of your summary of my feedback, Manu, but I'd
like to suggest a slightly different framing of the conclusions. There are
several places where the phone home behavior might "attach" (that is, be
triggered or enforced):

1. On the credential itself
2. On the wallet
3. On the use case

I think you agree with me that option 1 is untenable, because you said that
phone home is bad for privacy. However, I would like my argument to not be
simplified to one about the obvious, direct privacy consequences. I am
saying something bigger. Making phone home inhere in some VCs introduces
troubling questions about the privacy and the security of *the entire VC
ecosystem*. When a privacy hawk disses a "VC phone home mechanism" in the
press, it would be nice if they made it crystal clear how narrowly their
critique applies. But I know from personal experience that this nuancing
isn't realistic; inevitably, the privacy reputation of VCs as a general
category will be tarnished. And it's not just privacy. Phone home
mechanisms can have security consequences and vulnerabilities, too. So,
when a whitehat hacker publishes a CVE for a phone home behavior, the same
dynamic will obtain. In either scenario, how do ordinary humans get
reassured that their VC is unaffected, and why couldn't they be reassured
by the spec itself? I feel that the only safe position is to assert that*
the act of verifying is inherently independent from the act of phoning home*.
Sure, given the right circumstances, they could co-occur -- any number of
behaviors might co-occur with credential usage -- but VC tech has
explicitly defined phone home to be out of scope. Verifiable credentials
verify without issuer coordination; that is what the "verifiable" in
"verifiable credential" means. If an issuer wants to create an artifact
that inherently forces a consultation with them every time the artifact is
used -- regardless of use case -- then the artifact they want to create
isn't a VC, and they might as well not sign at all.

Your framing assumes option #2 -- some wallets phone home, and some do not.
This is tolerable to me, and I think it could be done in a way that's
consistent with what I just said about option 1. A wallet is a squishy
concept, as we all know. If a particular wallet wants to do more with a
given credential, so be it. I think this is super clunky, though, because
if I want to use my first responder credential to apply for an insurance
discount, I have to hold the same credential in two different wallets. Two
issuances? Ugly.

I really think the best option is #3. If we do option 3, then phone home is
a function of the way a credential is used, not a function of the wallet
that holds it or the issuer that made it. When COVID credentials were big,
we all agreed that only certain verifiers should be allowed to demand proof
of COVID status, and we talked about governance frameworks that would
qualify verifiers to ask the question. We imagined that wallets would warn
people if the wrong verifier asked for proof. So why can't we do the same
thing here? Have governance frameworks that require a verifier to comply
with a phone home request in certain circumstances, and require verifiers
to specify the governance that informs their requests, and then create
wallets that know how to recognize references to governance that will
require phone home? (We might say: "But if we say phone home is out of
scope for VCs, why should VC governance framework talk about a non-VC
issue?" I'd respond: governance is bigger than just the VC tech, and can
encompass non-VC topics like user terms and conditions, payment, and yes,
phone home.)

On Mon, May 12, 2025 at 10:13 AM Manu Sporny <msporny@digitalbazaar.com>
wrote:

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