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

The issue is with this sentence:

> 
> ​The only way a verifier can resolve uncertainty between the information
> Alice presents and what the issuer currently intends to be the factual
> state of the information is with a phone home step, or 3 rd party
> involvement
> 
> 

Status checks can be implemented without is referred to as "phone home" in the text from the use cases doc

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

On Wed, May 07, 2025 at 5:57 PM, < steve.e.magennis@gmail.com > wrote:

> 
> 
> 
> A little bit off the main topic, but wanted to comment on:
> 
> 
> 
> Verifiers must also be able to inquire about the *current* status of a
> credential without revealing to the issuer
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> I think tension occurs here because usually a holder is presenting
> information to a verifier that has been attested to by some other party.
> To put another way, the issuer, not the holder is the data of record and
> therefore is the *sole authoritative source* *of the* *state of the data of
> record at any given time*. For example say an employer attested at some
> point that Alice was an employee of theirs and issued her a credential to
> that effect. At some later point if the employer stipulated that Alice was
> no longer an employee, then Alice is no longer an employee from the
> perspective of a verifier regardless of what the credential she possesses
> says. The only way a verifier can resolve uncertainty between the
> information Alice presents and what the issuer currently intends to be the
> factual state of the information is with a phone home step, or 3 rd party
> involvement. I see most use cases leverage an expiration date as an
> alternative to phoning home which is low risk in many situations but is
> definitely not the same as knowing. I’ve also seen some folks try to
> implement a chain of update events to held credentials where the issuer
> has both the desire to maintain current data state and sufficient
> influence over the holder to insist they update the credentials they hold.
> In most situations I’ve come across either the level of risk using an
> expiration date is tolerable or some party has sufficient influence over
> the holder to insist they keep their credentials current at all times. I
> suspect 1 st responders fall into this later category.
> 
> 
> 
> 
> 
> 
> 
> -S
> 
> 
> 
> 
> 
> 
> 
> *From:* Kim Hamilton < kimdhamilton@ gmail. com ( kimdhamilton@gmail.com )
> >
> *Sent:* Wednesday, May 7, 2025 1:38 PM
> *To:* Daniel Hardman < daniel. hardman@ gmail. com (
> daniel.hardman@gmail.com ) >
> *Cc:* Manu Sporny < msporny@ digitalbazaar. com ( msporny@digitalbazaar.com
> ) >; W3C Credentials CG < public-credentials@ w3. org (
> public-credentials@w3.org ) >
> *Subject:* Re: When is "phone home" ok, if ever?
> 
> 
> 
> 
> 
> 
> 
> 
> Daniel's point (also touched on by Kerri and Filip) is the essential
> missing distinction in this discussion. I'd also like to chime in with my
> supporting thoughts:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> *1. Auditing is a separate concern/function from verifying.*
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Put differently, there seems to be a belief that, in order to satisfy
> issuer auditing requirements, verification must be designed that the
> issuer can also *take a peak* while verification is occurring.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> *2. Standards about making choices (to quote Mike Jones)*
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Both the spec and Verifiable Credentials Use Cases (
> https://w3c.github.io/vc-use-cases/#verify-credential ) doc are brutally
> clear that verification must be possible without phoning home. From the
> use cases doc:
> 
> 
> 
> 
> 
> 
> 
> 
>> 
>> 
>> ​ Verifiers must also be able to inquire about the current status of a
>> credential without revealing to the issuer
>> 
>> 
>> 
>> 
>> 1. The entity requesting that status
>> 
>> 
>> 
> 
> 
>> 
>> 
>> 2. The credential for which status is being checked
>> 
>> 
> 
> 
>> 
>> 
>> 3. The subject of the credential being checked
>> 
>> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>> 
>> 
>> In short, it must be possible to fully verify a credential without leaking
>> usage data to the issuer or anyone else. This is to avoid the so-called
>> "phone home" problem.
>> 
>> 
> 
> 
> 
> 
> 
> 
> 
> 
> The date on that document is 17 April 2025. Has something changed in the
> last 2 weeks that we are deciding to deviate from this principle, which
> has been present (at minimum) for the 9 years I've been thinking
> about/using this spec?
> 
> 
> 
> 
> 
> 
> 
> 
> 
> It's pretty clear that verification of a credential is not intended to be
> burdened with otherwise valid auditing requirements mentioned above; keep
> these concerns separate.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Sneaking new use cases and requirements into an otherwise mature spec
> makes it harder to reason about, not just for implementors but for privacy
> & legal experts.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> In short, auditing is a separate behavior / use case, and let's just
> handle it appropriately, while not compromising the existing spec.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Kim
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Sent via Superhuman ( https://sprh.mn/?vip=kimdhamilton@gmail.com )
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Wed, May 07, 2025 at 11:40 AM, Daniel Hardman < daniel. hardman@ gmail.
> com ( daniel.hardman@gmail.com ) > wrote:
> 
> 
>> 
>> 
>> Why can't phone home just be a separate behavior from verification? That
>> is, particular verifiers phone home not to verify a credential, but
>> because a governance framework that constrains their behaviors in certain
>> contexts says that they should, in addition to verifying, also notify a
>> stakeholder (not necessarily the issuer) that a credential has been used?
>> Conceptually, this is not different from the verifier sharing a log of
>> their activity, and it could totally be done without complicating the
>> standardized VC interactions. It would be an attribute of a usage pattern
>> under a particular governance, not an attribute of the credentials
>> themselves.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 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/ )
>>> 
>>> 
>> 
>> 
>> 
> 
>