Subject: [Wpack] WG Review: Web Packaging (wpack)

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 17 Feb 2020 14:52:08 -0500

I am a bit fuzzy on the non requirements. In particular, the DRM non
requirement.

If you have a means to publish a compound document as a book and you have a
means to protect the privacy of that compound document, you have the
ability to encrypt which means that you have a certain level of DRM
capability.

As I see it DRM is a combination of two problems, one control over initial
distribution, the second control over redistribution. The second has proved
to be infeasible of course but the first is quite tractable. So I think it
would be useful to narrow the statement to controlling redistribution.

What I think is also intended here is that the group does not consider the
protocol(s) by which access tokens are exchanged beyond the simplest case
of passing a key over a TLS connection. This should probably be stated
directly.

Also, I think that rather than a 'signing document', the group really has a
syntax document and it is far from clear that there will be only one. My
work requires a blockchain type capability, that is incremental
authentication and encryption. I certainly plan to re-use the bundling
semantics but I can't make use of a syntax that arbitrarily dismisses my
core requirements.

---

From: "Alexey Melnikov" <[email-masked]>
Date: Thu, 20 Feb 2020 10:14:03 +0000

Hi Phillip,
Thank you for your comments. My answers below.

On Mon, Feb 17, 2020, at 7:52 PM, Phillip Hallam-Baker wrote:
> I am a bit fuzzy on the non requirements. In particular, the DRM non requirement.
> 
> If you have a means to publish a compound document as a book and you have a means to protect the privacy of that compound document, you have the ability to encrypt which means that you have a certain level of DRM capability.
> 
> As I see it DRM is a combination of two problems, one control over initial distribution, the second control over redistribution. The second has proved to be infeasible of course but the first is quite tractable. So I think it would be useful to narrow the statement to controlling redistribution.
I think the idea is to declare both out of scope, so I would rather not get into details of how DRM might be implemented using the format. So I suggest no change.

> What I think is also intended here is that the group does not consider the protocol(s) by which access tokens are exchanged beyond the simplest case of passing a key over a TLS connection. This should probably be stated directly. 
I am not entirely clear where this text can be inserted. Can you suggest some specific text and where to insert it

> Also, I think that rather than a 'signing document', the group really has a syntax document and it is far from clear that there will be only one. My work requires a blockchain type capability, that is incremental authentication and encryption. I certainly plan to re-use the bundling semantics but I can't make use of a syntax that arbitrarily dismisses my core requirements.

There is no mentioning of "signing document" in the charter. I think what you propose is a very reasonable thing to discuss in the WG when it is formed.

Best Regards,
Alexey

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 21 Feb 2020 12:23:34 -0500

The signing doc is mentioned in the milestones:

Milestones:

  Jun 2020 - Working group adoption of use cases document (will not be
  published as an RFC)

  Jun 2020 - Working group adoption of bundling document

  Jun 2020 - Working group adoption of security analysis document

  Jun 2020 - Working group adoption of privacy analysis document

  Jun 2020 - Working group adoption of signing document

  Sep 2021 - Submit the Bundling document to IESG

  Mar 2022 - Submit the Privacy analysis document to IESG

  Mar 2022 - Submit the Security analysis document to IESG

  Mar 2022 - Submit the Signing document to IESG

I can't focus enough for wordsmithing at the moment. So I'll withdraw my
other points.

Having spent a couple of years playing with this space I think that it is
actually quite constrained at a certain level that is a bit more abstract
than syntax but still involving the order in which information is
presented. If you write out all the maximal requirements, there is only
really one way to do it that makes sense.

The only thing that is innovative in my work (DARE) is the way I provide
for incremental encryption and the profiling I do on JOSE to provide RAILS
like fluency.

On Thu, Feb 20, 2020 at 5:14 AM Alexey Melnikov <[email-masked]>
wrote:

> If you have a means to publish a compound document as a book and you have
> a means to protect the privacy of that compound document, you have the
> I think the idea is to declare both out of scope, so I would rather not
> get into details of how DRM might be implemented using the format. So I
> suggest no change.
>
> I am not entirely clear where this text can be inserted. Can you suggest
> some specific text and where to insert it
>
>
> Also, I think that rather than a 'signing document', the group really has
> a syntax document and it is far from clear that there will be only one. My
> There is no mentioning of "signing document" in the charter. I think what
> you propose is a very reasonable thing to discuss in the WG when it is
> formed.
>
> Best Regards,
> Alexey
>

---

From: "Alexey Melnikov" <[email-masked]>
Date: Fri, 21 Feb 2020 17:26:56 +0000

Hi Phillip,

>  Jun 2020 - Working group adoption of signing document

Oh, I see. Yes, I think changing it to "syntax document" is reasonable.

Best Regards,
Alexey

> I can't focus enough for wordsmithing at the moment. So I'll withdraw my other points. 
> 
> Having spent a couple of years playing with this space I think that it is actually quite constrained at a certain level that is a bit more abstract than syntax but still involving the order in which information is presented. If you write out all the maximal requirements, there is only really one way to do it that makes sense.
> 
> The only thing that is innovative in my work (DARE) is the way I provide for incremental encryption and the profiling I do on JOSE to provide RAILS like fluency.
> 
> 
> On Thu, Feb 20, 2020 at 5:14 AM Alexey Melnikov <[email-masked]> wrote:
>> __
>> Hi Phillip,

---

From: "Alexey Melnikov" <[email-masked]>
Date: Fri, 21 Feb 2020 17:39:31 +0000

On Fri, Feb 21, 2020, at 5:26 PM, Alexey Melnikov wrote:
> Oh, I see. Yes, I think changing it to "syntax document" is reasonable..
Sorry, I replied too soon. Bundling document is the syntax document. I don't think we need to require a single signing document from the WG, I am happy for the WG to make this decision.

Anyway, I will try to improve milestones.

Best Regards,
Alexey