Webfinger and did

ActivityPub
1

Hello. This really doesn’t belong in ActivityPub or even here. I’m just not sure what better place to ask. did-core github also seems bad.

So anyway, my question is quite simple. Say you run a service a service on domain.tld and associate to your user Alice a did say did:example:37. Now, Bob has got ahold of this information and wants to contact Alice. He knows that Alice has an ActivityPub Actor somewhere on domain.tld, so he might reasonably try

GET https://domain.tld/.well-known/webfinger?resource=did:example:37

and get the response

{
    "links": [
        {
            "href": "https://domain.tld/endpoints/37_11_407",
            "rel": "self",
            "type": "application/activity+json"
        }
    ],
    "subject": "did:example:37"
}

A further request to https://domain.tld/endpoints/37_11_407, let’s Bob discover Alice’s inbox and they can start exchanging cryptographic secrets.

My question:

Is there already a different solution for resolving did on top level domain? If yes, is it documented somewhere?

2

Can’t help with specifics… but pointing to other DID + AP work FYI: The did:orb Method v0.2 by TrustBloc · GitHub

3

WebFinger is probably one of your better bets, if not the best. The problem is establishing consensus between resolvers, or otherwise knowing who to defer to as “more authoritative”. This is analogous or roughly equivalent to DNS forwarding and propagation to/from root trust.

Bluesky’s AT Protocol has this:

some conceptual assembly required, but i think the flow is something like this:

  1. discover the PDS from some DNS record? or do you just use the handle directly? unclear
  2. GET /xrpc/com.atproto.handle.resolve?handle= at whatever the origin is via step 1?
  3. you should somehow end up with a service and serviceEndpoint at which you can perform additional xrpc calls

reeks of NIH syndrome tbh, you could probably just use webfinger? it’s not like did:plc is decentralized either; it depends on a centralized PLC server as best as i can tell. you might as well depend on a centralized WebFinger server that can you can redirect to or cache the results or whatever. or you can use an alternative root authority, or perhaps your DID method comes with such an authoritative source built in that is actually decentralized in some meaningful way. sky’s the limit, there’s a ton of DID methods and likely there will be more, with the free-for-all that’s currently raging.

1 Like
4

Thanks for the feedback.

Short check on my understanding, the proper form might be something like:

{
   "aliases": [
       "https://domain.tld/endpoints/37_11_407",
       "acct:alice@domain.tld"
    ],
    "links": [
        {
            "href": "https://domain.tld/endpoints/37_11_407",
            "rel": "self",
            "type": "application/activity+json"
        }
    ],
    "subject": "did:example:37"
}

Note the inclusion of the alias parameter.

Consulting RFC 7033 on the matter leaves me mostly undecided. I currently lack the vision for how this should all evolve except for ‘got a problem; let’s reuse the tool I know’.

I think this an issue that should be revisited in the future.

5

if you want compat with mastodon then the acct: uri should be the subject, not an alias. also the self link will be your activitypub id in most cases, but a redirect might work… unsure.