W3C home > Mailing lists > Public > public-xg-webid@w3.org > February 2011

Re: Documenting implicit assumptions?

From: Nathan <nathan@webr3.org>
Date: Tue, 01 Feb 2011 11:53:03 +0000
Message-ID: <4D47F41F.90000@webr3.org>
To: Manu Sporny <msporny@digitalbazaar.com>
CC: public-xg-webid@w3.org
Manu Sporny wrote:
> 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.

Indeed, that's what I was trying to convey, I don't see any point in 
tweaking spec text and ontologies when the there are fundamental 
design issues, and alternatives to address.

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

Yes - I'm not trying to say "I think X should be like Y", I'm sayign 
that there are design issues, and that I think it would be incredibly 
valuable to have everybody raise, share and discuss options for each 
element of the protocol, including alternative flows.

All we need to do is establish a Web Identifier (URI/name) for an 
Agent - and there are /many/ ways to do that.

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

yup, better now than a full rewrite or a series of versions, bc 
breaks, and competing protocols which cover the elements we didn't 
take the time to consider, or take alternative approaches we didn't 
even consider.

> (several years from now).

so long as several doesn't mean "seven or more"!

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

added as ISSUE-22

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

added as ISSUE-23

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

added as ISSUE-24

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

added as ISSUE-21

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

dropped notion of "it's hard" and detailed in more info w/ an 
alternative to SAN under ISSUE-19

>> 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 
>> use of content negotiation on webid URI dereferencing limits usage to HTTP.
> +0 
>> use of RDF requires RDF support, use of XML requires XML support, use of
>> HTML+RDFa requires DOM and RDFa support.
> +1
>> no required serialization makes interoperability nigh on impossible.
> +1

all the above are the same issue really, and I've /not/ added it as an 
issue yet, if nobody else does in a few days then I will.

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

done, however I want to stress that I've only added issues which I'm 
familiar with, and selected ones which will promote discussion and the 
notion that we /do/ have options - they are all very valid issues, but 
I'm hoping that in the initial weeks at least they'll promote 
discussion and the identification of options / requirements / 
use-cases, rather than result in fixed resolutions.

Best,

Nathan
Received on Tuesday, 1 February 2011 11:54:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:06:22 UTC