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

RE: Cache, Cert Creation and Keychains

From: Peter Williams <home_pw@msn.com>
Date: Thu, 1 Dec 2011 10:24:41 -0800
Message-ID: <SNT143-W3724D8B66BE9CC7D94FFD392B10@phx.gbl>
To: <henry.story@bblfish.net>
CC: "public-xg-webid@w3.org" <public-xg-webid@w3.org>

 Just understand you stepped on a landmine. There are forces who WISH there to be key agents, distinct from SSl clients. And, they want it BUILT IN to every crypto protocol. I dont mind...(personally) so long as its all VERY transparent, and not mandatory. unless something about the nature of webid validation requires the call out, perhaps reconsider. The spec should be getting less text day by day, not more. Try to decide if the spec exists to educate folks about the semantic web, or just do a superb job of TODAY enabling webid validation protocol to go live (for a 1 million users, day). When you consider the ASK, you get a reall hard decision, for example. Do you bias it towards older semantic web tools (so as to maximise easy uptake), or sparql libraries with some more modern feature (that not all libraries have).  Thats a really tough call (and tests the metal of a chair). SOmetimes you make tradeoffs, promoting such as SPARQL protocol SERVERS AND requiring folks use the more modern ASK syntax (that presumes a feature of SPARQL). Theen you get both worlds (deeming it vital/better to start webid with that more modern SPARQ), but PRMOTE the fallback (using sparql servers, to remote the ASK processor). The spec states this tradeoff as part of the rationale of why sparal protocol servers are now more prominent (that THAT set of tradeoffs). This is what will turns this effort from being an incubator report into something worythy of being a formal working group - that will have lots of vendors (continuously squabbling, if normal rules apply).     
 From: henry.story@bblfish.net
Date: Thu, 1 Dec 2011 19:07:38 +0100
CC: public-xg-webid@w3.org
To: home_pw@msn.com
Subject: Re: Cache, Cert Creation and Keychains

On 1 Dec 2011, at 18:55, Peter Williams wrote:the revision introduces concepts that are alien to most of us, and having no bearing in requirements analaysis of the last year - at least as documented in mailing list minutes of meetings and other comments.
Remember, your PRIMARY audience is a security engineer. If it says "key chain agent" and there exists a "protocol" between client and such agent, this is all  very material to the programmer.
You just expanded the scope, introducing a protocol that didnt even exist till yesterday. When someone looks at my client (IE) they will find no key chain, and no "key chain agent" and no protocol between the IE ssl client (a library called sspiclient) and said agent. My code now looks like its missing elements (i..e is incomplete).
Now, reading between the lines, I suspect I can guess who is driving that change (and the very phrasing gives a STRONG hint of what traditional "cryptopolitical issue" is driving its "introduction").  I can also note the shift in technical language use in the last 3 weeks. Its better, and much tighter. The reviewers are doing a good job. The language shift also gives hints about the new mindset.

there's no politics. I just thought it would be good to distinguish the parts that own the private keys, from the applications that use them. I think all applications do that on all operating systems. There may be a better word thank keychain. 

> From: henry.story@bblfish.net
> Date: Thu, 1 Dec 2011 17:16:51 +0100
> To: public-xg-webid@w3.org
> Subject: Cache, Cert Creation and Keychains
> I added text on all the above topics to the spec in mercurial.
> See the diff
> https://dvcs.w3.org/hg/WebID/rev/7a2859e0ab06
> Henry
> Social Web Architect
> http://bblfish.net/

Social Web Architect

Received on Thursday, 1 December 2011 18:25:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:39:50 UTC