Dave Longley

There are a number of reasons for this that should be better explained in the Linked Data Proof specification(s) that OCAP-LD builds on. Some of those reasons include the underlying...

@David-Chadwick, the point of this is: What technology must you add if you want to get certain features? It makes sense to choose the simplest technology that provides all the...

@mprorock, > big fan of this - would simplify things and improve security For the use cases that have no need of an integrated key agreement key and for those...

To be clear on my position here: If the use cases just aren't there for key agreement keys for ed25519 `did:key` DIDs, then removing `keyAgreement` makes sense -- provided that...

A use case that needs to be considered here (and whether or not `did:key` will be an acceptable DID method for it) is: You are required to use a single...

Another option to consider, would be to register another public key type in the multicodec table that means: "an ed25519 public key that can be transformed using a birational map...

@OR13, > No, because we are not using Ed25519 for keyAgreement today, we are converting to X25519 and then using that key... > > You can't have it both ways......

@OR13, > Ed25519 should be allowed for keyAgreement IF and ONLY IF, it's possible to use it for that purpose. > > NEW_KEY_TYPE should be allowed for PURPOSE IF and...

@OR13, Hmm, we may end up needing to support both approaches but perhaps we should only start out with the first one. We should probably use a different multicodec value...

Note: > The double SHA-256 checksum is slow and has no error-detection guarantees. Most of the research on error-detecting codes only applies to character-set sizes that are a prime power,...