Using WebFinger to resolve the actor for an acct: without parsing for a self-link

Software
,
1

A WebFinger resource MUST return a JRD as the representation for the resource if the client requests no other supported format explicitly via the HTTP “Accept” header. The client MAY include the “Accept” header to indicate a desired representation; representations other than JRD might be defined in future specifications. The WebFinger resource MUST silently ignore any requested representations that it does not understand or support. The media type used for the JSON Resource Descriptor (JRD) is “application/jrd+json” (see Section 10.2).

Taken at face value, we have the following:

  • JRD is the “default” representation when no Accept header is provided
  • Therefore, “the Webfinger resource” can be defined as the actor itself given an Accept header for the activitystreams type(s).
    • There is no requirement that the “WebFinger resource” be provided in the form of a resource descriptor

A WebFinger resource MAY redirect the client; if it does, the redirection MUST only be to an “https” URI and the client MUST perform certificate validation again when redirected.

So we can come up with the following as a FEP/pre-FEP, functionally speaking:

GET /.well-known/webfinger?resource=acct:user@social.example HTTP/1.1
Host: social.example
Accept: application/ld+json; profile="https://www.w3.org/ns/activitystreams"

HTTP/1.1 302 Found
Location: https://domain.example/actors/1

This saves having to deal with the semantics of link relations entirely. You could also save an HTTP response by returning the resource directly:

GET /.well-known/webfinger?resource=acct:user@social.example HTTP/1.1
Host: social.example
Accept: application/ld+json; profile="https://www.w3.org/ns/activitystreams"

HTTP/1.1 200 OK
Content-Type: application/ld+json; profile="https://www.w3.org/ns/activitystreams"

{
  "id": "https://domain.example/actors/1",
  "alsoKnownAs": "acct:user@social.example",
  // could also be flipped
}

Posting this as there has been some interest in “an AS2 representation of WebFinger”, which to me seems kind of unnecessary, but might as well be conducted as a theoretical exercise.

1 Like
2

One issue is that the AS2 content type does not, in general, mean “return an actor-typed JSON-LD representation”. WebFinger can be used to look up metadata about other AS2 types too. Of course, a WebFinger-related FEP could define the AS content type to specifically mean an actor-typed JSON-LD document associated with the resource, but I wouldn’t recommend it.

3

WebFinger would return an actor object only if requested resource is indentified by acct: URI.

In other cases it may return a non-actor object. For example /.well-known/webfinger?resource=https://social.example/posts/1 would return a Note

1 Like
4

That would help to disambiguate it. Would the type would would be required to be one of Object types categorized in AS2 as an “actor” (given there is no abstract Actor type in AP/AS2) or could it be an extension type (and assumed to be an actor-like thing that can be followed, etc.)? (For example, a Library in Funkwhale.)

5

I think the FEP could say that returned object MUST have inbox and outbox properties but not put any restrictions on type.

6

That’s a possibility. Just keep in mind that having inbox and outbox properties doesn’t make something an AP “actor” (fallacy of the inverse).

7

Title changed to clarify that this is for acct: resources specifically.

8

RFC7033 defines a “rel” query parameter. You could set rel=self in connection with the Accept header to disambiguate this.

1 Like