- From: Niels Klomp <nklomp@sphereon.com>
- Date: Fri, 19 Jul 2024 11:30:21 +0000
- To: Giuseppe Tropea <giuseppe.tropea@cnit.it>, "public-credentials@w3.org" <public-credentials@w3.org>
- Message-ID: <PAWPR08MB9589DFD7743D400858860CE7B6AD2@PAWPR08MB9589.eurprd08.prod.outlook.com>
I would also mention did:jwk. IMO that is a more straightforward DID method than did:key with its multibase and mutlicodecs unnecessarily complicating things. DID JWK is literally a JWK but then base64URL encoded, thus supporting a well-established standard way of encoding keys on the internet. The OID4VC set of specs also has it roots in OAuth where JWKs are heavily used, so it maps in a straightforward way onto JWKs. Just to give an example. EBSI uses did:key but then uses a JWK with JCS encoding, which is not part of the did:key spec. Although did:key is historically used quite often, the simplicity and familiarity by non-DID people of JWKs makes did:jwk the better spec IMO. This is the reason why we choose it over did:key in certain interop profiles we are involved in. Kind regards, Met vriendelijke groet, Niels Klomp CTO [cid:58c7e10e-63c2-46ea-b28c-f928e669a055] J.M. Keynesplein 10 1066 EP Amsterdam +31 (0)852 736513 Op woensdagmiddag niet aanwezig [cid:d495863b-7486-4eb2-9a25-7b766955e2c2]<https://outlook.office.com/bookwithme/user/ef3b1d5aa847400582b6e64de43cd9d9@sphereon.com?anonymous&ep=signature> Maak een afspraak voor een gesprek met mij<https://outlook.office.com/bookwithme/user/ef3b1d5aa847400582b6e64de43cd9d9@sphereon.com?anonymous&ep=signature> ________________________________ Van: Giuseppe Tropea <giuseppe.tropea@cnit.it> Verzonden: vrijdag 19 juli 2024 12:58 Aan: public-credentials@w3.org <public-credentials@w3.org> Onderwerp: Re: info about the “did:ebsi” method dear Markus and Alen, all CCG, thank you for your swift replies and help. I am one of the authors of the NGSI-LD specification at ETSI, which leverages JSON-LD for Property Graphs. We are now working on the second version of our security report for NGSI-LD. I am compiling a section about DID Authentication, and I want to list a set of representative did methods that cover the most relevant trust architectures. For instance I would mention: * did:key (offline, no external registry/resolver) * did methods based on ethereum or bitcoin (permissionless global ledger) * did:sov (permissioned global ledger with trust governance and trusted steward nodes) * did:ebsi (government owned network of trusted nodes, identifiers are bound to legal entities) * did:web or dns (trust rooted in the existing PKI for DNS/HTTPS certificates) Is my summary of the characteristics of did:ebsi and the others above correct? Do other similar methods in the same area as did:ebsi exist? Does a (different) did method exist that is a good fit for a “private dataspace” trust model rooted at the owner of the data space, who can in turn delegate trust to other trusted members of the data space? Thank you for your work, giuseppe Il giorno 15 lug 2024, alle ore 22:50, Alen Horvat <alen.horvat@netis.si> ha scritto: Dear, I’m one of the architects at EBSI. If you have any questions about the EBSI DID method, let me know and I’ll try to help the best I can. BR, Alen On 15 Jul 2024, at 14:45, Giuseppe Tropea <giuseppe.tropea@cnit.it> wrote: dear Credentials Community Group, after a cursory scan of the discussions here, I was surprised I didn’t find much about the “did:ebsi” method for legal entities (see https://hub.ebsi.eu/vc-framework/did/legal-entities). I see it is not in the list of did methods here: https://w3c.github.io/did-spec-registries/#did-methods Does anybody have any info? Thanks, giuseppe — Giuseppe Tropea CNIT - Italy giuseppe.tropea@cnit.it<mailto:giuseppe.tropea@cnit.it> —
Attachments
- image/png attachment: Outlook-22pj4ctw.png
- image/png attachment: Outlook-nbborilp.png
Received on Friday, 19 July 2024 11:30:28 UTC