Re: Cache, Cert Creation and Keychains

On 7 Dec 2011, at 03:19, Peter Williams wrote:

> 
>  +<p>A <tref>WebID Certificate</tref> identifies the <tref>Subject</tref> alone and no one else, if and only if she is the only one to control the corresponding private key.
>  
>  
> I thought the URI was the crux of the web identity?

That is in section  "2.3  Disabling a WebID Certificate"
http://bblfish.net/tmp/2011/12/06/index-respec.html#disabling-a-webid-certificate

So we are considering there the issue of how to disable a particular WebID/public key relation, which people will usually understand as how to disable  a certificate, which is what they present when they need to "identify" themselves. So a certificate does identify people.


I also have a feeling that one can distinguish between Reference and Identity. Reference is the relation between a URI and the thing it refers to. Identity is the relation between two terms that identify some thing. So in maths

 2+3 = 5

We have 2 and 3 and 5 as referring terms and we also have the identity relation between 2+3 and 5 .

In our case we have the WebID as the referring term, and the relation he has to a public key as the identity.
So in our example

:bob cert:key :key1 .

Has two referring terms. :bob  and :key1, where :key1 refers directly to a mathematical object.
What creates the identity of bob is the relation between the referring term :bob and the description "knower of public key"

That is what identity is about.

Perhaps this is something that could go into the spec...

Henry

>  
> Here you are saying that webid certificates identify. Furthermore, you introduce "subject", adding a formal concept. just stick with client, server and Person.
>  
> we dont want certs at the heart of the model. We want certs to be some irrelevant old blob format that happens to convey a (public key, URI collection) couplet to an SSL server endpoint from a client. The SSL handshake that happens to tie HTTP requests and responses to the identified person, using the method of data origin authenticaiton.
>  
> The cert is NOT an assertion (its an irrelevant old blob format that will go away, one day). Its not a statement. Its not a representation. It not anything. Its now just a blobber, no different to base64.That it is signed, self-signed or not signed or signed by 512-bit RSA, is also NOT material to webid validation. If it is expired (assuming an assertion of expiry even exist), this has NO impact on webid validation or an assertion of identity by a person. The identifying and identification properties of a webid URI (as invented by Tim Berners Lee) do NOT depend on certs. the URI is the URI, and is a wholly self-contained notion of identitiy. Once represented as webid URI, it becomes a concept we can work with, and now validate truth of propositions about said webid vURI.
>  
> Tls client authn provides the server with data origin authentication, tying web usage to the identity established by the validation agent - performing the validation protocol. Said protocol is in the class of identity protocols. The crux of that specific class of all identity protocols is that the URI and its various semantics of de-referencing are all one needs for identification (on the web) of a person or other foaf agent.
>  
>  
>  
> From: henry.story@bblfish.net
> Date: Tue, 6 Dec 2011 16:58:40 +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.
> 
> https://dvcs.w3.org/hg/WebID/rev/5b0128d1dbd1
> 
> I have now updated the language so that it is clear that we are no trying to get into a debate about keychain protocols. Rather the notion of a KeyChain is added to help make certain distinctions that make certain questions disappear. It also is a lot closer to how software actually works.
> 
> A Key Chain agent can return certificates to authorized <tref>Clients</tref> and can sign cryptographic tokens with the corresponding key. This protocol does not specify where that agent is: it could be that the <tref>Client</tref> contains his own Key Chain or it could be that the Key Chain is a seperate process on the Operating System.
> 
> 
> 
>  
> 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.
>  
> 
>  
> > 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
> http://bblfish.net/

Social Web Architect
http://bblfish.net/