Re: Bikeshed: "context" parameter for signatures

"appdata" doesn't address the structured data concerns Justin raised, which I agree with.

I like "tag" or "label", as they capture both the variable, application-defined meaning of this parameter's value, and its optionality.

—
Annabelle Backman (she/her)
richanna@amazon.com<mailto:richanna@amazon.com>




On Sep 22, 2022, at 11:53 AM, Tyler Ham <tyler@thamtech.com<mailto:tyler@thamtech.com>> wrote:


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.


My first thought when I see the labels "app" and "application" is that the value is meant to be the name of an application.

How about something like "appdata"? This changes the noun to a generic "data", but it keeps "app" in there as an adjective to indicate that this parameter is for something application-specific.

Tyler


On Thu, Sep 22, 2022, 8:43 AM Justin Richer <jricher@mit.edu<mailto:jricher@mit.edu>> wrote:
I missed an issue that had been filed (but not tagged) prior to the publication of signatures-12, and it asks a pretty simple question:

We added a “context” parameter to allow applications to put a specific string that the application can recognize into the signature parameter set, so that (for example) an authz protocol can declare that a specific value be used or a cloud deployment can have all of its proxies use the same value. However, the term “context” is used in other ways in the spec, so it’s not the best term to use for this new parameter. The proposal is to change “context” to “application” or even the shorter “app”:

https://github.com/httpwg/http-extensions/issues/2249



I’d like to do a quick bike shed on this parameter name here, for anyone who has an opinion. Since it’s newer, existing libraries mostly don’t have it supported yet so if we’re going to change it we should change it right now.


Thanks,
 — Justin