Re: Thinking about Webfinger

Johannes,
Please note that my suggestion that HTTP Accept headers might be used is
already defined in the WebFinger RFC
<https://www.rfc-editor.org/rfc/rfc7033.html#page-8>. See paragraph 5 under
"4.2.  Performing a WebFinger Query" which says:

>    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).


Thus, WebFinger defines the JRD format only as the default response format,
not as the only response format. I presented the other alternatives, in
part, just to demonstrate how ugly they are.

Given that WebFinger supports Accept headers, I'm not sure what would
prevent a WebFinger server from supporting any of the following:

   - application/ld+json
   - application/did+json
   - application/did+ld+json
   - application/did+cbor

Also, WebFinger supports resources identified by URIs of any type, not just
acct: URI's. So, why wouldn't I be able to create a valid WebFinger server
that returns a did:document when presented with a did URI instead of an
acct URI? If a request was made without an accept header (i.e. without
"Accept: application/did+ld+json") the WebFinger server would return a JRD
that included a did document as the value of a "did-document" JRD property.
But, if the request provided an appropriate HTTP Accept header, the
WebFinger server might just return a did document as its entire response.
In fact, such a server might be quite useful in providing support for
resolving did methods that aren't commonly supported. I might, for
instance, build a WebFinger server that understood lots of different did
methods and would do the work of retrieving did documents as a proxy. That
would make client code easier to write...

It seems to me that, given WebFinger *as it is currently defined*, we
should be able to have useful support for dids in ActivityPub systems. What
am I missing? I've often heard that WebFinger and DID are somehow
incompatible, but I've never understood what the problem is.

bob wyman