I am the designated artart reviewer for this draft.

Summary: Almost Ready

My biggest question about this draft is why it is separate from ietf-anima-rfc3866bis. It appears to be an extension to rfc3866bis, yet 3866bis is still being considered by the working group. 3866bis defines signature mechanisms in Section 6, but there is only one subsection, describing the CMS format voucher artifact. Why not just put the core of this in as Section 6.2?

The first part of Section 3 lists the different JWS serializations in RFC 7515. But the first statement in Section 3.1 says, “JWS voucher artifacts MUST use the ‘General JWS JSON Serialization Syntax’…”. Is the introductory information in Section 3 necessary? It looks like it may be left over from before that MUST requirement was placed.

In Section 3.3, “If present, the ‘typ’ parameter SHOULD contain the value ‘voucher-jws+json’”. Under what circumstances would the typ parameter be present or absent? Under what circumstances would the typ parameter contain a different value, especially since it seems like that would be self-contradictory?

Likewise in Section 3.3, under what circumstances would the x5c parameter contain something different, or should this be a MUST? Am I correct in assuming that the x5c parameter is only present for X.509v3 certificates (perhaps it should say that)?

Section 3.3 end of paragraph 2: “JWS Voucher parsers must be prepared” sounds like a normative MUST.

Nits:

Some RFC callouts are by RFC number, others by an abbreviation like [BRSKI]. I don’t know if it’s a requirement, but I prefer that this be consistent (I prefer RFC number).

Abstract: artifact called voucher -> artifact (known as a voucher)

2. Terminology: Terms after Voucher Data are in a different style.

3.3 paragraph 3: base64-encoded values opposed to base64url-encoded values may -> base64-encoded values, in contrast to base64url-encoded values, may

upfront -> up front

8.1 “in General JWS JSON Serialization” is not really needed since that’s the only serialization allowed.