Include a new codec from EBSI implementation

[samu-gataca]

Hi there,
I'm reaching out you to try to include the EBSI specification into the did key specification.
https://api-pilot.ebsi.eu/docs/specs/did-methods/did-method-for-natural-person#schema-of-the-method-specific-identifier

As you can see in the implementation, there is a multicodec approach

With this public key P-256
{ "crv": "P-256", "kty": "EC", "x": "Lyzu4hajYTyIBGeg31gneDkID1iiUapPONRPIrG8l4Y", "y": "iMLobYRurzjfgfJS-CbAPMA8xrVsA8QgQdimEu_W-yo" }
The DID generated is
did:key:z2dmzD81cgPx8Vki7JbuuMmFYrWPgYoytykUZ3eyqht1j9KbpaxuVPhKtEdpKCagY9XhyyyzNUPwwd4ookwVpAMkkMnKkNWWUJrSYPuShZp8dPKs17kBZqqfz3vDn3QQUT9EEiZN59AGSnDFxYLaRb2DawMkRhJth6U76FuKuWPZJE3v2G

In your specification there is the possibility to use this kind of codifications, so we are requesting to add this new one to the list included into the did method.

[alenhorvat]

Thank you @samu-gataca

[dmitrizagidulin]

@samu-gataca fascinating approach...

[samu-gataca]

Hi there, any new about this topic?
Regards

[reinkrul]

I'm opposed to this. It would make did:key implementations very cumbersome to make "complete": the DID method specification limits what you need to support (NIST-EC and RSA-family, and some other curves), but now you're including a container type (JWK) which can be anything JWK supports, including symmetric or private keys.

I.m.o., if you're handling JWKs, use did:jwk.

[bumblefudge]

https://github.com/multiformats/multicodec/blob/master/table.csv#L557

hey neat I never noticed that eb51 is l33t for ebsi 😅

while i tend to agree that someone who needs "any key that can be expressed in a jwk" already has a whole 'nother DID method they can use, this isn't any key, it's a very specific, profiled key expression that is deterministic enough (thanks JCS!) for use in multiformats/IPFS-usecases and can always be translated to a JWK where that interop is needed. i am +1 here, actually.

for me the bigger question is whether all multicodecs enumerated in the spec need to be mandatory for all implementations, or if some can be optional... each key type/curve adds more NxN interop, so there might be an argument for making ANY key expression that has a specified multicodec expression an optional extension...

[vdods]

I would personally recommend separating the concerns of what key types are representable within the data model of did:key from what key types are actually supported by a given implementation. See my comments in #70 (comment)