Thoughts on ADX’s usernames, DIDs, and DID Consortium proposals

[j0ev]

Hello bluesky, nice work on getting the ADX spec out. I have a few thoughts and questions on the DID portion of ADX below, maybe they are even intelligible.

1. It seems it would be helpful for the Webfinger response to be signed by the server cert. That way if I use a proxy or cache for lookups my paranoid client can double-check them against the internet roots at least. Is there any interest in such an effort?

2. Privacy seems to be a problem; Webfinger servers see my IP and the user identities I am interested in, as does the DID Consortium. One can partially alleviate this issue by going through a domain provider lookup proxy. Other feasible approaches at the Webfinger layer include supporting prefix search (I believe this is what peergos supports), and a bucketed-response approach like cloudflare’s “k-anonymity”; probably more techniques exist - will there be any effort to improve privacy in ADX’s username & DID lookup routines?

3. I have no doubt the DID consortium design would work to satisfy the proposed DID method constraints, but I wonder if it is really necessary to have an online DID lookup, versus a system that just inlines fully resolved DIDs inside the data format or transport protocol. One simple example of this is to use a DID method like:

    did:inline:[GENESIS-HASH]
        ?1=[BASE64-OF-GENESIS-DOC]
        &2=[BASE64-OF-SIGNED-CHANGE]
        &3=[BASE64-OF-SIGNED-CHANGE]…
   

   You would have to have the Webfinger servers implement GET+POST and keep track of each username's full did:inline URL; POST would work by accepting any validated did:inline that the current one is a prefix of. Consistency becomes the Webfinger server's problem; however any consensus between forked identity chains would have to be dealt with on the end client. I suspect I am missing a very simple reason why this is worse (probably involving consensus); what is it?

[pfrazee]

Hi @j0ev. My first thoughts on these:

1. It seems it would be helpful for the Webfinger response to be signed by the server cert. That way if I use a proxy or cache for lookups my paranoid client can double-check them against the internet roots at least. Is there any interest in such an effort?

Possibly. It would depend on how much benefit we get, and how much of a pain it is for server admins to produce those signatures.

2. Privacy seems to be a problem; Webfinger servers see my IP and the user identities I am interested in, as does the DID Consortium.

We're open to these kinds of improvements, but would need to balance them against complexity, performance, and freshness concerns.

3. I have no doubt the DID consortium design would work to satisfy the proposed DID method constraints, but I wonder if it is really necessary to have an online DID lookup, versus a system that just inlines fully resolved DIDs inside the data format or transport protocol. [...] I suspect I am missing a very simple reason why this is worse (probably involving consensus); what is it?

To your credit, we had to talk through your suggestion to recall why we didn't do this already. I'm constantly trying to sort out if there's a requirement we can drop to reduce the complexity of this.

The issue is the following two requirements:

• A client must be able to reliably get the latest DID Document for a given DID.
• A username (webfinger) must be able to change without disrupting the operation of the account & DID.

Your proposal essentially sets the webfinger provider as the host of the DID Document, which means that you get latest by refetching the webfinger response. If the user has changed their webfinger provider because the old one is gone -- a common occurance in federated networks like ActivityPub -- then there'd be no way to discover the new host.

[j0ev]

It seems it would be helpful for the Webfinger response to be signed by the server cert. That way if I use a proxy or cache for lookups my paranoid client can double-check them against the internet roots at least. Is there any interest in such an effort?

Possibly. It would depend on how much benefit we get, and how much of a pain it is for server admins to produce those signatures.

👍 I suspect the major benefit would be retaining trust (between user and internet CAs) while being performant for common usecases (proxied lookups) and in the face of common threats (a cache layer somewhere is compromised). One other alternative that signed responses allows you is to avoid webfinger altogether; instead have the signed responses published to the DID consortium, e.g. as part of the DID history; this would not really change the trust model but could remove a round trip.

The issue is the following two requirements:

• A client must be able to reliably get the latest DID Document for a given DID.
• A username (webfinger) must be able to change without disrupting the operation of the account & DID.

I knew I was missing something simple here... indeed I certainly violate requirement #1 when using username-less DIDs. Whether weaker requirements could possibly be acceptable for this usecase is a complex topic, I will keep thinking on it.

If the user has changed their webfinger provider because the old one is gone -- a common occurence in federated networks like ActivityPub -- then there'd be no way to discover the new host.

Does this mean that username changes will be part of the DID doc history/log? I think this is the right thing to do, but hadn't seen it explicitly discussed yet.

[pfrazee]

Does this mean that username changes will be part of the DID doc history/log? I think this is the right thing to do, but hadn't seen it explicitly discussed yet.

Not sure how much DID Document history will be retained -- might just be the key rotations, might be everything. If everything, yes that will be available.