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

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. :)

-- 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

Received on Friday, 4 June 2021 14:00:58 UTC