Re: [Wpack] Sec-Content-Origin clarification question (was Re: About content-based origins)

[Jeffrey Yasskin <[e-mail]>]

On Wed, Mar 25, 2020 at 10:29 AM Ted Hardie <[e-mail]> wrote:

> Hi Devin,
>
> Thanks for the write-up.  A clarifying question, snipped from the middle
> of your response:
>
> On Tue, Mar 24, 2020 at 11:36 PM Devin Mullins <twifkak=
> [e-mail]> wrote:
>
>>
>> In terms of publisher implementation feasibility, I think the mostly
>> likely implementation would be for a publisher to produce a
>> Sec-Content-Origin (Sec-CO) response for the current version of the
>> resource iff it matches the Sec-CO request. I suspect that keeping state of
>> past versions of the resource would be infeasible, especially as it
>> couldn't be done purely at the edge; it would require something like a
>> region-wide cache. The value of the above stateless implementation would be
>> inversely proportional to how often the resource changes (e.g. "transient
>> content" [2] such as Related Articles). I think this would be a workable
>> constraint for publishers wishing to publish such bundles, but felt it's
>> worth noting, nonetheless.
>>
>
> If the ecosystem supported something like signed bundles and unsigned
> bundles which used content identifiers, would you see a site sending a
> Sec-Content-Origin response resulting in the user agent essentially
> upgrading the bundle's treatment to the same as a signed bundle's, or would
> there a third state (unsigned bundled, verified NI, signed bundle)?
>

I don't think there should be three states.

I've been trying various models and sets of terminology for the possible
treatments of bundle content over the last couple months, and I'm not yet
sure what model makes most sense. This week, my favorite is to use
HTTP's notion of a response being "authoritative",
https://tools.ietf.org/html/draft-ietf-httpbis-semantics-07#section-11.1. A
response in a bundle can either be authoritative for their claimed URL or
not, and they're authoritative if any of several conditions holds:
1. The bundle itself was served by the same origin.
2. The bundle was signed by the origin.
3. A live request to the claimed origin adopts the content.

I think that doesn't quite match Martin's notion of aliasing origins, so I
still have some thinking to do.

Jeffrey