Add COSE key format example into CBOR section

[jonnycrunch]

At present the CBOR example demos a public key format in text for easy serialization to/from JSON and JSON-LD without the need for cryptographic libraries.

@jonnycrunch TODO:

• Remove JSON-LD idioms from example
• provide an example of COSE Key format with appropriate COSE tags

[jonnycrunch]

Work in progress. PR in the works.

[OR13]

We might want to reserve terms / discuss on key representations call.

[jonnycrunch]

I was waiting to get feedback before submitting PR and to make sure the example is a well formatted COSE with int as keys.

[jonnycrunch]

Having discussed this in more depth, I am understanding the challenges. In essence, in order to express that a verification method has a public key in COSE encoding we will need to either specify an attribute in the DID document or DID spec registries (as @OR13 suggested publicKeyCOSE ? ) and echoing @selfissued who stated in the IETF documents that specifying the COSE key is application specific. Thus as our DID specification is relying on a COSE key format which is not satisfied by a tag and we haven't yet figured out MIME types for the DID doc, so we would need an attribute that the clearly states the values is represented in an CBOR object and specifically COSE key, which doesn't have an IANA tag. In dagCbor (which is where I have been focusing) this is easy and has been explored before by @msporny :

{ ... , 
"verificationMethod" :  { 
    "/": "<base32><cidv1><ed25519-pub-multicodec><ED25519_PUBLIC_KEY_BYTES>
}

I'm not a bit fan of publicKeyMulticodec as the material is more than just multi-codec and includes multi base, but in essence it is a self describing hash-based pointer to cryptographic key material.

[OR13]

"verificationMethod": [
{
"id":"#z6Mkf5rGMoatrSj1f4CyvuHBeXJELe9RPdzo2PKGNCKVtZxP",
"type":"Ed25519VerificationKey2018",
"controller": "did:key:z6Mkf5rGMoatrSj1f4CyvuHBeXJELe9RPdzo2PKGNCKVtZxP",
"publicKeyMulticodec":"z6Mkf5rGMoatrSj1f4CyvuHBeXJELe9RPdzo2PKGNCKVtZxP"
}
]

"verificationMethod": [
{
"id":"#z6Mkf5rGMoatrSj1f4CyvuHBeXJELe9RPdzo2PKGNCKVtZxP",
"type":"Ed25519VerificationKey2018",
"controller": "did:key:z6Mkf5rGMoatrSj1f4CyvuHBeXJELe9RPdzo2PKGNCKVtZxP",
"publicKeyMulticodec":"<base58><ed25519-pub-multicodec><ED25519_PUBLIC_KEY_BYTES"
}
]

I think you need to define a new publicKey type...

publicKeyIpld: <base32><cidv1><ed25519-pub-multicodec><ED25519_PUBLIC_KEY_BYTES>

@jonnycrunch

Then we would still need to address the other meta data expressed by a verificationMethod... including controller, type and id.

[jonnycrunch]

@OR13, yes. I had started a publicKeyMultiformat.cddl format, but this is blocked until we have resolution regarding other key formats and accepting CDDL to aid in the representations. I'm also on the fence about whether to allow for inline CIDs.

something like for linked items:

publicKeyMultiformat = {
"verificationMethod": [  {
      "id" : did-url
    "type" : VerificationMethodTypes
    "controller" : did 
      "publicKeyMulticodec": #6.42(bstr)
  } ]
}

This will work fine for cbor, but not for JSON.
In line is much harder as I want to unambiguously represent all of the multicodecs and I'm still learning cddl.

perhaps the follow is a compromise and works for both dagCBOR, CBOR and JSON but I think I can do better:

publicKeyMultiformat = {
"verificationMethod": [  {
    "id" : did-url
    "type" : VerificationMethodTypes
    "controller" : did 
     "publicKeyMulticodec": #6.42(bstr) / linkedCID / inlineCID 
  } ]
}

linkedCID = {
    "/" : text              ; ideally this should be more constrained  
}

inlineCID = text      ; ideally this should be more constrained  

technically, this will work for both JSON, CBOR and dagCBOR and is the direction I am attempting in the DID core CBOR section, but alas ... politics

[OR13]

hmm, I can see the value of publicKeyMulticodec as a CID... but its also a DOS vector... one of my favorite ways to attack IPFS systems is to hand them valid but unresolvable CIDS....

I would prefer to split that case, so the that field is always by value , and some other field is by reference.... both have their uses.... I can imagine some CBOR DID Methods might choose to only support 1 or the other.

[OR13]

Propose closing this and not adding support for CWK this round.

[msporny]

The group discussed this issue on 2021-01-12 and suggested that the added complexity may not be worth it and has also suggested that the issue should be closed.

This issue will be closed in 7 days unless there are objections.

[brentzundel]

No objections raised, closing issue