Re: DID Threat Modeling Deck & Image

On Tue, Feb 3, 2026 at 10:57 AM Tom Jones <thomasclinganjones@gmail.com>
wrote:

> Sorry i missed this meeting.  I would support TM for DID - BUT
> i need to understand enuf of a use case to create a DFD for use -
>

The use case document for DIDs can be found at
https://www.w3.org/TR/did-use-cases/

HOWEVER, the diagram was shared as part of the presentation in the call,
not as a stand-alone deliverable. I'm still working on the prose that would
go along with that diagram, which would give a better walk through of how
those components fit together.

I hope to have something more complete shortly.


> So the first step is resolution - fine
> what's next - established trust?
>

I don't believe that "trust" is the goal here. IMO, trustworthiness is the
goal. And in DID Resolution, trustworthiness is largely in two models:

1. You run the code yourself. Whether open source or your own proprietary
implementation, running it yourself gives you the greatest opportunity to
believe the running instance is secure, reliable, and conformant, all
features of trustworthiness.

2. You use a service provider you trust. I consider this the Coinbase
model. Cryptocurrencies don't depend on service providers like Coinbase,
but consumers do. In this use pattern, we have not standardized much around
why you should choose to trust a particular resolution service provider. We
use https to ensure your communications with your chosen resolver is
secure, but the trustworthiness of that service provider is an independent
judgment that the spec is quiet on.


> - establishing an enduring relationship on which trust can be built?
>

Depends on your model. For #1, you invest in your own technical capacity,
e.g., hiring an IT team that can,  or learning yourself how to,
independently vet the open source tech you run or you rely on the wisdom of
crowds and trust the repo.

For #2, enduring relationships is probably your best fallback. To wit, I
don't trust Coinbase to store my long term cryptocurrency holdings, but I
do pick & choose Coinbase amongst its competitors because, frankly, over
time it has delivered as promised.


> - Just validating some attribute like 1 i am a human 2 - I am over xx year
> of age 3- I am a resident of the EU
>

I'm not sure I understand this. DIDs are a framework for identifiers. It
seems you're talking about attestations, which is typically managed through
credentials, like mdocs or VCs. To validating an attribute is out of scope
for DID Resolution, and likely DID Core. Instead, we are putting hooks in
the VC spec that can use verification methods in Controlled Identifier
Documents such as DID Documents.

Establishing trustworthiness of a particular resolver, or a particular DID
method, is independent of establishing the trustworthiness of a particular
attestation from a specific authority.

The separation of identifiers and claims is one of the most important
innovations in the DID/VC ecosystem. It enables trustworthiness to travel
with data objects independent of network topology. One can establish
confidence that they are the subject of a VC without deference to a third
party authority: the cryptography is a strong factor for identity
assurance. And separately, issuers can make attestations available without
deference to any central authority. Companies, nations, even individuals
can all issue VCs that have strong guarantees for assurance, without any
mandated deference to a central authority.


> - Others?
> Peace ..tom jones
>
>
> On Tue, Feb 3, 2026 at 10:27 AM Joe Andrieu <joe@legreq.com> wrote:
>
>> Here is the powerpoint from today, as well as the initial DFD I created
>> for the DID work.
>>
>> I look forward to feedback as we develop this threat model.
>>
>> -j
>>
>> --
>> Joe Andrieu
>> President
>> joe@legreq.com
>> +1(805)705-8651
>> ------------------------------
>> Legendary Requirements
>> https://legreq.com
>>
>>
>

-- 
Joe Andrieu
President
joe@legreq.com
+1(805)705-8651
------------------------------
Legendary Requirements
https://legreq.com


<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.www.avg.com
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Received on Thursday, 5 February 2026 19:45:45 UTC