A place for service providers (i.e. OneName)
Posted: Tue Jan 20, 2015 1:27 am
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.
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.