A Cryptographic Golem has been created

[jonnycrunch]

I have major concerns regarding the direction of this did spec registries and how there is an expectation that someone will create the CBOR equivalent of what is in essence new cryptographic methods and/or key types that have just been declared like some sort of cryptographic golem. To be clear this started by importing outside cryptographic vocabularies from w3id.org into the group without completely understanding the consequences.

• In invoking this cryptographic golem represents either a new cryptographic method or defines a novel approaches to cryptography that I don't believe is in our charter.

• CBOR and COSE are robust and well documented approaches to cryptography that is well beyond the skill of most developers or contributors to what is in essence a shared data model that should leverage existing web standards whenever possible.

Certain entries in this registry seem harmless at first blush. Defining reserved names for this registry such as publickeyHex and publicKeyPem seem like just formating syntaxes to carry over legacy systems and for human readiblity. However, there is no 1:1 mapping of a CBOR or COSE serialization of this PEM ASCII representation. The closest would be the native binary format of exported public key from pgp which would be Radix-64 encoded data with use of headers as in asc exported public keys.

Whole cryptographic libraries are used for these data transformations to consume Base64 encoded DER certificate (PEM encoding), translate and validate it and then export it into different formats, such as COSE key format.

Other entries, such as PublicKeyJwk, JwsVerificationKey2020, publicKeyJwk are very much JSON and JWK specific and it would not be fair to say that there must be a 1:1 mapped CBOR/COSE equivalent ... again there are whole libraries to convert the cryptographic key material from JWK to COSE Key format.

Next, ethereumAddress is a generalized concept that really represents an abstract pointer on a non-specific distributed ledger. This doesn't tell me which flavor of ethereum (Besu, main Ethereum, Ethereum Classic). Again, this is attempting to invoke a novel cryptographic key recovery mechanism just by giving it a name in the registry.

Finally, other items (capabilityInvocation and capabilityDelegation) are really advanced, are method specific, or invoke object capabilities thru some utterances by Mark Miller. IMO these would be best suited from a verifiable credential as discussed at RWoT5 with Mark rather than appear in this registry. I am open to these, but could we just start with simple desiderata for now? ... like controller, publicKey, proof and service before moving on to something so complex.

All of this is an undue burden to ask that I MUST contribute the equivalent CBOR mappings or my CBOR core representation to the DID spec is at risk. I can only conclude that this tactic is trying to subvert legitimate implementations from competing with a more elegantly simple approach that uses existing and hardened standards.

I also agree with @selfissued that this entire registry needs the "Expert Review Required" registration procedure similar to IETF's Section 16.11 and probably more importantly rather then invoke this cryptographic golem, that we should defer to IETF where the security considerations should be addressed and not try to create them here.

[OR13]

@jonnycrunch As is, this is inviting a lot of discussion...touching many topics all at once, many of which we have had discussion for months on various issues and special topic calls.

I agree that the registration burden can be a tactic to prevent registration of properties... and in fact, thats exactly why I suggested removing the requirement to register anything by JSON-LD and HTML, and have CBOR and JSON just use those...

Anything more than that, will be more work, and given the current rate of contribution, I see this much as you do, as increasing the probability that JSON and CBOR won't make the cut, because people who care about those representations would be required to reinvent the entire JSON-LD vocabulary... instead of just using it and html.

I'd prefer to see these points raised as separate, focused issues, where we can discuss them in isolation and work towards consensus that could be implemented in clean focused PRs.

I will attempt to pull out the high level concepts, if you think I have gotten them, I would ask that you open issues for each of them, cross link to here, and close this.

1. The registry needs and Expert Review Required section.
2. The registry needs to reduce the burden for registering JSON / CBOR equivalence with JSON-LD (how?).
3. The registry needs to do a better job of describing capabilityInvocation and capabilityDelegation.
4. The registry needs to point to a reputable source for CBOR representations (https://tools.ietf.org/html/rfc7049 ?)
5. How will we handle key representation conversion for keys that are representation specific? (JWK / CWK)

Did i miss anything major? can you open separate issues / link here and close this?

[OR13]

@jonnycrunch we might want to open another issue in did core, to track what is remaining (some of the stuff in this text block has since been resolved, like ethereumAddress)..... also... sadly, very few people review these issues... we might have better luck getting feedback just moving this to did core.

[OR13]

@jonnycrunch I will close this in a few days without objection... I agree with your concerns, but we need to split them up and get the WG to review them independently.