Re: Documenting implicit assumptions?

Henry Story wrote:
> On 31 Jan 2011, at 19:19, Nathan wrote:
>> Henry,
>> Think of it as if you have invented the wheel, we have seen that it is great and useful, and now is the time to consider whether that wheel needs spokes, a hub for the axle, bearings, a tyre, an inner tube, should those elements be plastic, metal, rubber, wood, stone, do we need different kinds of wheels for different use cases and so forth.
> Nathan, just put forward some proposal with if possible detailed text for the spec, howto, 
> or whatever, and proposals for changes you wish to put forward. Make those changes clear 
> and concise. Spell  out why you think they are needed, what issue the change will solve.
> 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...
> We have limited time, so take the most important issues you have first, and put those 
> forward. 

A few off the top of my head then:

no equivalent of certificate revocation or password reset

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

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.

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.

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

is subjectAltName IRI compatible?

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.

use of content negotiation on webid URI dereferencing limits usage to 

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

no required serialization makes interoperability nigh on impossible.

Sorry Henry, I can't produce "text for the spec, howto or whatever" 
with issues like this, as you can see. This is just a tertiary list 
from the top of my head, there are countless more I've not thought and 
others I haven't included that have been mentioned previously.

Back to the point, it would be very nice to approach this as a group 
dissertation, I'm sure we can all agree that Roy T. Fielding's REST 
dissertation is most useful because it analyses everything related, 
defines some design trade-offs, uses them to place some constraints to 
make an optimized architecture, then applies that architecture to HTTP 
and URI in order to find mismatches. We could easily take the same 
approach with WebID, consider everything properly, weight things, up, 
apply to FOAF+SSL / WebID 1.0 to create a great Web Identity solution.



Received on Monday, 31 January 2011 20:01:54 UTC