Re: Secp256k1 key types standardizations

The other problem is the naming inconsistency. From the other 2 key ids in
the registry, (below) and from DID hardening discussions around key
"purpose". I'd expected the ids to follow a pattern, e.g.
<curve-specific><purpose>Key<date>.

To clarify, I thought we decided that an entry in this registry would map
to a specific combination of JWK parameters to help avoid the problem of
algorithmic agility. (However, I did miss many of the later DID
hardening calls.)

Given that the registry is brand new, I'd think we could impose this
consistency before things get out of control. Or is that not possible or
necessary in this case?

   - Ed25519*VerificationKey2018*
   - Rsa*VerificationKey2018*
   - EdDsaSAPublicKeySecp256k1

Either way, it's irritating to look at :)

On Wed, Mar 28, 2018 at 11:59 AM Mike Lodder <mike.lodder@evernym.com>
wrote:

> EdDsaSAPublicKeySecp256k1 is incorrect. EdDsa is only possible with
> Twisted Edward curves. This should be ECDSAPublicKeySecp256k1.
>
> On Wed, Mar 28, 2018 at 12:48 PM, Kim Hamilton Duffy <
> kim@learningmachine.com> wrote:
>
>> We may have a naming issue in the current LD Cryptosuite Registry; note
>> that we have a secp256k1key, but its identifier (EdDsaSAPublicKeySecp256k1)
>> isn't consistent with the others in terms of specifying purpose.
>>
>> For context, here's the list of key identifiers currently in the registry
>> (https://w3c-ccg.github.io/ld-cryptosuite-registry/):
>>
>>    - Ed25519VerificationKey2018
>>    - RsaVerificationKey2018
>>    - EdDsaSAPublicKeySecp256k1 <<<
>>
>> Example for EdDsaSAPublicKeySecp256k1 in the registry:
>>
>> {
>>   "id": "did:example:123456789abcdefghi#keys-1",
>>   "type": "EdDsaSAPublicKeySecp256k1",
>>   "owner": "did:example:123456789abcdefghi",
>>   "publicKeyHex": "02b97c30de767f084ce3080168ee293053ba33b235d7116a3263d29f1450936b71"
>> }
>>
>> The DID spec uses the type name you mentioned
>> (Secp256k1VerificationKey2018) in the same context of a publicKey
>>
>>  {
>>     "id": "did:example:123456789abcdefghi#keys-3",
>>     "type": "Secp256k1VerificationKey2018",
>>     "owner": "did:example:123456789abcdefghi",
>>     "publicKeyHex": "02b97c30de767f084ce3080168ee293053ba33b235d7116a3263d29f1450936b71"
>>   }]
>>
>> Should we rename the identifier in the registry? Or does this have some
>> purpose I'm missing
>>
>> On Wed, Mar 28, 2018 at 10:46 AM Pelle Braendgaard <
>> pelle.braendgaard@consensys.net> wrote:
>>
>>> Hello guys,
>>> I've lost count of all the variations of the secp256k1 key types I've
>>> seen. The latest in the DID spec is:
>>>
>>> "Secp256k1VerificationKey2018"
>>>
>>> Can we stick with that for now. I know we need to register it here
>>> https://w3c-ccg.github.io/ld-cryptosuite-registry/ but not quite sure
>>> of the process for that.
>>>
>>> For authentication I would like to use the following type copying from
>>> the conventions for RSA:
>>>
>>> "Secp256k1SignatureAuthentication2018"
>>>
>>> Regards
>>>
>>> Pelle
>>>
>>> --
>>> *Pelle Brændgaard // uPort Engineering Lead*
>>> pelle.braendgaard@consensys.net
>>> 49 Bogart St, Suite 22, Brooklyn NY 11206
>>> <https://maps.google.com/?q=49+Bogart+St,+Suite+22,+Brooklyn+NY+11206&entry=gmail&source=g>
>>> Web <https://consensys.net/> | Twitter <https://twitter.com/ConsenSys>
>>> | Facebook <https://www.facebook.com/consensussystems> | Linkedin
>>> <https://www.linkedin.com/company/consensus-systems-consensys-> |
>>> Newsletter
>>> <http://consensys.us11.list-manage.com/subscribe?u=947c9b18fc27e0b00fc2ad055&id=257df01285&utm_content=buffer1ce12&utm_medium=social&utm_source=facebook.com&utm_campaign=buffer>
>>>
>> --
>> Kim Hamilton Duffy
>> CTO & Principal Architect Learning Machine
>> Co-chair W3C Credentials Community Group
>> 400 Main Street Building E19-732, Cambridge, MA 02139
>> <https://maps.google.com/?q=732,+Cambridge,+MA+02139&entry=gmail&source=g>
>>
>> kim@learningmachine.com | kimhd@mit.edu
>> 425-652-0150 <(425)%20652-0150> | LearningMachine.com
>>
>
>
>
> --
> Mike Lodder
> Senior Crypto Engineer
>
>
> --
Kim Hamilton Duffy
CTO & Principal Architect Learning Machine
Co-chair W3C Credentials Community Group
400 Main Street Building E19-732, Cambridge, MA 02139

kim@learningmachine.com | kimhd@mit.edu
425-652-0150 | LearningMachine.com