Any plans to make WebIDs independent of service providers / prevent vendor domain lockin?

@Daniel-Albrecht wrote:

As it is now, WebIDs are always URLs. While people like me have own domains, unfortunately, most of people don’t. They will get a WebID from an existing provider, but then they’re locked in to that provider, because switching it means switching the WebID. It’s like with email addresses, nobody wants to change them, because they would have to tell everyone.

Are there any plans for distributed WebIDs, over which no single entity has control? And if so, how could this look like?

I’m asking mostly out of curiosity, because I think solid and its decentralization of data storage for user data is an important step forward in combating online provider lock-in, but I likely won’t have time to contribute much. But I can give some ideas.

I think the biggest challenge for creating distributed WebIDs would be to make it usable with current browser accessible technologies. I see 2 possible solutions to this:

  • One is to extend the DNS infrastructure. There are two variations of that possibility:
    • If some of the well known existing internet authorities such as icann would provide free domains on a new TLD for people only, with an API to register them automatically, it would allow everyone to get their own domain without any effort. But it would place control over the domains in the hands of said authorities, which may not necessarily be much better.
    • If we do the same as above, but instead of letting the authorities maintain the records for said TLDs themselves, the DNS servers are instances of a blockchain client, like with namecoin, then not only would nobody be in control of the domains, if the authorities choose to stop the service, the browsers could use their own namecoin or similar instances to resolve the domains instead. The problem in that case is that blockchains usually need blocks to have value to keep miners and stay secure, which means domains have a cost and thus the same problem regular domains have regarding accessibility, and blockchains like namecoin don’t save domains forever, in addition to taking a lot of space.In addition to the problems of both approaches, I doubt that icann and co. would be interested in providing such a free service.
  • A URN could be used for WebIDs, which are resolved using trackers, similar to how WebTorrents and magnet URIs work. The main issue with this approach is to find a way to not relay on a fixed set of trackers, to check that they are synced, automatically update the used trackers, keep track of which ones are not malicious, and validate that the WebID information are correct (using a hash as webid wouldn’t be user friendly, so the webtorrent approach to this wouldn’t work.). I believe this to be solvable problems, but very difficult ones.

A combination of the above could also be possible.

Of course, it could be way easier to create standards for protocols which can handle the lookup of URLs based on an URN without needing any hashs but just a resource name/type without a central registry/authority, and if browsers would then implement those, but I don’t know how something like that would look like or if there are any.

What do you all think, where and how could or should this be solved? Is this even the right place to resolve the problem, or should it be discussed/solved somewhere else?

There has been some discussion on https://github.com/solid/solid/issues/195 with @RubenVerborgh, @melvincarvalho, @Kjetilk, and @elf-pavlik and would like to invite more here.

2 Likes

There are already decentralised WebIDs on the SAFE Network, you can get an idea from this brief explanation of how to create them: Creating your WebID on the SAFE Network (Alpha-2) - Apps - Safe Network Forum

I think a (read-only) proxy can be created to support fetching WebIDs from safe:// protocol. The WebIDs from the SAFE Network can be fetched in Turtle, JSON-LD, and other formats, so from my understanding using Turtle would allow them to be compatible with Solid.

4 Likes

As mentioned in the Github issue, DIDs might help solve to solve the decentralized URL creation aspect of this problem.

However, we still need some solution for moving / changing your WebID.

The owl:sameAs prop could also be used to point to other WebIDs.

Another solution is to send a HTTP 301 Permanent Redirect pointing to the new WebID, and make sure that the client Solid Pod updates all IRIs. This might be the cleanest solution, since it does not just help with changing WebIDs, but with all kinds of resources. This would require some extra logic in Solid pods, though, and being able to remotely rewrite IRIs might create some security risks.

Perhaps some form of WebIDChangedNotice can be sent to friend pods as well.

1 Like

Maybe something to bring up on https://github.com/solid/process/blob/master/panels.md#identity-panel

1 Like

The solutions of owl:sameAs and 301 are feasible only if

  1. The providers themselves are still available. Otherwise it’s always 404.
  2. The user had a happy ending with the providers. The provider may not allow the user to keep the redirection in their realm if the service is ended because of censorship or arrears.

For WebIDChangedNotice, how can we ensure all PODs with the reference to this IRI get notified? As such references may get propagated without the owner’s awareness.

2 Likes