Decide on a general procura field

[moa]

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.

Precision in definition specification is precisely what you were requesting .... do it how you like of course.

[phelix]

The "signer" address(es) shall be used for signing like the address holding a name.

Priority:
highest: name holding address
signer[0]
signer[1]
signer[2]
...

Code: Select all

{"signer":["N15mJsVMHNtVDedDnD8vu82M5hCfn3nJWq"]}

or

Code: Select all

{"signer":["N15mJsVMHNtVDedDnD8vu82M5hCfn3nJWq","N2pGWAh65TWpWmEFrFssRQkQubbczJSKi9"]}

[domob]

The "signer" address(es) shall be used for signing like the address holding a name.

Priority:
highest: name holding address
signer[0]
signer[1]
signer[2]
...

I think we should clarify that "signing like the address holding a name" does not mean it is allowed to sign namecoin transactions on behalf of that name, but instead this is only the case for certain high-level applications (like file verification and NameID once I implement it) which explicitely claim themselves they want to support "signer". Furthermore, what exactly is the significance of the priority ordering? While it makes sense intuitively, I fail to see a situation where it would matter. Do you have a particular example in mind?

Code: Select all

{"signer":["N15mJsVMHNtVDedDnD8vu82M5hCfn3nJWq"]}

or

Code: Select all

{"signer":["N15mJsVMHNtVDedDnD8vu82M5hCfn3nJWq","N2pGWAh65TWpWmEFrFssRQkQubbczJSKi9"]}

Sounds good. What about allowing the first one to be just a single string instead of an array, like

Code: Select all

{"signer":"N15mJsVMHNtVDedDnD8vu82M5hCfn3nJWq"}

? I think this makes sense and is not too hard to implement from an applications point of view. (For OTR fingerprints I currently support both versions in my experimental work there.)

[phelix]

The "signer" address(es) shall be used for signing like the address holding a name.

Priority:
highest: name holding address
signer[0]
signer[1]
signer[2]
...

I think we should clarify that "signing like the address holding a name" does not mean it is allowed to sign namecoin transactions on behalf of that name, but instead this is only the case for certain high-level applications (like file verification and NameID once I implement it) which explicitely claim themselves they want to support "signer".

feel free to work out a nice and short wording

Furthermore, what exactly is the significance of the priority ordering? While it makes sense intuitively, I fail to see a situation where it would matter. Do you have a particular example in mind?

Nah, I just got the idea and thought I would write it down in case a conflict should arise. It is pretty clear though that the holding address has highest priority as it "can change the others".

Code: Select all

{"signer":["N15mJsVMHNtVDedDnD8vu82M5hCfn3nJWq"]}

or

Code: Select all

{"signer":["N15mJsVMHNtVDedDnD8vu82M5hCfn3nJWq","N2pGWAh65TWpWmEFrFssRQkQubbczJSKi9"]}

Sounds good. What about allowing the first one to be just a single string instead of an array, like

Code: Select all

{"signer":"N15mJsVMHNtVDedDnD8vu82M5hCfn3nJWq"}

? I think this makes sense and is not too hard to implement from an applications point of view. (For OTR fingerprints I currently support both versions in my experimental work there.)

I don't mind. I thought about it, too, but was feeling generous on blockchain characters. Most of the time it will only be one signer address I guess...

Code: Select all

The "signer" address(es) shall be used in high level applications (in contrast to regular namecoin transactions) for signing interchangeably to the address holding the name.

Code: Select all

{"signer":"N15mJsVMHNtVDedDnD8vu82M5hCfn3nJWq"}

or

Code: Select all

{"signer":["N15mJsVMHNtVDedDnD8vu82M5hCfn3nJWq","N2pGWAh65TWpWmEFrFssRQkQubbczJSKi9"]}

[biolizard89]

Am I correct in assuming that functionality like multi-factor authentication (e.g. require 2 keys to sign a NameID message) should be handled by multisig addresses (with a single multisig address listed in the "signer" field), not by listing multiple non-multisig addresses in the "signer" field? Anyone know if a multisig address in Bitcoin can sign messages like standard addresses can?

Has "signer" been implemented in NameID or any other implementations? If I possessed an important id/ name, I would be concerned about unlocking my wallet every time I wanted to login to a website.

[domob]

Has "signer" been implemented in NameID or any other implementations? If I possessed an important id/ name, I would be concerned about unlocking my wallet every time I wanted to login to a website.

No, not yet, but it is on my list of things to do next. (Actually it even was before this feature was discussed here, since I agree with you that it is very good to keep important names safe while you may want to log in from not so secure computers / unlock the wallet often.) I hope that it will be done in the next weeks or at the very latest a few months, depending on how much time I find for it.

[virtual_master]

- 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.

Yes. That's correct.
I didn't want to stop anybody to implement a new feature just asked if you are convinced if it is necessary.
Sure. If somebody will need it in the future it will be there.
Thanks.