Links updated to 2nd Working Drafts today.

[dturnerx]

We just rolled out the 2nd working draft of CXP and CXF.

[LikeLakers2]

Hey, quick question. In the first working draft, the specifications used WebIDL to define the data structures - but this second working draft appears to use a different language. Can I ask what this language is called?

[LikeLakers2]

Ah, nevermind, I seem to have found my answer after fighting a bit with Google: It's CDDL, which itself is defined in RFC 8610.

That said, might I recommend making a note in the specification that it's using CDDL?

[Progdrasil]

Yeah that will be included in the next version, along with a clarification that the use of CDDL is to define JSON structures and not CBOR since CDDL can be used for both.

[LikeLakers2]

I noticed a couple things while looking through the changes between the first and second working drafts.

In the Protocol specification, the ExportRequest structure has a mode field, defined as mode: tstr. However, the field's description seems to want a ResponseMode. Seeing as how there's likely no useful values for mode aside from the ones defined in ResponseMode, shouldn't this field be defined as mode: ResponseMode?

Additionally, also in the Protocol specification, the HPKEParameters structure has a key field, defined as key: JWK. However, the field's description appears to imply that the field won't always appear (and therefore is optional). Shouldn't the structure definition reflect this?

[Progdrasil]

Thanks for the callout! A fix for key will be included in the next version.

Enums are hard in specifications when planing for backwards compatibility. In CX we're following a similar pattern to webauthn where we allow arbitrary values in case we add new values in the future and other providers haven't updated yet. That being said, we've landed on a more expressive way in CDDL by setting mode: ResponseMode / tstr. We've also added a section in both CX specifications explaining this pattern.

[LikeLakers2]

That makes sense. :)

As an aside, I think the term you're looking for is "forward compatibility"? At the very least, that's what it sounds like you want out of the mode field.