Optional encoding header field

[expede]

Initial source: ucan-wg/ts-ucan#73 (comment)

I'm not yet sure if this is a good idea or not, but on first glance it seems harmless at worst and useful for libraries at best.

I would of course check if there's already something like this in the JWT spec that we could plug into, but we already have added additional fields (UCAN version) to the header. @Gozala's dag-ucan can represent two encodings of a UCAN: one that's directly stringified as normal, and a second that can be optionally round-trip re-serialized by a library.

With this flag set, we could specify a tighter serialization order. Libraries that care about this can opt-in by using the flag to detect that this is in a sorted format. Importantly: libraries that don't opt-in can continue to use these tokens as normal by handling them in the bit-for-bit fully stringified format internally.

It would look something like this:

{
  "alg": "EdDSA",
  "typ": "JWT",
  "uen": "slx", // OPTIONAL: `UCAN Encoding = Stripped Lexicographical Order`
  "ucv": "0.9.0"
}
{
  // payload as normal
}
<SIGNATURE>

(Encoded as an enum for future extension.)

I'm not sure this would interact with also downcasing, since some URIs may be case sensitive 🤔

Thoughts?

[Gozala]

What would be the value of this option though ? It seems to me that it could invalidate otherwise valid UCAN.

One one hand it such option would let parser in dag-ucan know which representation it can parse into, but on the other hand I think it would probably still make sense for parser to validate that and if so I'm not sure there's really a benefit after all.

I'm not sure this would interact with also downcasing, since some URIs may be case sensitive 🤔

dag-ucan does not lower case URIs just values of can which spec says are case insensitive.

[expede]

It seems to me that it could invalidate otherwise valid UCAN.

No, it would make a normal valid UCAN, just "more constrained".

UCAN doesn't constrain the key ordering or whitespace by default. You have asked several times for a more constrained version that does set a key order etc, where we can deterministically encode a UCAN from its constituent fields. This change would give you a way to signal that a UCAN is deterministically serializable to the normal JWT format, by constraining key order and whitespace rules. The resulting UCAN is entirely valid — it's a subset of the possible encodings for a UCAN, where libraries that want to support this field can agree on how to deterministically serialize tokens. They would still need to support the unconstrained version.

Libraries that don't support this would treat the deterministically encoded UCANs as normal, because they're still valid UCANs.

[expede]

it would probably still make sense for parser to validate that

While this is a good idea, I don't think it would be "REQUIRED" from an implementation! It's a contract with the recipient to say "I put it in this format". If it can't round-trip the encoding, it 1. very much the creator's fault (they opted in), and 2. the UCAN is actually valid if the signature matches. It would be a "hint" only.

[matheus23]

The way I understand it, originally the idea was to support a deterministic encoding, which would make implementations easier to implement & less error prone.
An optional header would allow implementing UCAN libraries that are simpler, but only if they're exclusively support one specific optional encoding. I'm assuming that most libraries won't do that (and generally I assume most people will just use a library that "does the right thing" at some point).

Something else that I heard thrown around was a more compact encoding for UCANs, possibly based on CBOR.
I don't think that use case can be supported by an optional header value, since this still assumes a header/payload/signature JWT encoding, as far as I understand.