Canonical Representation / Signing requirements

[mlagally]

We need to review JSON signing mechanism wrt. canonicalisation requirements.

https://tools.ietf.org/html/rfc7515

Check for number representation formats, whitespace handling, sort order. we should however not duplicate requirements in the profile that are already covered by referenced material.

[mlagally]

https://www.w3.org/TR/vc-data-model/ Verifiable Credentials Data Model 1.0 REC

[mlagally]

The canonical representation as defined by https://tools.ietf.org/html/rfc8785 looks like a good start.

We shoud check if there are any requirements that require TD specific additional clarifications.

[mmccool]

So another thing we should clarify in the TD spec are arrays-of-one-element being expressed as a single value. I think profiles currently require these to be expressed as arrays but this goes against certain things where we say otherwise, ie security (where the array form, ie with more than one element, is deprecated, since we want to remove the array completely in a future version...).

Edit: Other TD canonicalization topics discussed:

• Default values. Do we omit properties that are assigned their default values? These could have been filled in when a TD is imported into a directory, for example.
• Prefixes. This is a JSON-LD issue. If a URL is defined for a prefix, and a database expands them internally, we need to convert BACK to prefixes when serializing... IF the original document used them. We may have to add a rule that TDs must ALWAYS use prefixes and not URIs for vocab terms? I suspect this is the main thing we should coordinate with the JSON-LD group, but we should ask them about other known issues.
• Array ordering. There some places in TDs where arrays are used but the order does not matter, eg form, op, etc. We need to add an assertion that TD processing must not change the order of any arrays, even if there is no semantic change. Note that JCS says that order of arrays is not changed.
• Array-of-one-element: see above. We should check for any other equivalent-ways-to-express the same thing and the canonical form should insist on one.

[mmccool]

Note there are already two issues on this:

• https://github.com/w3c/wot-thing-description/issues/940
• https://github.com/w3c/wot-security/issues/166

The one in security points at the TD issue and that's where I think this discussion belongs, as canonicalization requirements (and the scheme for embedding the signing information, eg an ld-proof block) should go into the TD spec, I feel (not profiles; signing should be a universal TD feature, IMO).

[mlagally]

Arch call on 10.12.: We prefer shortness of a TD over verbosity:

• default values MUST not be included in the canonical form of a TD
• prefixes: use the compact form

We have to select a specific signing mechanism / algorithm, may need to update to a new version when an algorithm gets broken. There needs to be an extension of the TD data model to support https://tools.ietf.org/html/rfc7515.

As a strawman we agree to use JWE with a selected set of algorithms (t.b.d: select algorithms that have not been compromised yet and can be done on resource constrained devices)

See: https://datatracker.ietf.org/wg/jose/documents/

Review the algorithm choices done by CBOR (COSE) https://tools.ietf.org/html/rfc8152

[mlagally]

We want to reference the corresponding TD chapter and provide required additional constraints, if necessary.

[mmccool]

The above PR is ready for review, and should address this issue.