Re: Documenting implicit assumptions?

On 01/31/2011 02:59 PM, Nathan wrote:
> Henry Story wrote:
>> Then we can have something to agree with, criticise, accept or shoot
>> down. We will need to think about the implications of your proposal,
>> test the idea with real code, see if it interoperates, if it is easy
>> to implement or not, etc... etc...

First, however, I think that the XG needs to record that there are
fundamental design concerns with the protocol as it stands right now.
These fundamental design issues aren't something new - they've been
around for quite some time, have been raised repeatedly, and there seems
to be a certain unwillingness to record the worst of them as design issues.

Recording current design issues helps to write use cases and
requirements (which are both deliverables of the WebID XG).

It doesn't sound like Nathan is proposing anything specific - he's
raising design issues, which could easily be turned into use cases and
requirements.

>> We have limited time, so take the most important issues you have
>> first, and put those forward. 

I'm not convinced that this will result in the best output of the WebID
XG. Yes, time is limited. However, if there are X fundamental design
flaws, the group will have to address all X of them before Last Call
(several years from now).

> A few off the top of my head then:
> 
> no equivalent of certificate revocation or password reset

+1 - a very big issue. Not to mention password reset, if you allow pure
live-on-the-web public/private keys.

> profiles are susceptible to man in the middle attacks (changing profile
> content on the fly at intermediaries)

+1 - Digital signature support? Require HTTPS or some sort of secure
communication channel?

> privacy is not guaranteed (an intermediary, or a "webid/profile host",
> can detect a request from an server (say a bank, a private site, an
> adult site, a gambling site) to a users webid URI and thus know the user
> has attempted to login on said site.

+1 - How is privacy protected via WebID? What protocols should be used
in order to ensure this protection? Is it a MUST or SHOULD in the spec?

> the notion of public key holder owns to webid uri (on which the protocol
> is currently predicated) is temporally weak, that is to say, the
> public/private key holder is not proven to still own / have write
> permissions to the webid resource.

+1 - How do you protect against temporal attacks like this on WebID?

> subjectAltName tightly binds WebID to x509v3 certificates, x509v3
> certificates with subjectAltName extensions are very hard to produce
> with common libraries (unless you have a custom setup - e.g. openssl).

-1 - Our company hasn't had an issue generating certificates on all the
major platforms for subjectAltName, and really - this is a fairly simple
application to write. Not concerned about this one.

> is subjectAltName IRI compatible?

-1 - It's an opaque octet stream, so we think so, but that's up to the
group to decide.

> format of public key in profile requires libraries to extract component
> parts of public keys, type of properties used is not well defined,
> modulus requires normalization for comparison.

+1 - We've encoded the ASCII armored value and stuffed that directly
into the RDF/RDFa documents. It's much easier to deal with for
implementers and makes using the data with libraries like openssl far
easier.

> use of content negotiation on webid URI dereferencing limits usage to HTTP.

+0 - which specific limitations are you talking about Nathan? What other
protocol should WebID run on top of?

> use of RDF requires RDF support, use of XML requires XML support, use of
> HTML+RDFa requires DOM and RDFa support.

+1 - should discuss the alternatives. One minor clarification -
/well-formed/ HTML+RDFa only requires XML and RDFa support - no DOM
necessary (but that's a technical nit that may not have any sway on a
real-world application).

> no required serialization makes interoperability nigh on impossible.

+1 - Yes, please don't make this some sort of abstract document that is
useless to implementers. Tell the world exactly how to implement
inter-operable WebID applications. One of the things that this community
keeps doing is "blue skying" with WebID. "Oh, WebID/FOAF+SSL is so great
that it can work with a large number of different technology
combinations!".

When you get ready to write the final spec, please don't blue sky - just
give us something we can implement in a manner that is unambiguous.
Please don't give us a great number of things to pick from - that's
going to really hurt implementations.

If that means you limit it to TURTLE/x509/HTTPS/whatever then so be it -
just please require /some/ specific protocol and /some/ specific
serialization format.

I'd also add the following design flaws to the current proposed protocol:

* No way to use the technology from a public terminal.
* Tie to browser UIs is too fragile and depends on the browser
  manufacturer's "getting it" in order to make WebID successful.
* Loss of UI control from a website which prevents UI innovations to
  happen parallel to WebID.

> Back to the point, it would be very nice to approach this as a group
> dissertation.

+1 to this as well. This is not the first time the issues above have
been raised - there have been numerous, very long threads on some of
these issues above. However, I couldn't find most of the issues above in
the XG issue tracker.

Why can't Nathan just add these issues to the WebID XG ISSUE tracker and
you go from there? That way, the discussion has an issue associated with
it from the start, it's easy to track, and we don't have to worry about
getting lost in the churn of discussion.

Nathan - if/when you do add them to the issue tracker, please do write
at least a paragraph on each issue. Henry's suggestions on how to start
each discussion were good. However, adding an issue with the text to the
issue tracker will automatically start a new thread on the mailing list.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Linked Data in JSON
http://digitalbazaar.com/2010/10/30/json-ld/

Received on Tuesday, 1 February 2011 04:44:16 UTC