A place for service providers (i.e. OneName)

Post Reply
indolering
Posts: 801
Joined: Sun Aug 18, 2013 8:26 pm
os: mac

A place for service providers (i.e. OneName)

Post by indolering »

So, I was thinking about the problem we are having with OneName providing another identity service on the blockchain under a legacy namespace. We all agree that duplicate namespaces are a serious problem, but resolving the current situation is tricky. However, I think I've figured out a solution to resolving the duplicate namespace issue AND how to reconcile the role these registrars play.

The primary criticism of name registrars (such as OneName) is that they basically control the entire identity process, although ZK can enable some degree of autonomy and the registrar can hand over the private keys. On the other hand, the vast majority of individuals and businesses do not want to be responsible for their private keys.

So, what if we just allowed registrars to control the creation of sub names, such as id/service-provider/user? We can give the child names varying degrees of autonomy, we could even specify those levels in the id/service-provider name record. Users can chose their service provider if they want one or register an id/name directly.

OneName could transplant their users under u/name to id/onename/name. For id/, this would give a natural reverse mapping of name@service-provider.id.bit.

This would also take care of the cost issue, in that we all agree there should be different costs and renewal periods for id/name than for d/name. We could, for example, reserve id/names for 10 years and charge $100 for them while charging the minimum network fee for child names.
DNS is much more than a key->value datastore.

indolering
Posts: 801
Joined: Sun Aug 18, 2013 8:26 pm
os: mac

Re: A place for service providers (i.e. OneName)

Post by indolering »

Note that this would also be a more secure replacement of the practice of setting up an import. For example, in d/ it is recommended that users setup a record under dd/name and import this record from d/name, enabling users to store d/name in cold storage.

Using d/name/import would be more secure since d/name/import requires the permission of d/name and an attacker cannot take advantage of someone forgetting to renew dd/name. However, the security argument is more relevant to id/name since it is likely that we will want multi-year registration for names under id/.
DNS is much more than a key->value datastore.

Post Reply