Clarify key hint #148
Clarify key hint #148
Conversation
Key hint is both specified in the bundle's `verification material` but may also be specified inside the `content` if it'a DSSE envelope. Signed-off-by: Fredrik Skogman <[email protected]>
Signed-off-by: Fredrik Skogman <[email protected]>
There was a problem hiding this comment.
No objection to the language, although I'll repeat a previous general concern about identifier/value duplication: every time we duplicate a value (and expect a conforming client to check it for consistency), we introduce a possible error state (or arguably worse, an ambiguous state where a validation path exists but some clients may be looser or stricter than others). Maybe that's unavoidable in this case, but I think as a general design principle we should continue to deduplicate state wherever possible.
|
The other option is saying that when a DSSE envelope is used, the key hint should not be set, or if set, should be ignored. |
|
IMO the current language is fine -- requiring that the two be exactly equal makes the most sense to me, I'm just griping about having to think about an additional error state :-) |
|
Agree that this is not ideal, but I think the current proposal (require them to be equal) is the best option given the current way the bundle is structured. |
Summary
Clarified how the use of (reduntant) key hint.
Key hint is both specified in the bundle's
verification materialbut may also be specified inside thecontentif it'a DSSE envelope. This discussion started in this PR #145This PR favours simplicity over efficiency; that is; the key hint should be equal and duplicated to simplify any consumption of the bundle, as the value may appear in multiple places. The key hint (if used) is usually a short string so I argue it's not too bad.
Release Note
Clarified how to populate the key hint in the bundle, when the content is a DSSE envelope with a key hint too.
Documentation
This PR is only documentation.