add text on deterministic CBOR encoding

[c2bo]

Closes #18

I wasn't entirely sure if we were in a state to propose a PR for this topic, but having text to discuss hopefully moves the discussion along.

[github-actions]

📄 Editor's Copy preview

https://openid.github.io/dchp/PREVIEW-DO-NOT-USE/pr-64/digital-credentials-harmonized-presentation-editors-copy.html

Preview of 0d1ee06; updated on every push. For review only — the official specifications are published at https://openid.net/specs/

[jogu]

discussed on today's call, no feedback, Martijn offered to review and also volunteered DavidZ :)

[jogu]

What's the outcome when they're not encoded as such? Is it undefined, are wallets required to reject RequestPayload if it's not deterministically encoded?

I can see some "fun" interoperability problems if a verifier sends something non-deterministically encoded and some wallets hash the RequestPayload as sent and some hash the decoded then reencoded one.

[martijnharing]

If these are not encoded following the rules, decryption would fail since the wrong input is used.

[jogu]

Well, yes, but the verifier will decrypt fine with some wallets, and fail to decrypt with others, and there's very little clue as to why.

Requiring wallets to reject requests which aren't deterministically encoded would instead surface the failure and cause pretty immediately. It would be an extra burden on wallets but maybe that's okay.

[jogu]

Possibly we should be 100% clear that values defined outside this document (like transaction data equivalents or credential format specific items) are also deterministically encoded?

Suggested change

	All CBOR data items defined in this document shall be encoded in accordance with the core deterministic encoding requirements defined in [RFC 8949, Section 4.2.1](https://www.rfc-editor.org/rfc/rfc8949#section-4.2.1).
	All CBOR data items defined in this document, including any extension values they contain, shall be encoded in accordance with the core deterministic encoding requirements defined in [RFC 8949, Section 4.2.1](https://www.rfc-editor.org/rfc/rfc8949#section-4.2.1).

[martijnharing]

Suggested clarification for the first section, otherwise good.

[martijnharing]

Taking your comment and trying to be a little bit more specific, how about replacing the text with:

---

All CBOR data items defined in this document, as well as any extension values embedded directly as CBOR data items, shall be encoded in accordance with the following requirements. For CBOR data items encapsulated within a byte string, these requirements only apply when the content of the encapsulated data item is defined in this document:

• The cbor data items shall be encoded in accordance with the core deterministic encoding requirements defined in RFC 8949, Section 4.2.1.
• Floating-point values like Nan, Infinity and -Infinity shall not be used.

Note: The deterministic serialization defined in draft-ietf-cbor-serialization [2] is the same as RFC 8949, Section 4.2.1 except for the encoding of NaN values, which are not used in this document.

---

[martijnharing]

If these are not encoded following the rules, decryption would fail since the wrong input is used.