Re: Bikeshed: "context" parameter for signatures

Good point. It kinda is the application name but not quite - it's not meant to be like an "agent" header, at least. I am a little wary of "data" because we don't want to imply or encourage putting structured information inside of it for things to parse downstream, which that implies to me.

Perhaps "tag" or "apptag" might work?

________________________________
From: Tyler Ham <tyler@thamtech.com>
Sent: Thursday, September 22, 2022 2:53 PM
To: Justin Richer <jricher@mit.edu>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: Bikeshed: "context" parameter for signatures

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