Re: Documenting implicit assumptions?

Great Nathan.  Thanks for bringing these points up.

For each of the questions you put below, create a new thread. Perhaps start 
with 1 or two a day at most so that we don't get overwhelmed, and that we can
follow the conversations. Remember if you want your points to stick you need 
members  of this list to have time to read them and to follow the conversation. 
Some member are in different time zones, some of them are employed and have 
other priorities, so don't make them too long. Remember that not everybody knows 
the WebID protocol by heart so use references to the current protocol to make 
your point. I notice that the current spec is missing a UML sequence diagram, 
so we can use the one on the http://esw.w3.org/foaf+ssl page for the moment. 
(I'll file a bug report for this)

So for example for  "no equivalent of certificate revocation or password reset"
explain what you mean by this in detail. At what point of the protocol does this
become an issue and why? What is this needed for? etc.... Write this out with as
little presuppositions as possible as to the knowledge level of the people reading
your e-mails. 

I am sure that after we do a couple of these, we will find some template we can put 
together for these.

Henry


On 31 Jan 2011, at 20:59, Nathan wrote:

> 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 HTTP.
> 
> 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.
> 
> Best,
> 
> Nathan

Social Web Architect
http://bblfish.net/

Received on Monday, 31 January 2011 22:30:56 UTC