domob wrote:
[...]
What about a "general purpose" specification to include "signature keys" (most likely namecoin addresses) in name values, which are allowed to sign on behalf of the name for all kinds of applications (file verification and login being the ones I have in mind so far)? In the simplest case, it would be enough to have a "signer" or "authorized" or whatever field in the name which contains an array of or just a single namecoin address. For the future, it could even be extended to allow signing with GPG keys or so if that should ever be desired.
As you mention, this would prevent problems with name_update changing the address. But it would also allow me to keep my name's "master key" in protected storage while having a throw-away signer address in my working wallet in order to use NameID. Thus I can use the signing feature day-to-day without worrying about losing my name's private key.
It could be my lack of skill of the english language but I am unsure about "signer" - my dictionary seems to indicate it is a rare word used in mainly in law.
domob wrote:
[...]
What about a "general purpose" specification to include "signature keys" (most likely namecoin addresses) in name values, which are allowed to sign on behalf of the name for all kinds of applications (file verification and login being the ones I have in mind so far)? In the simplest case, it would be enough to have a "signer" or "authorized" or whatever field in the name which contains an array of or just a single namecoin address. For the future, it could even be extended to allow signing with GPG keys or so if that should ever be desired.
As you mention, this would prevent problems with name_update changing the address. But it would also allow me to keep my name's "master key" in protected storage while having a throw-away signer address in my working wallet in order to use NameID. Thus I can use the signing feature day-to-day without worrying about losing my name's private key.
It could be my lack of skill of the english language but I am unsure about "signer" - my dictionary seems to indicate it is a rare word used in mainly in law.
"signer" sounds good to me. It's not an extremely common word in English, but I wouldn't call it rare -- I think most English speakers would know what it means. "procura" is rare though -- in honesty I hadn't heard the word until now.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy DyName: Dynamic DNS update client for .bit domains.
Interesting concept to have a master key for Namecoin domains. Did I understood correctly ?
How exactly should it work ?
--------
What name to give for it ? Doesn't matter to much for me since I have learned English as 6. language.
virtual_master wrote:Interesting concept to have a master key for Namecoin domains. Did I understood correctly ?
How exactly should it work ?
--------
What name to give for it ? Doesn't matter to much for me since I have learned English as 6. language.
It can work like a two factor auth for names by signing one names value by another name. By not using the address holding the name but by putting it into the value you gain some security and flexibility.
Signatory is nice but too long. Let's just go with "signer" as per domob's original suggestion and biolizards advice. As domob said it can be a single address or a list of addresses.
Note: The purpose of the signer field is quite different from addresses that are used to receive coins so I think it makes sense to create an extra field.
nx.bit - some namecoin stats nf.bit - shortcut to this forum
I think "endorser" is the closest legally equivalent role ... since you are effectively transferring signing authority (proof of ownership) to a different signer (priv key).
Just two more notes:
- signer is short and more understandable for non English experts also
- are you sure that we need this ? May be we can make a voting on bitcointalk.org to see if it is needed or not.
If we implement such a feature then we should be sure it is needed and it should be cost efficient. If there will be 100 uses/year and each costs 0.02 namecoins then for 2 namecoins it is not economic and would only confuse the others(who don't use it).
virtual_master wrote:Just two more notes:
- signer is short and more understandable for non English experts also
- are you sure that we need this ? May be we can make a voting on bitcointalk.org to see if it is needed or not.
If we implement such a feature then we should be sure it is needed and it should be cost efficient. If there will be 100 uses/year and each costs 0.02 namecoins then for 2 namecoins it is not economic and would only confuse the others(who don't use it).
I vote for "signer". Not sure I understand your second concern - it is not something that will change the "base" namecoin protocol. The "signer" field is not meant to sign namecoin transactions for instance. It is only used by certain high-level protocols built on top of namecoin, like the file verification or NameID login. This field specifies addresses that are allowed to sign files or login challenges on behalf of the name's owner, until this permission is revoked by him/her. They are not allowed to take over the name, since this is precisely their purpose - allow one to keep the name's real key in cold storage (or at least somewhere more protected) while the signer keys can be on machines like my work computer to just allow me to sign into NameID without the risk to lose my name. Kind of like a certificate authority system, where the name's key is the root authority and the signer names are child certificates which are allowed only to perform certain restricted tasks.
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/
virtual_master wrote:- are you sure that we need this ? May be we can make a voting on bitcointalk.org to see if it is needed or not.
If we implement such a feature then we should be sure it is needed and it should be cost efficient. If there will be 100 uses/year and each costs 0.02 namecoins then for 2 namecoins it is not economic and would only confuse the others(who don't use it).
Like domob I don't understand this concern. Namecoin is generic name/value storage; no one is required to use certain fields. It is beneficial to have a specification for such things because the people who do have a use for it will not have to design it separately for different use cases, and will be able to interoperate with each other. Not everyone uses the import field right now either, but as I posted in another thread, it's useful for cold storage purposes. When people have ideas for Namecoin use cases, they shouldn't have to get approval for the use case existing; they should just start writing a specification and get feedback to make the spec as good as possible.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy DyName: Dynamic DNS update client for .bit domains.
moa wrote:I think "endorser" is the closest legally equivalent role ... since you are effectively transferring signing authority (proof of ownership) to a different signer (priv key).
Though this is more precise it is also harder to understand, especially for non native English speakers. If there are no strong arguments I suggest we stick to "signer", it seems the majority is at least ok with it.
nx.bit - some namecoin stats nf.bit - shortcut to this forum