Re: *Possible* additional use cases

> On 14 Oct 2016, at 14:49, Leonard Rosenthol <lrosenth@adobe.com> wrote:
> 
> >Signing a (P)WP
> >
> While it might be possible for professional publishers to obtain the necessary cryptographic credentials to sign all of their publications – it’s not something that will work in the world of “ad-hoc publications”.  Even amongst the members of the IG (who are technically savvy people!), I would bet that very few have certificates.  And while it is possible to create a “self-signed” certificate, such a cert wouldn't be useful for this use case (though it would be useful for the “integrity check” use case).

That is correct.

But I realize that the use case text may have been incorrect. I do not think that the use case says that this/these features must be available for _all_ publications. What it says that it should be possible for an author/publisher to do so, ie, it _may_ be used when that is a necessary feature. Ie, the Legal publisher in the UC would probably have such credentials and could do it, whereas if you or I produce a WP, we may not have the right tools, and/or we would not care to use it.

> 
> 
> But yes, we can revisit them all when we have the revised version from Heather.
> 

+1

Ivan

> Leonard
> 
> From: Ivan Herman <ivan@w3.org>
> Date: Friday, October 14, 2016 at 7:26 AM
> To: Leonard Rosenthol <lrosenth@adobe.com>
> Cc: Garth Conboy <garth@google.com>, W3C Digital Publishing IG <public-digipub-ig@w3.org>
> Subject: Re: *Possible* additional use cases
> 
> 
>> On 14 Oct 2016, at 02:18, Leonard Rosenthol <lrosenth@adobe.com <mailto:lrosenth@adobe.com>> wrote:
>> 
> 
> I think, as I said to Garth, the final decision on these (and possibly others) should be taken only when the full dedupe+reorg is done and we can have a fresh look at the result. It is also tied to the issues in general.
> 
> 
>> #1 – we had one of these use cases and I removed it as it was very tied to the packaged approach.  Your version is better, but still needs a bit of wordsmithing before it could apply to both packaged and non-packaged.
>> 
> 
> Agreed. And maybe we should have two, once for packaging and one for the non-packaged (I am not sure).
> 
>> #2 – Agreed with Garth.  It’s a very good idea, but very difficult to accomplish.  It also is only tied to the package world (and in fact is the crux of the security discussion problems).
> 
> Hm. I am not an expert but… if the publisher hashed all resources, creates a hash of all the hashes, then cryptographically signs the result, and if both the hash values and the public key used for the signature is published on some unforgeable place (eg, blockchain), wouldn't that be a workable solution?
> 
> Maybe not, but I am not sure whether it is *very* difficult to accomplish. And even if it is, the use case is relevant, though may not be achievable in version 1...
> 
>> 
>> #3 – We had some of these in the original set and I removed and/or rewrote them as Marcos, Mike and others made it clear that we should NOT be putting anything on User Agents, but instead should focus on the WP itself.   I’d like to keep to that.
>> 
> 
> Let us come back to this. Since then a lot of discussion happened in terms of the (P)WP processors, their relationships to browsers, etc, and this one may be the source of an important design principle. Let us look at this with a fresh eye.
> 
> (One example which was, I believe, raised during the discussion: if the return of a WP URI is a manifest file, then only browser that can interpret the manifest can do anything with this. On the other hand, if the return is an HTML file that includes (a) a link to the manifest and (b) contains at least a rudimentary TOC, this could be interpreted by any browser. This is the type of things that we should, in my view, keep an eye on…)
> 
>> #4 – That’s already in there in a few other use cases (certainly distribution but a couple other ones as well)
>> 
> 
> If indeed so, that is fine!
> 
> Ivan
> 
> 
>> 
>> Leonard
>> 
>> From: Garth Conboy <garth@google.com <mailto:garth@google.com>>
>> Date: Thursday, October 13, 2016 at 2:13 PM
>> To: Ivan Herman <ivan@w3.org <mailto:ivan@w3.org>>
>> Cc: W3C Digital Publishing IG <public-digipub-ig@w3.org <mailto:public-digipub-ig@w3.org>>
>> Subject: Re: *Possible* additional use cases
>> Resent-From: <public-digipub-ig@w3.org <mailto:public-digipub-ig@w3.org>>
>> Resent-Date: Thursday, October 13, 2016 at 2:13 PM
>> 
>> Hi Ivan,
>> 
>> Thanks.  Is you plan to discuss these on the mailing list or have them be topics for a future DPUB IG Call?
>> 
>> My first off the cuff reactions to each (from top to bottom, on a scale of one [don't include] to ten [certainly include]) would be:
>> 
>> #1 - 7 (assuming the PWP has been authored in such a manor to provide this data)
>> #2 - 2 (doesn't seem practical, given our online, offline, off-web use cases; though perhaps there is an authoring time solution)
>> #3 - 5 (perhaps noble)
>> #4 - 9 (forward compatibility with the existing EPUB ecosystem)
>> 
>> Best,
>>    Garth
>> 
>> 
>> On Thu, Oct 13, 2016 at 4:56 AM, Ivan Herman <ivan@w3.org <mailto:ivan@w3.org>> wrote:
>>> Dear all,
>>> 
>>> as we said on our last call, there may be some new use cases that popped up during the github discussions of the last month. I went through the open issues to see what were raised there. I haven't yet compare it to the latest version of the UCR to check whether these are really new requirements (at first glance they look like it) also because that document is still kind of a moving target. However, I did not want to unnecessarily pollute the github repo either; so I copy the 4 use cases I extracted in the mail below for first sanity check. I will put as explicit issues the ones that we agree upon as o.k. (any linguistic/grammatical changes are welcome); we can then take care of them when both Leonard and Heather declare victory in the big set of changes.
>>> 
>>> With that, here they are:
>>> 
>>> Req XXX: the user agent should be able to verify that the (P)WP has not been tampered with at delivery.
>>> 
>>> The author/publisher should be able to provide information (cryptographic hash, blockchain entry, etc.) usable by a user agent to check the content is genuine and has not been tampered with.
>>> 
>>> Use Case:
>>> 
>>> - LegalPublisher Ltd. regularly publishes the official legal texts and regulation as decided by the local government. Michael, who is a lawyer, has access to these documents via his law firm, and uses them for his cases; to do so, he must be 100% sure that the publication he accesses faithfully reproduces the latest governmental decisions.
>>> 
>>> (Related to, and mentioned in issue #110)
>>> 
>>> 
>>> ----
>>> 
>>> Req XXX: the user agent should be able to verify the exact origin of the publication.
>>> 
>>> The author/publisher should be able to provide information (signature, identifier, etc) that can be served, and checked, as a unique identifier of the origin.
>>> 
>>> Use Case:
>>> 
>>> - Michael, who is a lawyer, and uses the publications of LegalPublisher Ltd., must be 100% sure that the publication he uses for his case has indeed been published by LegalPublisher Ltd., and not by a possible third party.
>>> 
>>> (Related to, and mentioned in issue #110)
>>> 
>>> ----
>>> 
>>> Req XXX: Any genuine user agent must be able to provide a usable view of a Web Publication albeit, possibly, without the full functionality that a WP provides
>>> 
>>> A full-blown, WP aware user agent may use a number of information incorporated, for example, in the manifest of a Web Publication (e.g., separate table of content control, visual representation of the publication's metadata information like ISBN-s or DOI-s, etc.). However, not all user agents are necessarily WP aware. Nevertheless, the structure of a Web Publication should provide a graceful degradation for these cases and not make the presentation of the publication impossible.
>>> 
>>> - Ossi has access to a technical Web Publication on the Web. However, he is working from behind a corporate firewall, which does not allow him to install the necessary browser extensions to manage all features of a Web Publication. Nevertheless, even without this extension, he is able to get to the essential information of the document which allows him to do his work.
>>> 
>>> (Related, albeit loosely, to issue #110)
>>> 
>>> ----
>>> 
>>> Req XXX: there is need to send a Web Publication from A to B over different media, not only Web protocols.
>>> 
>>> Use Case:
>>> 
>>> - Dave is reading Moby Dick on his tablet (at home with network connectivity). He then jumps on a plane with his good friend Tzviya. After having finished reading the book, he wants to lend it to Tzviya, so that she can start reading on her own tablet. They are both offline, but can exchange data with SD cards or Bluetooth.
>>> 
>>> (Related, albeit loosely, to issue #113)
>>> 
>>> Comments, please…
>>> 
>>> Thanks
>>> 
>>> Ivan
>>> 
>>> ----
>>> Ivan Herman, W3C
>>> Digital Publishing Technical Lead
>>> Home: http://www.w3.org/People/Ivan/ <http://www.w3.org/People/Ivan/>
>>> mobile: +31-641044153 <tel:%2B31-641044153>
>>> ORCID ID: http://orcid.org/0000-0003-0782-2704 <http://orcid.org/0000-0003-0782-2704>
>>> 
>>> 
>>> 
>>> 
>> 
>> 
> 
> 
> 
> ----
> Ivan Herman, W3C
> Digital Publishing Technical Lead
> Home: http://www.w3.org/People/Ivan/ <http://www.w3.org/People/Ivan/>
> mobile: +31-641044153
> ORCID ID: http://orcid.org/0000-0003-0782-2704 <http://orcid.org/0000-0003-0782-2704>
> 
> 
> 
> 


----
Ivan Herman, W3C
Digital Publishing Technical Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704