Sidetree Operation Test Vectors in Spec

[OR13]

JSON Create Payload => did JSON Update Payload (contains a compact JWS) kid is in header JSON Recovery Payload (contains a compact JWS) kid is in header JSON Deactivate Payload (contains a compact JWS) kid is in header

[OR13]

related https://github.com/w3c/did-core/issues/259

[troyronda]

We likely will have some canonicalization discussion when thinking about the inputs to the test vectors.

[troyronda]

(if there are test vectors on how the client produced the encoded value from JSON).

[OR13]

Targeting May 19th for completion.

[txalkan]

I've also been wondering about the use of kid, is it gonna be supported in the reference implementation code?

[OR13]

@thehenrytsai @csuwildcat @isaacJChen Can one / all of you add examples of the JWS used by sidetree here: https://github.com/decentralized-identity/did-jose-extensions

@julio-cabdu short answer is that sidetree reference implementation has fixtures like this: https://github.com/decentralized-identity/sidetree/blob/06152ae3a7062f64192ecd180e137c5ad5a76e5d/tests/fixtures/update/update.json

signed_data is is a normal JWS... it looks like this

You can see the JWS header does not contain a kid...

{
  "alg": "ES256K"
}

The outer object (not signed) contains a pointer to the identifier.... because sidetree invented its own commit reveal scheme, operation verification (in the context of JWS), is only defined in the sidetree spec....

You take the revealed public key, and use it to verify the JWS.... in other words.... sidetree does not use kid for any protocol operation verification.

however, you can specify kid (id) on keys you add to did documents... and still verify JWS, according to whatever JOSE based spec you are following or the JSON-LD documentLoader conventions for DID Core / VC Data Model.

Here is an example of a did document, signed by all the keys in a did document: https://github.com/w3c-ccg/lds-jws2020/blob/master/docs/example/didDoc.json

Notice:

 "verificationMethod": "did:example:123#NjQ6Y_ZMj6IUK_XkgCDwtKHlNTUTVjEYOWZtxhp1n-E",

See my proposal here: https://github.com/decentralized-identity/did-jose-extensions/blob/master/options.md#kid-value-in-jwajwe

TL;DR; JOSE support in DID Core and the VC Data Model is incredibly poorly documented.

[txalkan]

thanks for the info! what about the future regarding Schnorr signatures?

[OR13]

@julio-cabdu https://github.com/decentralized-identity/SchnorrSecp256k1Signature2019#terminology

Could be years before schnorr is added to IANA.... and of course, you would need a variant for each of the key types that support schnorr.... TL;DR.... don't use unregistered crypto, unless you are prepared for it to become registered differently than it worked when you started using unregistered crypto.... ES256K-R is probably never doing to be registered at this point.

[OR13]

Next thing to do is make sure the test vectors are referencing in the spec.

[OR13]

We added test vectors here: https://github.com/transmute-industries/sidetree.js/tree/master/packages/test-vectors/src

[troyronda]

Same action/resolution as #550 @thehenrytsai @csuwildcat