Handling of JRD with no `subject` in reverse discovery

[tesaguri]

Section 4.4.1 of RFC 7033 requires the following:

The "subject" member SHOULD be present in the JRD.

So the presense of the subject member in a JRD document is not a MUST requirement and thus it is possible that the member is absent, even though that is not a recommended practice.

The RFC is not clear about the interpretation of an absent subject member, but I suppose we can assume that an absent subject implies the same value as the resource parameter value of the request, so the reverse discovery algorithm of the report can be like the following:

4. Optionally: If the subject JRD from the previous step has a subject that contains an acct: URI different from the one you constructed, perform a verification discovery against that acct: URI afterward. (In such cases, the subject of the JRD denotes the expected canonical identifier.)

Or, more explicitly:

4. Optionally: If the JRD from the previous step has a subject that and it contains an acct: URI different from the one you constructed, perform a verification discovery against that acct: URI afterward. (In such cases, the subject of the JRD denotes the expected canonical identifier.)

[pfefferle]

I just read the section in the spec: https://swicg.github.io/activitypub-webfinger/#reverse-discovery

I would recommend to not use the preferredUsername to "assume" a WebFinger acct URI, but to use the ID for the look up instead (maybe to use the preferredUsername as fallback).

GET /.well-known/webfinger?resource=https://activitypub.example.com/actor/1 HTTP/1.1

This makes things easier because:

• You do not have to verify the ID afterwards
• You could simply use the subject (if an acct: URI) or see if there is an acct: in the aliases instead.

And it would be more consistent when thinking about Domain wide IDs like discussed here: https://github.com/swicg/activitypub-webfinger/issues/17

[pfefferle]

Just did some research and found out that the documented way is how Mastodon is doing reverse lookups and it is indeed hard to compete with that (no bias): https://github.com/mastodon/mastodon/blob/main/app/services/activitypub/fetch_remote_actor_service.rb

But I would love to at least have a discussion if that is really the best way or at least to maybe mention alternatives?!?

[tesaguri]

So, as far as this issue is concerned, interpreting absent subject as the same value as the resource parameter would be problematic when you are using the actor ID as the resource parameter value, I assume?

In that case, I suppose we could consult the aliases member as you mentioned. But the server might well have set the subject to the acct: URI in the first place if it included the URI in the aliases value, and I expect we might end up using the preferredUsername (or some other mechanism like FEP-3c59) as a fallback.

[tesaguri]

The Extensible Resource Descriptor (XRD) Version 1.0 standard, on which JRD is based, describes the following:

If <Subject> is not specified, it is expected that the resource described by the XRD will be identified by other means.

From this description, it seems that the handling is intentionally left unspecified, presumably because XRD is a mere file format so that the context URI is not always obvious from the spec's point of view. I feel like WebFinger, as a more concrete protocol, was in a position to specify the handling, but that's not the case, unfortunately.