Use of CTY to describe inner payload

[kdenhartog]

The text currently states:

The "cty" (content type) Header Parameter defined by [RFC7515] and
[RFC7516] is used by this specification to convey structural
information about the JWM.

In the normal case in which nested signing or encryption operations
are not employed, the use of this Header Parameter is NOT
RECOMMENDED. In the case that nested signing or encryption is
employed, this Header Parameter MUST be present; in this case, the
value MUST be "JWM", to indicate that a Nested JWM is carried in this
JWM. While media type names are not case sensitive, it is
RECOMMENDED that "JWM" always be spelled using uppercase characters
for compatibility with legacy implementations.

I'd propose we change it to be:

In the normal case in which nested signing or encryption operations are not employed, the use of this Header Parameter SHOULD be "JWM". In the case that nested signing or encryption is employed, this Header Parameter MUST be present; in this case, the value MUST be "JWS" to indicate the payload follows a standard JWS structure. The internal JWS header SHOULD also indicate "JWM".

Open aspects of consideration around this:

1. I think it could also be JWSC (compact JWS)/JWSJ(JSON JWS) to indicate the format of the payload that was encrypted.
2. In the case where this is a nested JWE for multi-level nesting as described in issue Multilevel Nested JWM #37 should we consider something like JWEH (JWE Header only data) to support this flow? More discussion needs to occur on this aspect still and a proposed format encryption/decryption processes would be needed for this as well.

[TelegramSam]

I think I understand your goal, but this application is inconsistent. If we are to indicate it is a JWS when signed, then it should be a JWE when encrypted. Whatever we do here should be consistent across the various packaging forms of a JWM.

[kdenhartog]

The CTY should be pointing the format of the inner payload was the general principle I was after. That way, when processing the outside format, I can strongly type the inner format before returning the payload.

[dhh1128]

This spec is the wrong place to require behavior. Because a JWM is intended to be specialized with different profiles, we explicitly (and correctly) say in the JWM spec that most of the fields are optional, and it's up to specific profiles to get more prescriptive.

I think at the level of the JWM spec, we should be saying something like, "use of the cty header is strongly recommended, with a value that identifies the content as a JWM. What that value might be could depend on how a profile specializes the JWM, but if which profile of JWM is unimportant, the generic value "JWM" is strongly preferred."

Then, at the level of the DIDComm profile of JWM, we should be requiring cty with a specific value -- but the value should be one that identifies DIDComm (and therefore JWM by implication), rather than generic "JWM."

[tplooker]

+1 I agree with @dhh1128