[Feature Request] Looser verificationKey material restrictions

[iFergal]

It makes sense to restrict the controller keys (MASTER_KEY and maybe REVOCATION_KEY) to simplify signature checks for DID document updates on the Atala nodes.

But restricting all verificationMethods might reduce interoperability. For example, DIDComm key exchange using keyAgreement type P-256 may be required for some interaction instead of X25519, or maybe some FIPS compliance.

Multibase encoding would also be nice instead of just JWK, and probably easy to support.

[EzequielPostan]

thank you for the comment :) It is in the plans, as mentioned in the spec

In future versions, more verification method types and keys will be supported.

we started with a smaller subset and a particular encoding, but it can be extended

[iFergal]

Indeed, I did see that in the spec! My thoughts here though is that any verificationMethod that is not MASTER_KEY or REVOCATION_KEY should not be bound by the spec at all (/extended via updates), and fully at the discretion of the user.

So while MASTER_KEY is limited to secp256k1 and Ed25519 right now, and can be extended in the future - as this is what each Atala node needs to understand; that other verificationMethod types needn't be restricted at all (aside from general formatting).

To me this makes sense, if the DID controller adds key types that aren't interoperable it's their fault, or they may have a specific party they interact with that requires such types. This seems to be the case in Sidetree (at least on nodes I've tested against) which has similarities to this spec.

But if there's a good reason to not allow free-reign verificationMethod types I would love to understand! :)

[BS-IO]

I think it's a thin needle to thread, balancing flexibility of implementation vs expected interoperability based on the spec. You could end up in a situation where the same did-method might not have interoperable verificationMethods.

Now that might be good for flexibility and increasing the usefulness of the implementation, but it could come at the cost interop. Imho, some constraints could be enabling as they set clear expectations and could help drive adoption.

[rodolfomiranda]

Adding more Crypto Suit types should be trivial and can be extended easily if needed, but need to define each in the spec. Note that JsonWebKey2020 allows all JOSE crypto primitives in just one Suite, including P-256 , see here, so it seems that only a reference in the spec is needed.

[iFergal]

@BS-IO That's a good point! Having focus is for sure important and we should hopefully drive for every did-method to use as much in common as possible.

Just wondering though, if Atala SDKs (and likely any made by the community) simply point to secp256k1/Ed25519/X25519 by default with strong recommendations use these for interop reasons - everyone would just use them. But that could still allow a user to add e.g. P-256 if it was required for their particular use-case.

For example, I think X25519 isn't FIPS-compliant (but is on the roadmap to be, or maybe already is by now - just an example anyway) so an industrial IoT factory may want to only use P-256 (for all devices, so they will be interoperable with each other too). And a DID can have a verificationMethod for both X25519, and P-256 if it really requires it.

Just thinking out loud. :)

@rodolfomiranda - yes, but the spec itself restricts the curve used.

[BS-IO]

@iFergal there's definitely power in defaults. I like the example of FIPS/NIST compliance you raise as we are taking those types of things into consideration. Maybe we could explore 'recommended defaults for categories of use-cases'?

[rodolfomiranda]

Fergal, that's a good option at least to easily extend to the curves defied in jose-conformance section of JsonWebKey2020. @EzequielPostan what do you think?

[iFergal]

Indeed, the jose-conformance would likely cover a lot of use cases!

@BS-IO Sounds look a good idea! It's difficult to predict every use case, but FIPS/NIST compliance (for "mission-critical" use cases) and wherever the DID space is going in general is a good starting point. (I just happened to have the FIPS IoT one on hand from recent research :))

[EzequielPostan]

Fergal, that's a good option at least to easily extend to the curves defied in jose-conformance section of JsonWebKey2020. @EzequielPostan what do you think?

apologies for the delay Yes, a priori, the support is not hard to add. Note that most EC types of keys can be added fairly easily by defining the encoding in our protobuf models (either the compressed or uncompressed versions)

With respect to adding even more general types of verification methods, there are trade offs on implementation. For example, the more generic the model, the harder to compress it in a compact way, which is a topic to consider given that we are storing events on-chain In any case, as use cases reveal the need for more types we can examine how to add them; I like the suggestion from @BS-IO to have a list so we can make use cases and required keys more visible

[iFergal]

@EzequielPostan On that note, have there been any considerations given to not compress the key material directly but rather compress the entire metadata as a whole?

Overall EC should be a good place to start with. I'm sure plenty (often legacy) systems use RSA but right now not sure on the use cases that wouldn't allow them to migrate to EC.

[EzequielPostan]

@EzequielPostan On that note, have there been any considerations given to not compress the key material directly but rather compress the entire metadata as a whole?

protobuf helps on this, and we could exploit it a bit more. For instance, curve names could be an enum instead of strings. The issue is that, the more generic you try to be, the less you can rely in pre-defined values. If you mean that we could take data in general and apply a compression algorithm, we haven't experimented with that. Sidetree uses JSON patches and zip compression, but in our conversations in DIF, the result is not that better than using protobuf of CBOR. We could explore other ways too, do you have any in mind to consider?

[iFergal]

I just meant to apply compression in general - though yes it's possible it's not much better than protobufs - perhaps some testing needed with some different compression algorithms.

It might overall help simplify in terms of adding new keys as you wouldn't have to worry about specific compression techniques for a key.

[EzequielPostan]

I will close the issue to keep a cleaner view of active ones We can re-open if needed