Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
Daniel-Abrecht opened this issue Oct 5, 2018 · 11 comments

Comments

Projects
None yet
9 participants
@Daniel-Abrecht
Copy link

commented Oct 5, 2018

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?

@RubenVerborgh

This comment has been minimized.

Copy link
Member

commented Oct 5, 2018

As it is now, WebIDs are always URLs.

The important thing about WebIDs is that they are URLs—but, crucially, this does not mean HTTP URLs.

When I say "URL", I mean that a WebID must be an unambiguous identifier (so the "URI" part of it), and it must be dereferenceable (the "L" part of "URL").

The majority of Solid components just rely on those two properties, and there are many other URLs besides HTTP URLs that satisfy these properties (IPFS and dat URLs, to name a few). You will have no problem using these. All you need to do is implement the corresponding resolvers (some browsers do this for you) and it will just work.

@melvincarvalho

This comment has been minimized.

Copy link
Contributor

commented Oct 5, 2018

@Daniel-Abrecht good thoughts. Solid itself operates on the principles of URIs denoting identity. So anything that does that is fine with solid, technically. WebID is basically branding for the HTTP flavour.

Each scheme has pros and cons. Http means you can dereference it and get machine readable data. Disadvantage is that the linkage may break or be owned.

Content addressable URIs such as ipfs require a infrastructure for lookup, but are long lasting.

Namecoin has a distributed model, but it comes at a price.

We could ask ICANN to reserve for us .solid domains (I'd like that!) but the question is always how is it managed, and how you prevent squatters and sock puppets.

There are trade offs with each approach, but with solid they can all play nicely in one eco system.

@Daniel-Abrecht

This comment has been minimized.

Copy link
Author

commented Oct 5, 2018

Does only the browser have to be able to resolve the URIs? Either way, the URIs that are supported by the most commonly used browsers are very limited, which means that, unless I fundamentally misunderstand something about solid, either who can access my data easily or which application can access it would be very limited if I used anything but a http url.

I'll take a look at IPFS/IPNS and similar things to see if I can implement the resolution of URIs for any of these things in a decentralized manner in current mainstream browsers, or if there already is such a thing, but it may take a while until I get to that. If I find one, maybe it could be added to solid or I may continue my https://github.com/Daniel-Abrecht/protocolloadfallbackhandler project to increase the availability of usable URI schemes on the web. But I won't get to this any time soon.

@melvincarvalho

This comment has been minimized.

Copy link
Contributor

commented Oct 5, 2018

The URIs are independent of the browser. But there are different network effects.

As an extreme example, a URI could be written on a napkin and used by two people. On the other hand it could be used in the browser and have an audience of billions.

Or you can make your own browser (like the safe network has) and use it with a growing community.

It really depends on your use case.

@Daniel-Abrecht

This comment has been minimized.

Copy link
Author

commented Oct 6, 2018

I'm not entirely sure I understand what you are trying to tell me.

The URIs to the resources may be used by any program. But not every program will support every URI scheme. If I want things to be accessible to everyone, and assuming not every developer uses the same implementation to access solid pods, I can't ensure everyone can access the resources with every program if I don't use a URI scheme as widely supported as http. Is that the point?

It seams using http for URIs is the only viable solution to not exclude anyone or anything who may want to access any of my resources, since getting any other protocol/URI schema as widely supported probably won't be possible.

So that would only leave extending the DNS infrastructure as an option, except if the URI schemes that should be supported at a minimum won't get specified, for which figuring out which ones that are would be necessary first.

@kjetilk

This comment has been minimized.

Copy link
Contributor

commented Oct 22, 2018

for further discussion of .solid, see #201

@elf-pavlik

This comment has been minimized.

Copy link
Member

commented Oct 30, 2018

you might find this effort relevant https://w3c-ccg.github.io/did-spec/

Decentralized Identifiers (DIDs) are a new type of identifier for verifiable, "self-sovereign" digital identity. DIDs are fully under the control of the DID subject, independent from any centralized registry, identity provider, or certificate authority. DIDs are URLs that relate a DID subject to means for trustable interactions with that subject. DIDs resolve to DID Documents — simple documents that describe how to use that specific DID. Each DID Document contains at least three things: cryptographic material, authentication suites, and service endpoints. Cryptographic material combined with authentication suites provide a set of mechanisms to authenticate as the DID subject (e.g., public keys, pseudonymous biometric protocols, etc.). Service endpoints enable trusted interactions with the DID subject.

links to other relevant references: https://github.com/w3c-ccg/community/blob/master/work_items.md

@dmitrizagidulin

This comment has been minimized.

Copy link
Member

commented Oct 30, 2018

@elf-pavlik I see DIDs as basically a next generation of WebIDs. Definitely backwards-compatible, with only a little bit of effort. And with scope widened to not just HTTP, but also various blockchains/DLTs.

@Mitzi-Laszlo

This comment has been minimized.

Copy link
Contributor

commented Nov 6, 2018

@EGreg

This comment has been minimized.

Copy link

commented Nov 6, 2018

Agreed, DIDs seem like a generalization of WebIDs, as long as they are backwards-compatible it would make sense to incorporate DID standard.

Which projects are using DIDs at the moment?

@justinwb

This comment has been minimized.

Copy link

commented Nov 6, 2018

Closing this as a github issue - please track through the discourse discussion above moving forward.

@justinwb justinwb closed this Nov 6, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.