Re: Worst case example of a proposed DID endpoint?

The example here is a bit faulty for what you are doing.

Someone that publishes a did:sov (replaced by did:indy) *wants* to be
correlated -- they want their data public and to be found. Such DIDs are
*not* for people, they is for organizations that want to have a
public "SSI" (if you will) presence and to have their information public
and found by anyone that is interested.  Anyone using did:sov has agreed to
a governance framework and signed legal agreements about what they can and
can't do in using the ledger.  That includes that there is no private data
put on the ledger.

Next, the vast majority of DIDComm Service endpoints are shared via peer
DIDs (`did:peer:<id>`) -- DIDs that are not published to be globally
resolved, but rather are shared from one peer to another. Only the peer
will ever resolve such a DID.  The peers have no interest in anyone else
seeing their DIDs.

What you are seeing in the did:sov example above is a purposefully public
DIDComm service endpoint so anyone in the world can initiate a DIDComm
connection with the DID Controller as soon as they receive the DID.  Again
-- the goal is to be correlatable and shout to the world "Here I am -- come
connect with me".  BTW -- that service endpoint is only used to bootstrap a
connection. As the connection is established, the two parties (peers)
switch to using peer DIDs that are not published anywhere.

So, perhaps the examples might be helpful for what you want to show, but
hiding the data in the DIDs is contrary to the goals of publishing those
DIDs.

On Fri, Oct 18, 2024 at 3:53 PM Christopher Allen <
ChristopherA@lifewithalacrity.com> wrote:

> On Fri, Oct 18, 2024 at 3:01 PM Markus Sabadello <markus@danubetech.com>
> wrote:
>
>> DIDComm endpoints can be a bit complex, e.g.:
>> https://identity.foundation/didcomm-messaging/spec/#service-endpoint
>>
>> The idea of having a DID (instead of HTTPS URL) as service endpoint has
>> been proposed here:
>> https://github.com/w3c/did-resolution/issues/7
>>
>> The idea of having non-correlatable endpoints have been discussed here:
>> https://github.com/w3c/did-resolution/issues/35
>>
>> Hope this helps?
>>
>
> Thanks Markus!
>
> The example in did:sov method is a good one for me to start with (
> https://sovrin-foundation.github.io/sovrin/spec/did-method-spec-template.html
> ):
>
> "service": [ { "type": "endpoint", "serviceEndpoint": "
> https://example.com/endpoint" }, { "id":
> "did:sov:HR6vs6GEZ8rHaVgjg2WodM#did-communication", "type":
> "did-communication", "priority": 0, "recipientKeys": [
> "did:sov:HR6vs6GEZ8rHaVgjg2WodM#key-agreement-1" ], "routingKeys": [],
> "accept": [ "didcomm/aip2;env=rfc19" ], "serviceEndpoint": "
> https://example.com/endpoint" } ]
>
> I don't have an example of this from the real world (if someone has one,
> it would be appreciated), but I suspect that in many real-world examples of
> did:sov there might be a lot of correlatable data, as well as
> quasi-correlatable data such as structures.
>
> May goal is to have this subsumed into completely elided property, that
> looks something like:
>
> "service": [ { "type": "elidedEndpoints", "serviceEndpoint": "cbor:<base64
> of a fully elided gordian envelope>" } ]
>
> Fully elided it should be well under 100 bytes.
>
> I also want show how someone could do a proof of inclusion for only the
> portion:
>
> "type": "endpoint", "serviceEndpoint": "https://example.com/endpoint
> (plus the appropriate salts)
>
> …that proves that the endpoint was committed to in the full did controller
> document, without revealing any of other endpoint data.
>
> We will be talking about Gordian Envelope at next Tuesday's CCG meeting,
> and besides an overview, I'd like to show this as a practical example.
>
> -- Christopher Allen
>
>
>
>


-- 

Stephen Curran
Principal, Cloud Compass Computing, Inc. (C3I)
Chair - Sovrin Foundation (sovrin.org)

*Schedule a Meeting: **https://calendly.com/swcurran
<https://calendly.com/swcurran>*