FEP-2c59: Discovery of a Webfinger address from an ActivityPub actor

Standards Fediverse Enhancement Proposals
, ,
52

aside from this, concerns from 2 years ago remain unaddressed:

issue 1: “webfinger address” is not defined in webfinger

A Webfinger address is an email-address-like identity in the form user@activitypub.example. Following the Webfinger protocol, a client can discover information about the person at that address

this statement is false. webfinger allows discovering information about resources by their uri. you can’t take a string like user@activitypub.example and get any meaning out of it unless you give it a scheme, which comes with its own semantics. for example, mailto:user@activitypub.example identifies a mailbox (specifically, the act of sending an email to that mailbox), while acct:user@activitypub.example identifies an account on a system (similar to a UNIX user account, but allowing for other account systems that use email addresses, such as acct:a%40trwnh.com@site.example identifying “the account a@trwnh.com on site.example”, assuming that site.example tracks accounts by email addresses instead of by usernames.

furthermore, the acct: URI scheme defined in RFC 7565 does not have a default resolution method. it identifies the account even if webfinger is not used, and can be used without webfinger.

this part of the motivation should be rewritten to accurately describe how webfinger is actually used in fedi, which is for mastodon-style “handles” of the form @user@domain, which have an associated resolution protocol using webfinger:

  1. let DOMAIN be the last part when you split on @
  2. let RESOURCE be the result of replacing the first @ of the handle with acct:
  3. construct a webfinger uri of the form https://DOMAIN/.well-known/webfinger?resource=RESOURCE
  4. filter the JRD links for an item with rel=self and type=AS2
  5. the href of that item is the actor id.

you can’t assume this protocol is always in effect simply from a string user@domain or even a uri acct:user@domain. the uri for the webfinger result is https://DOMAIN/.well-known/webfinger?resource=RESOURCE. (you could consider a uri scheme like webfinger: which makes this shorter, but it probably isn’t worth breaking the network effects of https: just to be able to refer to webfinger://DOMAIN/RESOURCE. maybe web+finger:// could be useful, but like other web+ schemes it shares the same issues.)

issue 2: preferredUsername is functionally required by mastodon et al

This technique can cause issues for certain actor URLs. First, preferredUsername is not a required property for an ActivityPub actor.

introducing a new property which is also “not a required property for an ActivityPub actor” seems like weak justification. i would remove the quoted part here entirely.

issue 3: incorrect description of canonicalization

Second, it becomes inconvenient to use subdomains or alternate domains for actor URLs. If the original WebFinger is evan@organization.example, and the ActivityPub URL is https://social.organization.example/evan, the Webfinger will be canonicalized to the longer evan@social.organization.example. A similar problem arises if the actor URL uses one subdomain per user, like https://evan.organization.example/.

no, the canonical handle is the subject of the JRD returned from social.organization.example’s or evan.organization.example’s webfinger endpoints.

going from a handle to an actor, you take the domainpart as the webfinger host, and lookup the corresponding acct: URI of the handle. it then links to the actor.

once you have the actor, you can go from the actor to the canonical handle. to do this, you use the actor’s host as a webfinger host and lookup the actor (or their preferredUsername + host) via the host’s webfinger endpoint. the subject is then the “canonical handle”. you can then verify this handle if the domainpart of the acct: uri in the subject is different from the host of the actor.

in other words, if evan.organization.example says that acct:evan@evan.organization.example has a subject of acct:pompous@idiot.example, then the canonical handle is @pompous@idiot.example. you can verify this by checking the webfinger endpoint on idiot.example to see if it agrees.

there’s no “inconvenience” here, just 1 extra request if you don’t trust the actor host to make claims about cross-origin accounts.

using a dedicated property for a handle still incurs verification to see what the host says the subject is. ironically, depending on your trust model, you could use the so-called “webfinger” property to skip webfinger resolution entirely (since you already have the claimed subject!) if it’s on the same domain and you apply same-origin trust (and then you only need to do webfinger lookup if the domainpart and the host are different).

issue 4: considerations for jsonld

the FEP seems to assume the jsonld context of https://purl.archive.org/socialweb/webfinger will always be used, but there is not a requirement that actor documents MUST use this jsonld context. hence, other serializations are possible, and by default (AS2 only), this is what the current jsonld context expects for compaction:

{
  "https://purl.archive.org/socialweb/webfinger#webfinger": {
    "@value": "acct:foo@bar.com",
    "@type": "http://www.w3.org/2001/XMLSchema#string"
}

this is mentioned in the previous post in further detail.