Can WebFinger resolve subject to a different domain?
My immediate assumption is yes, it can, because someone may use a specific domain merely as a gateway, and point to a different domain for resolution.
e.g. https://activitypub.directory/.well-known/webfinger?resource=acct%3Ajulian%40activitypub.space (note the different TLD)
Resolving to:
{"subject":"acct:julian@activitypub.space","aliases":["https://activitypub.space/uid/1","https://activitypub.space/user/julian"],"links": ...
However, this is a potential security issue because said directory could then poison the resulting data, especially if cached by a user of that webfinger directory.
Am I wrong about that? In the meantime I’ve updated NodeBB’s code to strictly enforce webfinger lookups so if a response subject has a different hostname, then the webfinger query result is considered invalid.
@julian You’re not wrong – it’s just generally not considered “authoritative”.
Compare to DNS via the authoritative nameserver, versus DNS via a public resolver. dns:trwnh.com is different than dns://8.8.8.8/trwnh.com in that the latter is explicitly resolved via Google, or dns://1.1.1.1/trwnh.com to resolve via Cloudflare.
@julian so, here’s what RFC 7033 says:
“The host to which a WebFinger query is issued is significant. If the query target contains a “host” portion (Section 3.2.2 of RFC 3986), then the host to which the WebFinger query is issued SHOULD be the same as the “host” portion of the query target, unless the client receives instructions through some out-of-band mechanism to send the query to another host. […]”
@[email protected] boy, that second half does a bit of heavy lifting doesn’t it :smirk_cat:
@julian srsly
“[…] If the query target does not contain a “host” portion, then the client chooses a host to which it directs the query using additional information it has.”
@julian so, I read that as “You should use the hostname from the webfinger unless you don’t want to or it’s not there.” Your directory idea sounds fine. I could see using it as a high-performance cache, for example.
@julian just out of curiosity is it related to this funny looking thing?
@[email protected] actually, no! That’s a different Julian: @[email protected] :laughing:
But it seems we have thought about the same problem.
@[email protected] @wronglang Only kind of – I’ve never considered the implications of a server resolving a WebFinger query for a user on a different origin. At a glance I’m not sure if it solves more problems than it introduces.
What we do have is WebFinger results linking to ActivityPub actors on a different domain. Fun for things like static site redirects: https://www.hanselman.com/blog/use-your-own-user-domain-for-mastodon-discoverability-with-the-webfinger-protocol-without-hosting-a-server And it enables split-domain setups if the ActivityPub domain delegates its WebFinger lookups back to the WebFinger server.
@[email protected] the only way I can think of it conceivably working is if Webfinger(domain A) » Account (domain B) »
name: user@domainASo, a two-way back-reference.
@[email protected] Current split-domain setups (Mastodon, GTS etc) do the two-way verification like this: the domain A WebFinger result has a rel=“self” ActivityPub link pointing to the actor on domain B, the domain B WebFinger query for user@domainB returns a result with subject: user@domainA. The actor document doesn’t need to do anything special.
That said, FEP-2c59 has seen some uptake since I wrote @canary. I should update the text some time to reference it.
@[email protected] thanks for summarizing the split domain dance for me.
Assuming this is how your canary is set up?
@[email protected] Yep! Compare
and
Note the self link and the subject. In a split-domain setup, the WebFinger results for both hostnames are identical, which is why server software often simply issues an HTTP redirect for ease of implementation.
For clarity, I didn’t invent this, Mastodon came up with it (and respects it for profile views). I noticed while setting up earlier versions of @DailyRucks that Misskey does not. And so @canary was born. 😉
@[email protected] Here’s Mastodon’s server admin documentation for the feature: https://docs.joinmastodon.org/admin/config/#web_domain And here’s GoToSocial’s: https://docs.gotosocial.org/en/latest/advanced/host-account-domain/
Notably, everyone so far other than Takahē treats this as a server-level configuration, when it would work perfectly fine as a per-account setting. I’ve had a FediForum demo titled “None of you have any idea how close we already are to custom handle domains in profile settings” drafted in my head for years, I just can’t find the time to put it together.
… but it is great that you posted it! You’ve shared a common use-case for a webfinger resolution to a different domain… what @[email protected] calls the split-domain.
So in that case, a blanket rejection of a different domain isn’t the right approach.
@[email protected] @[email protected] thanks, most of the computing I do is numerical so as much as I try to keep up with how fedi works it’s just not part of my day to day thought process and it’s very educational to see threads like this one!
I believe there was a questionably named “WebFist” protocol that allowed cross-server WebFinger.
