Re: Thinking about Webfinger

Johannes wrote:

> What if we treated [WebFinger] as a dataset that the user can augment at
> will?

*That is exactly what WebFinger was intended to be!* You should be able to
put whatever you like in your WebFinger document. That's one of the reasons
that the "rel" parameter exists -- to allow someone to filter out just the
bits that they care about. But why was the "rel=" parameter thought to be
useful? Such a mechanism would have been a massive overkill if it was known
then that WebFinger files would be as empty as they are today. You only
need to filter a collection when you expect there to be a lot of things in
it that you don't care about. The mere presence of "rel=" should tell you
that WebFinger files were expected to be able to support having lots of
stuff in them.

Look at the RFC. Note that there are examples of rel = "profile-page,"
"business-card," and OpenId "issuer." There could also be "blog," "email,"
"private key," "did," "avatar-image," "preferred-contact-method," etc. If
you had several ActivityPub accounts, you could list them all. If you had a
default "rights grant" for content you create, you could announce it
(perhaps as ODRL) in your WebFinger data. If Mastodon users subscribed to
you via WebFinger, then you'd be able to notify subscribers of the move
simply by changing the values in your WebFinger doc. If you opened a new
blog, people who monitored your WebFinger would discover it easily. That is
the way it was supposed to be.

Concerning privacy, as both Ben and I have pointed out, there is value in
having a trusted intermediary to do lookups so that one's identity isn't
leaked to an arbitrary third party. (As ben points out, if someone can
force you to ping their site simply by posting a new identifier to your
feed, then every post becomes a honey-trap that provides someone with
valuable analysis data.) Also, if one wants "security," as in encrypted
messages, etc. then where better to publish your public key than in a
location that belongs to and is controlled by you? If we don't use
something like WebFinger, or an equivalent did-method, then we're stuck
having to trust someone else to publish our keys and they will
probably only do that if we also allow them to provide the "service" of
generating our keys as well as encrypting and signing messages for us.
(Which means they need to know our private key.) Using such a service would
be insanity if an alternative exists -- even though it will be welcomed by
many who value convenience more than security.

I think we should see WebFinger as what it was intended to be and focus
less on how it has been used. I also think that WebFinger should be seen as
an important part of addressing privacy and security issues.

bob wyman


On Sat, May 6, 2023 at 11:11 PM Johannes Ernst <johannes.ernst@gmail.com>
wrote:

> On May 6, 2023, at 19:05, ben@bengo.co wrote:
>
> It seems like it is more human-centric to accommodate resolving via a
> service chosen by the human doing the resolving, not a service chosen by
> the author or controller of the identifier.
>
>
> Now you opened up a larger issue …
>
> (Perhaps somebody can point to an example for this in the wild, because
> I’d love to see one and am not aware of one (other than self-hosting the
> webfinger endpoint at your own domain))
>
> We tend to treat the data in the webfinger doc as static. As something
> that the developer creates of the app that hosts it, and that’s what that
> is.
>
> What if we treated it as a dataset that the user can augment at will? E.g.
> can add “entirely unrelated” aliases into? So I could say, for example:
>
> * My primary identifier is @j12t@social.coop, and by default its
> corresponding webfinger file has Mastodon stuff in it.
> * But I also have a blog at https://reb00ted.org, and I would like to
> advertise this fact inside the same webfinger file, and declare its
> frontpage url an alias
> * And I have a calckey account at @j12t@calckey.social, treat it as an
> alias
> * and perhaps my did:key as well, while we are at it.
> etc.
>
> … and all three identifiers, when locally resolved against their
> respective webfinger endpoint, produce the same webfinger file. Or the same
> webfinger++ = DID file if we put the DID in there as well. Now I could
> conduct business all across the place as a single person, using the same
> identifier everywhere. And if you looked up my identifier, you can easily
> choose where and how to interact with me.
>
> Notes:
> * Of course only if I wanted to have those identifiers correlated.
> * This may need a (small) webfinger extension to allow to specify which of
> the aliases to use with a given link element
> * There are some practical problems to be resolved how to keep those files
> consistent. Maybe it would be easiest to have N-1 of them redirect to the
> “primary” one, which is the “editable data” webfinger endpoint.
>
> Again, there is a lot that could be done on this front, but I continue to
> believe that the majority in the survey respondents was right, the most
> interest and focus right now should be
> 1) to work down the issue log and
> 2) improve security and privacy, hopefully in a non-breaking manner.
>
> Cheers,
>
>
>
> Johannes.
>
> Johannes Ernst
> Blog: https://reb00ted.org/
> FediForum: https://fediforum.org/
> Dazzle: https://dazzle.town/
>
>