Re: [Wpack] About content-based origins

Hi Martin,

Thanks for your note.  A question in-line.

On Mon, Mar 23, 2020 at 5:34 PM Martin Thomson <mt@lowentropy.net> wrote:

> Ted's note prompted me to send a much-belated announcement (sorry folks, I
> forgot).
>
> The draft is here:
> https://tools.ietf.org/html/draft-thomson-wpack-content-origin-00
>
> A nicer version here:
>
> https://martinthomson.github.io/wpack-content/draft-thomson-wpack-content-origin.html
>
> This approach could a dramatically different approach to addressing the
> use cases set out in our charter.
>
> In short, this aims to address the core question of how offline content
> might *ultimately* be attributed to a web origin in a fundamentally
> different way.  There are two key concepts:
>
> 1. Content is given its own origin, using a new system for identification.
>
> 2. A target origin can "accept" content and state from one of these new
> origins.
>
>
I note that you did not include "hashing is a key element of
identification" in the key concepts here, despite it being pretty prominent
in the draft.  Is it something you consider fundamental here, or is it an
approach to demonstrate a method of achieving the two desiderata above?

> There are a lot of details here (read the draft), but the major advantage
> I see is that you don't have to make an offline decision about authority,
> and that means you can be offline for much longer (lifting the 7 day limit).
>
> I would personally describe this as a trade-off, rather than an
advantage.  The inability to make an offline decision about authority has
consequences for how different resources available to the client relate to
each other (e.g some come from a bundle and some from a cache).  To take an
unfortunately pressing example, let's assume a local authority has provided
a set of resources to local residents.  A new item is created and
distributed.  For those getting it via direct connection to the local
authority's server, the new item can be related to the other items.  With a
signed exchange and a signature verification, those receiving it
peer-to-peer can as well.  In a content-origin approach, my understanding
is that the new item could be received and displayed, but the ability to
integrate it with the rest of set is not active until the client can go
online and confirm with the local authority's serve that it verifies that
"ni:hashmumble" is the target.   The problem here for an offline client is
pretty serious, as it cannot determine whether the new resource is from the
local health authority or not.  If it updates information like a set of
symptoms or treatments, the consequences are large.

Have I missed something here?  If I have not, then this approach makes a
trade-off that limits its utility in ways that make peer-to-peer usage of
the approach problematic for use cases I personally care about it.  Others,
of course, may make other assessments of that trade-off.

regards,

Ted

> What it does have in common with signed exchanges approach is the need for
> a bundling format, but in its current form it is less dependent on the
> details of the format.  That might allow that to be simpler, but I'm sure
> that the need to mint new identifier types will more than make up for any
> slack there.
>
> The draft is quite rough.  I'm sure that it has the remnants of a few bad
> ideas still hanging around.  Ask questions if you think something is
> unclear.
>
> _______________________________________________
> Wpack mailing list
> Wpack@ietf.org
> https://www.ietf.org/mailman/listinfo/wpack
>