Re: Elision in DID document

On Fri, Mar 14, 2025 at 4:25 PM Stephen Curran <swcurran@cloudcompass.ca>
wrote:

> Thanks for raising this. I've heard about the idea of selective disclosure
> of DID Docs before, but I've not heard of use cases for it. My model for
> DIDs is that the identifier is bound to a DIDDoc of information (public
> keys, services) that you want every resolver to see.  What are the use
> cases for some of the content of a DID being selectively disclosed?
>
> Note that I'm a big fan of peer DIDs, where the DID (both identifier and
> the DIDDoc) are shared only with the peer(s) that you want to be able to
> resolve it, but I think that is pretty different from selective disclosure
> for a given DIDDoc.
>

On Mon, Mar 17, 2025 at 6:22 AM Will Abramson <will@legreq.com> wrote:

> Yep, that is a good question. I don't have any concrete use case - hoping
> Christopher can chime in here as the biggest advocate for the importance of
> elision.
>
> I just wanted to show how you might technically achieve elision in a way
> that aligns with the DID specification.
>

There are two areas where DID documents can benefit from elision (I don't
use the terms selective disclosure or selective redaction because of name
collisions, see other threads).

The first use case is in support of principles of key separation and
unnecessary disclosure of correlatable public keys. Best practices of key
separation means not using the same keys for everything, and even further,
if you have multiple devices, having different keys for each device. For
instance, each of my development machines have their own set public keys,
one for each proof-purpose
<https://www.w3.org/TR/vc-data-integrity/#proof-purposes>  which they
support. I should not have to disclose all of my public keys for all of my
device — instead, only when they are needed for their proof-purpose. With
elision, I can commit to a public key and a proof purpose, but only reveal
it to a verifier when they need it, and only cthe key that they need to
verify. They can know it was committed previously, and that it should be
accepted on the ~same trust level as the keys they've already accepted, as
they were all committed together.

The second use case is in the area of service endpoints. At one time in the
early DID efforts, there were a lot of interesting capabilities offered by
service endpoints, but soon it became clear that too much information here
could lead to correlation. More modern uses of service endpoints don't
offer details or options. Using elidable endpoints, you can point to
sophisticated services, backup options when services are down, etc., and
only reveal that you committed to them earlier when you need to.

Even though for security best practices (see NIST on key separation) the
first use case is probably more important, it is harder to implement in the
DID 1.1 framework. But supporting elidable service endpoint commitments is
much easier, so that is what I proposed at the last TPAC meeting.

-- Christopher Allen