Envelope headers

[iamwillbar]

We've been discussing a couple of scenarios where it would be helpful to share signed side-band information beside the payload. The obvious workaround is to generate a new payload that wraps the original payload and stores the side-band information plus the original payload in the new payload.

Would there be interest in having this being a first-class part of the envelope to avoid the workaround?

[TomHennen]

Can you provide some examples?

[iamwillbar]

You may want to include information about where (e.g. machine name), when (e.g. @dlorenc's suggestion in #33), who (e.g. a decentralized identity. This is along the same lines as HTTP or SMTP headers, arguably the payloadType is just a specialized Content-Type header and could even move into this header section.

[dlorenc]

IMO the timestamp is conceptually part of the signature, so it might make sense in the envelope.

The machine name, etc should probably go into the payload. There's not a great spot for the machine name in the ITE-6 payload right now, though.

[iamwillbar]

@dlorenc you're right, anything can go in the payload but that assumes you have control over the payload. If you wanted to take some arbitrary content and wrap this around it then it's nice to have a side-channel you can annotate without having to manipulate the payload.

[TomHennen]

Are you asking for something like a plain old 'metadata' field that can be any dict the producer wants but that people shouldn't depend on for making policy decisinos?

[MarkLodato]

My feeling is no. Signing-spec/DSSE is intended to be "dead simple" to minimize attack surface. JWS already exists and has the requested feature. If we added it here, we'd basically be reinventing JWS.

The workaround described in the original post is a reasonable solution. Or alternatively just use JWS if it provides the features you need.