Repository navigation
Clarify signature requests and conditional signing - #141
Conversation
| Agents can sign every request or sign only when an origin requests a signature | ||
| ({{requesting-message-signature}}). Conditional signing adds a round trip when | ||
| the origin requires a signature. Non-idempotent requests cannot be automatically | ||
| retried without additional protocol mechanisms; see {{Section 9.2.2 of HTTP}}. |
There was a problem hiding this comment.
This is super vague. Does the agent try every request without so that each is made twice? A 403 is a per-resource thing, right? Or should it make some guesses and start signing everything after a signature is requested? What in the response it gets would indicate one vs. the other?
There was a problem hiding this comment.
This is how the Web works today for many kinds of failures; scoping of metadata has always been an issue in HTTP headers (as I often complain).
Even HTTP auth realms don't really provide this; while they tie things together, they don't describe the shape of the protection space; instead we get this advice -- which seems to have not made it into 7616 (after a quick glance).
I could see adding path-based advice like that. I could also see making this effectively a server-wide hint. Something more complex than either of those might scratch an itch for some people, but I kind of doubt the extra complexity would be worth it.
There was a problem hiding this comment.
I know that the situation is, by default, terrible. I'm suggesting that maybe this specification doesn't have to follow that pattern. An explicit scope parameter would be a huge upgrade. The fuzzy basic auth scoping thing is second best. What this has presently is far from satisfactory.
There was a problem hiding this comment.
reading RFC 7616 domain parameter, would this be something similar that you are after?
A quoted, space-separated list of URIs, as specified in [RFC3986], that define the protection space
Specifically, a scope at which the parameters that, once discovered, can be reused?
Thinking through, we could add a parameter to HTTP Message sig domain= and have something similar.
This does not answer the question about signing target-uri for instance, which would impose a new signature per URL and prevent reuse, but that's a distinct question
There was a problem hiding this comment.
Related to this (and we might have talked about it earlier, Thibault), it would be great to have a mechanism to signal the client that they can stop signing. We heard of implementers who only care about the first request to be signed, then they use other mechanisms to identify the client. In this case it would be great if the client could stop signing.
| `nonce`. | ||
| The status code SHOULD be 403 Forbidden as defined in {{Section 15.5.4 of HTTP}}. | ||
|
|
||
| Signature requests MUST be consistent with this profile. Agents MAY ignore |
| Agents can sign every request or sign only when an origin requests a signature | ||
| ({{requesting-message-signature}}). Conditional signing adds a round trip when | ||
| the origin requires a signature. Non-idempotent requests cannot be automatically | ||
| retried without additional protocol mechanisms; see {{Section 9.2.2 of HTTP}}. |
There was a problem hiding this comment.
Related to this (and we might have talked about it earlier, Thibault), it would be great to have a mechanism to signal the client that they can stop signing. We heard of implementers who only care about the first request to be signed, then they use other mechanisms to identify the client. In this case it would be great if the client could stop signing.
|
@sandormajor your comment should have been addressed in d0a4fa1 |
|
merging as is, so that we have a draft before the cut off. some issues have been openned to track remaining discussion |
Addresses feedback from @mnot on the mailing list
@sandormajor for review