Use JWS instead of DI Proofs?

[swcurran]

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]

FYI @TimoGlastra.

[TimoGlastra]

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]

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.

[PatStLouis]

As @TimoGlastra pointed out, since generating the SCID requires JCS, using JWS would actually add complexity to the overall spec, negating the main purpose behind this suggestion. The simplicity of JWS is also mainly due to the library support. If an implementer was to build this from the ground up, would it actually be simpler to do JWS signing? (genuine question as I do not have insight here)

I do like the idea of having an opinionated approach to the multiKey as to which base representation to recommend.

I would favor keeping the Data Integrity w/ ecdsa-jcs-2019 cryptosuite. All references can be kept to the W3C specifications and avoid cross body references for implementations (JWS being an IETF recommendation). Having 2 competing standards in the same specification sounds like it might create problems downstream.

This being said, I have limited hands on experience with TDW.

[dbluhm]

If an implementer was to build this from the ground up, would it actually be simpler to do JWS signing?

Short answer is yes. The JWS specification is well defined and widely implemented. Implementers of did:tdw would not have to read up on the specification at all and just use a library that supports it.

While part of the simplicity is indeed compromised by needing to canonicalize the doc for SCID generation, I contest that JCS is still significantly simpler conceptually than introducing JSON-LD for producing a signature. JCS may be required in the process of generating a SCID but it would not be a part of verifying the signature itself, which I would again contest is still a significant simplification.

The only consolation I have in the selection of ecdsa-jcs-2019 cryptosuite is that JSON-LD contexts don't have to be resolved in order to verify the signature.

All references can be kept to the W3C specifications and avoid cross body references for implementations (JWS being an IETF recommendation). Having 2 competing standards in the same specification sounds like it might create problems downstream.

I think this is unavoidable, realistically; JCS is neither a W3C nor IETF recommendation so usage of ecdsa-jcs-2019 is already a departure from "pure W3C" specifications. I don't find this a compelling reason not to use JWS.

[dbluhm]

At some stage, the "turtles all the way down" needs to reach a base case where a "primitive" is used. I assert a JWS would be that primitive. As it stands, in order to support the DI proof, we have to format the key as did:key, which is a DID method that never left unofficial draft status and contains odd edge cases. Using a JWS would eliminate this issue.

[andrewwhitehead]

Since a detached JWS is used, the payload would depend on the context and we could define it to be the base64-encoded JCS-normalized log line. Or make use of the 'b64: false' attribute (RFC 7797) and skip that encoding. If we eliminated the 'patch' option so that the entire document is in each log line, I believe it would also suffice to just sign the entry hash. (Technically the document state is protected even with patches, but less explicitly since it depends on the correct evaluation of the patch.)

I could handle storing the keys in JWK format since the conversion from multikey is a pain for verifiers (finding the 'y' coordinate for ECC keys). The pre-rotation hash could be the JWK thumbprint, or it could be the JCS of the entire key definition (including the kid).

[PatStLouis]

Implementers of did:tdw would not have to read up on the specification at all and just use a library that supports it.

I find the argument of going with whatever has the most existing library counter innovative, as by that logic you shouldn't use any new technology which don't have library support and maintain a perpetual status quo. Library support comes with time and market adoption. It is undeniable however that it makes it easier for new implementers.

JCS may be required in the process of generating a SCID but it would not be a part of verifying the signature itself, which I would again contest is still a significant simplification.

Doesn't a verifier still need to verify the SCID which involves the same algorithm as the generation? Or is the SCID verification not important and can be skipped entirely?

I contest that JCS is still significantly simpler conceptually than introducing JSON-LD for producing a signature.

Did you mean JWS here? I'm unclear what is being contested since I'm also suggesting that JCS is a simpler process for generating a signature.

which is a DID method that never left unofficial draft status and contains odd edge cases.

Fair, but at the same time no did method is formally a recommendation, at least none that I know of (web, indy, jwk, key, peer) are all drafts. DID key does have a fairly robust test-suite to demonstrate interoperability.

I'm also not a big fan of seeing former editors of the VC-JOSE specification formally requesting Data Integrity not to be published as a recommendation in favor of IETF standards and I will be transparent that these accusations do influence my decision making. Albeit this is in a different context, all roads lead to Rome. Data Integrity is very much a specification I look forward working with in the future and would like seeing it used more broadly, being aware that it's a fairly new concept.

The main concern behind this issue seems to be market adoption/barrier of entry. I'd like to hear more from the editors of TDW on the choice of technology and their opinion about impact on market adoption.

[brianorwhatever]

Another benefit to DI is that we could use a proof chain for the witness proofs such that they are signing on top of the proof created by the controller. See #66

[swcurran]

Closing this -- for the foreseeable future we will stick to DI proofs.