bcgov / trustdidweb

Trust DID Web (did:tdw)
https://bcgov.github.io/trustdidweb/
Apache License 2.0
12 stars 6 forks source link

Use JWS instead of DI Proofs? #61

Open swcurran opened 5 days ago

swcurran commented 5 days ago

It was suggested at the DICE presentation on Trust DID Web that instead of using Data Integrity proofs, did:tdw should use JWSs.

This issue is to collect feedback on the two options to determine which is the preferred approach. If we do switch to use JWSs, should the updateKeys format be changed as well?

Comments welcome.

swcurran commented 5 days ago

FYI @TimoGlastra.

TimoGlastra commented 5 days ago

Because creating a JWS is so simple, and already used so broadly I have a slight preference for using a JWS in general. That said, the benefit of DataIntegrityProofs is that a normalization scheme is defined as well, meaning it's easier to keep the integrity protected data outside of the encoded JWS (like it is now). A benefit of adding the integrity protected data to the JWS is that you wouldn't need a canonicalization scheme at all as you'd always start with the base64url encoded data (and you decode it to work with the data, or you hash it to verify the signature). But as JCS is already a requirement for generating the SCID there's no reduction in complexity by not requiring JCS here. I think that was my main reason for suggesting JWS to reduce the steps required verify the integrity of the data (which is what I dislike about JSON-LD, it's so damn hard to verify a signature when using JSON-LD)

If switching to JWS, It'd probably make sense to also update the updateKeys entry to be an array of JWKs. But looking at how keys are included in DID documents, multiKey seems to be the standard nowadays. It might be good though to define which encoding format(s) are allowed for the multi-key updateKeys, so it's easier to get interop for processing did:tdw jsonl file (e.g. only allow base64 encoding)

dbluhm commented 2 days ago

The simplicity of JWS is appealing. As Timo suggests, it seems it would be a good idea to use JWK representation of the key -- which I do find to be a bit of a bummer, I like the conciseness of the Multikey representation but the existing tooling for using JWKs is extensive, which would further simplify implementations and lower the barrier to entry.