Re: Chartering work has started for a Linked Data Signature Working Group @W3C

On Fri, 4 Jun 2021 at 15:08, Manu Sporny <msporny@digitalbazaar.com> wrote:

> Peter F. Patel-Schneider wrote:
> > Oh no, I very much understand this point.  Implementers are free to
> > implement the algorithms in any way that they want so long as they
> conform
> > to the description of the algorithms.  But the provided code doesn't do
> > that.
>
> It does... roughly... and that's all that's required of an input document
> to a
> W3C WG. Nowhere in the W3C Chartering process does it say that all input
> documents have to be perfectly written and perfectly implemented to be
> used as
> input documents.
>
> Now, the point you're making might be: I don't think this is good enough
> and
> it needs more work, but that's quite vague and not actionable.
>
> For example, I've spent at least two weeks answering your questions,
> pointing
> out why your proposed attacks don't work, writing code for you, pointing
> out
> where things are implemented in source code, and still it doesn't seem like
> you're satisfied. I don't really know when you would be, or what point
> you're
> trying to make other than: "I don't think this document is ready." -- you
> need
> to provide a measure of when you would think it would be ready.
>
> If what you're trying to get at is that the algorithms might not be
> perfect as
> written, then sure... that's why there are issue markers all over that
> document. That is refinement that we expect to happen in a WG. We can spend
> time doing that work now, but then the complaints would be that we're
> going to
> be very inflexible when we get into a WG because we're not going to want
> any
> changes to the algorithm. W3C Membership doesn't want rubber-stamp
> processes
> put around specifications. Much of the conversation we've been having
> belongs
> in a WG. Questions like:
>
> 1) Do we want to support chained-signatures?
> 2) Do we want to support mixing set-signatures and
>    chained-signatures?
> 3) Do we want to provide any guidance about loading
>    remote contexts?
> 4) Do we want to speak to how one would protect
>    information that is referenced but not included
>    in the RDF Dataset?
>
> These are all questions for a WG and the input document is silent on most
> of
> it because it's not clear what people would want to see in the document
> (although, the discussion with you has been very illuminating on what we
> might
> want to speak to).
>
> RDF WGs have been launched with much less than what we have for the LDS WG,
> which include 1) peer reviewed mathematical proofs 2) specifications, 3)
> test
> suites, 4) multiple independent implementations, 5) pilot/production
> deployments, 6) integration into other W3C WG, and 7) 8+ years of work
> behind
> the work items.
>
> > It may be that what the code does do internally corresponds to the pieces
> > of the algorithm, but there needs to be a full implementation of the
> > algorithm.
>
> Why? What demands a full reference implementation of the algorithm that is
> external to an actual implementation? The argument seems to be: "Yeah,
> there
> are real implementations in products out there... but what I want to see
> is an
> implementation of the algorithms that would not be use to anyone except as
> a
> direct comparison between the algorithm in the specification and the
> implementation of that algorithm." -- and if that's what you're asking
> for...
> that is done during CR, if the WG would like to see something like that,
> and
> if someone steps forward to implement that.
>
> In the meantime, we have multiple implementations that implement the
> algorithms... and that seems far more useful as a demonstration than a
> pared
> down reference implementation. I will grant that it would be nice to have
> that
> reference implementation, but that's what it is: a nice to have by the time
> you're in CR, not a requirement for an input document to a Working Group.
>
> >> Yes, this is because the code I wrote for you refuses to go out to
> > the
> >> Internet and fetch random JSON-LD Contexts. This is a security
> > feature. If the
> >> software doesn't have a local vetted copy of the JSON-LD Context, it
> > throws an
> >> error.
> >
> > So the code doesn't implement that algorithm.
>
> That code has nothing to do with the algorithm. It's a protective measure
> that
> sits at a layer of abstraction above the algorithm.
>
> > The code might be more secure, it might be less secure, but what is
> needed
> > is a implementation of the algorithm.
>
> What you would like to see is a line-by-line implementation of the
> algorithm.
> That is clear at this point.
>
> That doesn't exist, it used to, but then people had to write software that
> was
> used in real world systems and so those implementations gained features
> that
> helped developers integrate the algorithm into their library toolchains.
>
> The end result of those libraries is the same, however... they canonicalize
> and sign inputs and produce the same outputs. We have multiple
> implementations
> that do that.
>
> It is not required that we provide a line-by-line clean room
> implementation of
> the exact algorithm in the specification. I will also note that this isn't
> even required to exit CR and go to REC. What you're requesting is well
> outside
> of the W3C Process.
>
> Like I said above, yes, it's a nice to have... yes, it's something you'd
> like
> to see... but it's certainly far from mandatory, even to get to REC.
>
> > I tried to run the code that is supposed to implement the algorithm (or
> at
> > least the closest code that I was provided).   It throws an exception on
> > valid inputs.  That's bad.  It doesn't matter whether these inputs are
> > dangerous.  Reference code should implement the algorithm, i.e., produce
> a
> > signed version of the document for any valid JSON-LD document.
>
> We disagree here. You were trying to do something dangerous when
> generating a
> digital signature and the software /I wrote/ prevented you from doing that.
>
> If you want to remove that safety and load that remote context and
> digitally
> sign using it, you can modify the source code to do an HTTP GET on the
> remote
> context and you will get a digital signature as a result. You will have
> built
> a foot gun that will almost certainly blow a developers foot off, but you
> can
> do that. I just won't help you write that software. :)



That does sound really really bad. Perhaps the WG charter should cover only
use of self-contained Linked Data / RDF format, eg Turtle/TRiG? And then
try to secure hypertext / multi-stakeholder RDF syntaxes (json-ld, grddl,
...) as a stretch goal rather than core business?

Dan


>
> -- manu
>
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> blog: Veres One Decentralized Identifier Blockchain Launches
> https://tinyurl.com/veres-one-launches
>
>
>