CDDL in B.2.6 forbids the null value the prose requires

Both Handover structures declare the third element as a byte string. B.2.6.1:

OpenID4VPHandoverInfo = [
  clientId,
  nonce,
  jwkThumbprint,
  responseUri
]

jwkThumbprint = bstr

and B.2.6.2:

OpenID4VPDCAPIHandoverInfo = [
  origin,
  nonce,
  jwkThumbprint
]

jwkThumbprint = bstr

bstr is CBOR major type 2, while null is major type 7, so a bstr cannot carry it.

The prose beside each block requires null. B.2.6.1:

If the response is encrypted, e.g., using direct_post.jwt, the third element MUST be the JWK SHA-256 Thumbprint as defined in [RFC7638], encoded as a Byte String, of the Verifier's public key used to encrypt the response. Otherwise, the third element MUST be null.

and B.2.6.2:

For the Response Mode dc_api.jwt, the third element MUST be the JWK SHA-256 Thumbprint as defined in [RFC7638], encoded as a Byte String, of the Verifier's public key used to encrypt the response. If the Response Mode is dc_api, the third element MUST be null.

So for Response Mode dc_api, which is one of the two modes Appendix A permits, a conformant OpenID4VPDCAPIHandoverInfo appears to violate its own CDDL. That is one of two paths through that block rather than an edge case, which is what makes me think I am reading it wrong rather than that it is a small slip.

The consequence is not cosmetic, because these bytes are hashed into the SessionTranscript that the mdoc DeviceResponse signs or MACs. An implementer working from the CDDL and an implementer working from the prose produce different bytes for the same request, so the Verifier's signature check fails with no indication of why.

I looked for a nullable CDDL form elsewhere in the document, in case there is a convention I am missing, and did not find one.

So, two questions. Is the intended CDDL a type choice, jwkThumbprint = bstr / nil? Or is the prose meant to name a different value, such as a zero-length byte string, rather than null? Either answer resolves it, and I could not tell which was intended from the text.

Read the CDDL and adjacent prose in Appendix B.2.6.1 and B.2.6.2, then compare the response modes listed in Appendix A. Done means resolving whether the third element permits null or requires another value, and aligning the CDDL and prose so both describe the same SessionTranscript bytes.