Page 1 of 1

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

Posted: Tue Jan 20, 2015 1:27 am
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.

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

Posted: Tue Jan 20, 2015 5:19 pm
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/.