Code change:
2.1.1. If the value of an HTTP field is known by the application to be a <del> structured field (STRUCTURED-FIELDS), and the expected type of the structured field is known, the signer MAY include the "sf" parameter in the component identifier.  If this parameter is included with a component identifier, the HTTP field value MUST be serialized using the rules specified in STRUCTURED-FIELDS applicable to the type of the HTTP field.  Note that this process will replace any optional internal whitespace with a single space character, among other potential transformations of the value. </del> <ins> structured field type (as defined in STRUCTURED-FIELDS or its extensions or updates), and the expected type of the structured field is known, the signer MAY include the "sf" parameter in the component identifier.  If this parameter is included with a component identifier, the HTTP field value MUST be serialized using the formal serialization rules specified in STRUCTURED-FIELDS (or the applicable formal serialization section of its extensions or updates) applicable to the type of the HTTP field.  Note that this process will replace any optional internal whitespace with a single space character, among other potential transformations of the value. </ins> If multiple field values occur within a message, these values MUST be combined into a single List or Dictionary structure before serialization. <ins> If the application does not know the type of the field, or the application does not know how to serialize the type of the field, the use of this flag will produce an error.  As a consequence, the signer can only reliably sign fields using this flag when the verifier's system knows the type as well. </ins> For example, the following dictionary field is a valid serialization: If included in the signature base without parameters, its value would

Related discussion:
text: You need to know the top-level type (Dictionary, List, or Item) for each field. The consequence of that (AIUI) is that a recipient wishing to validate a signature that uses will need to understand the top-level type of each 'd field in the signature. It'll also need to support the permissable types in those fields -- e.g., if a field allows Date, the recipient needs to be able to handle that. As a result, it won't be possible to reliably verify a signature if your processor doesn't have knowledge of the top-level type, or if it doesn't have support for an extension type in use in one of those fields. However, there is a chance of verifying it still, if the SF-produced form is sent on the wire and not changed at all in transit, and the processor just ignores processing (and in some ways, this is worse than reliably failing). I think this all can be reasoned out by reading the specs appropriately. Documenting it as a tripping hazard would help users avoid interoperability issues, but this specification is already long and dense, and if we also make it a user guide, it will risk becoming unusable. So, speaking personally -- if the above summary is correct, I could see adding a sentence or two to section 2.1.1 at the most; I could also see leaving it to a separate profile/user guide.
[ chair hat on ] This issue is the last thing holding the Signature spec going to IETF LC. NAME NAME please respond to above, particularly: whether such text is necessary whether such text will address the issue when such text, if necesary, would need to be incorporated (before/after LC). Thanks,
I believe it would be good to have such text; and that it should be in the spec, not in a guide that is unlikely to materialize. It should be incorporated before LC (I hope you mean a new WGLC here...?). Given the amount of changes, we really should spend some time reviewing all that changed, and to verify that the open issues have been addressed properly.
NAME can you propose something? I don't see any reason to rerun WGLC, based upon the current PRs; there are some changes (especially in one or two), but they're based on AD review and can be discussed during IETF LC.