Message Headers section needs more details
Closed this issue · 0 comments
Here are a few comments about the message header section:
They are encrypted and decrypted along with body and therefore have an identical audience.
It could also mention they MUST be signed just like the body in case it's a signed message.
Also see below my comment about the typ header regarding fields that we might not want to encrypt...
id - REQUIRED. Message ID. The id attribute value MUST be unique to the sender.
This is not clear: is it a "Message ID" that MUST be unique across all messages of a given sender, or is it an ID that is "unique to the sender" but the same for all their messages?
type - REQUIRED. Plaintext message type, useful for message handling in application-level protocols. The type attribute value MUST be a valid Message Type URI, that when resolved gives human readable information about the message. The attribute’s value SHOULD predict the content in the body of the message.
"Plaintext message type" isn't clear, we already have a notion of plaintext messages. Rephrase using "body message type" maybe?
Also "predict the content in the body of the message" isn't really true, it's predicting the type of the said content.
typ - OPTIONAL. Media type of the JWM content.
This could explain briefly how it's not the same as type... And maybe link to the relevant media types?
Notice that the JWE spec has the notion of typ and cty "content type" headers already: https://datatracker.ietf.org/doc/html/rfc7516#section-4.1.11
It typically doesn't make a lot of sense to me to have the typ being encrypted and signed, as it's supposed to help with the application/implementation treating the message at hand properly.
As such, I'm not convinced it should be used as a DIDComm Message header that gets encrypted. Instead it would make more sense to have it in the headers of the envelop of the message, i.e. at the JWE or JWS level.
to - OPTIONAL. Identifier(s) for recipients. MUST be an array of strings where each element is a valid DID or DID URL (without the fragment component) that identifies a member of the message’s intended audience.
Could we specify an ordering maybe for the said array? Lexicographic order seems fine to me.
When Alice sends the same message to Bob and Carol, it is by inspecting this header that Bob and Carol learn that the message was sent to both of them. If the header is omitted, each recipient can only assume they are the only recipient (much like an email sent only to
BCC:addresses).
So, it seems we are expecting messages to have multiple recipients and not to be sending multiple per-recipient encrypted messages to multiple recipients instead... (Saying this wrt. the lengthy discussions we've had about multiplex encryption and multi-recipient messages)
The
toheader cannot be used for routing, since it is encrypted at every intermediate point in a route. Instead, theforwardmessage contains anextattribute in its body that specifies the target for the next routing operation.
At this point in the spec, it is not clear what is a forward message, neither whether it's part of DIDComm or not (especially since we covered already message type in 2.1-2.3 and it wasn't there.)
A reference would be welcome, and maybe a bit more details.
Also "contains a next attribute in its body" is strange, why not just in the headers? And also what type of body content are we talking about there? Is it a body field or something else?
If not included the
idproperty of the message MUST be treated as the value of thethid.
Notice that here the meaning changes depending if the id is unique per message or unique per sender, which is currently unclear see a previous comment above about the id.
pthid - OPTIONAL. Parent thread identifier. If the message is a child of a thread the pthid will uniquely identify which thread is the parent.
I'm assuming this, along with the fact that id is used as a thid if not present, means that when "responding" to specific messages, one would indicate doing so by using the pthid and setting it to the said message's id (which is being responded to).
Correct?
This mechanism could be made clearer as the thid and pthid usage isn't necessarily obvious, I'd say.
(Maybe this (p)thid stuff deserves its own issue, BTW?)
created_time - OPTIONAL. Message Created Time. The created_time attribute is used for the sender to express when they created the message, expressed in UTC Epoch Seconds (seconds since 1970-01-01T00:00:00Z UTC) [link](1970-01-01T00:00:00Z UTC). This attribute is informative to the recipient, and may be relied on by protocols.
It is not clear to me why there's a fake link displayed as is in the text: "[link](1970-01-01T00:00:00Z UTC)". Maybe this is missing the correct reference link?
Same issue for expires_time with a strange link appearing as text.
Aligning with RFC 6648, DIDComm Messaging explicitly rejects the X-* headers convention that creates divergent pseudo-standards; if a new header needs broad support, proper standardization is required. Since we expect header fields to be small in number and modest in complexity, we expect this sort of powerful extensibility to be unnecessary in most cases.
This seems to be slightly contradictory with the previous § saying "Additional fields with unreserved names can be added at the discretion of producers and consumers of messages".
Any thoughts?