- From: Henry Story <henry.story@bblfish.net>
- Date: Wed, 30 Nov 2011 16:51:47 +0100
- To: Kingsley Idehen <kidehen@openlinksw.com>
- Cc: public-xg-webid@w3.org
On 30 Nov 2011, at 16:42, Kingsley Idehen wrote: > On 11/30/11 10:08 AM, Peter Williams wrote: >> >> given copies of the public key exist in a billion http caches, HOW in semantic web and linked data *culture* does "disablement" occur? It needs to say. I doubt this sepc will be read by mom and pop users. It's far too technical. Im not sure a vendor would know what to do or to measure, either. >> >> >> >> Theft of a .p12 file export of a browser (*or platform) credential store typically copies the private key within (since most PC security systems use software crypto). Once its stolen, like most IP its hard to get all the copies back. > > In the Linked Data realm, you drop the relation in your data space that associates your WebID with the public key in the missing .p12. Same applies to Certs in keychain/keystores of your host OS. Ditto cryto keys. > > The real beauty of WebID is that I can delete relations with alacrity across my IdP data spaces. I don't have to go to hell an back just because I've lost my private key. I think Peter is aware of this. What is missing is the text in the spec to explain this (though it is suggested in a number of places) I'll add this after I have done a bit of coding, unless someone wants to try their hand at this do this. > > >> Getting assurance you have all the copies is essentially impossible, for the costs folks will typically bear. > > See comment above. Its a simple delete. Basically, another example of why I felt Twitter was an important IdP, just delete our tweet. The same applies to Blog spaces, delete the blog post. > >> Its irrelevant whether its password protected (and that the password is a secret from which a data encryption key is drived, used in an AES encipherment mechianism within .p12).Compromise means "loss of control" and inability to assign risk metrics. > > See comments above. > >> >> >> >> Compromise recovery (vs revocation of crredentials for access controls" in key management is basically what distinguish a Lexus from a Ford. Key distribution is what a webid profile does, sitting on some blog site firing packets out >> >> > Yes, and with a RWW aspect taking shape thanks to many Web 2.0 apps, deletion of the "mirrored claims" is trivial. > >> >> >> >> be careful when saying vacous things such as :"citizens of the world are responsible for the future of the human race, and when noticing that others are not eating well, users need to take action to make distribution of the the food supply more fair." Its tempting to be use idealisms, to cover up lack of professional engineering. >> In many corporate use cases, Bob will not be responsible in the manner suggested, and BOB will NOT be the party doing the compromise recovery (Bob will run away, or be fired, typically). > > Bob needs to understand WebID conceptually. I had a chat with Henry yesterday about this aspect of the WebID spec. Specs should always have Conceptual and Technical sections. We are going to fix the missing conceptual stuff. Once done, we also have foundation for the concerns to outline re. what Bob should be digest en route to WebID exploration and eventual exploitation etc.. > >> Decide if corporate culture IS or IS NOT a part of the community of users anticipated by webid in the next 3 years. Be clear in terminology, and tone. Appeal to an audience (other than 10 developers of code). > > In my eyes, this is a major solution for enterprises. Simply major! > >> >> >> "+<dd>Bob is an agent who uses a<tref>Client</tref> to connect to<tref>Alice</tref>'s Service, and who is responsible for the private key the<tref>Client</tref> uses to authenticate to<tref>Service</tref>s. >> 3.23 +If he notices the private key was compromised he needs to take action to disable the public key." >> >> >> >> I notice that the spec draft can no longer be tagged as being anti-CA, since it defines a CA for the first time. >> >> >> >> Its focus on TLS rather than https (the protocol identified by the scheme) is unfortunate. https is not the same as TLS, as https uses SSL sessions in a particular way for hypermedia. Web services over HTTP typically use TLS without conforming to the https scheme used in mozilla-class clients. > > I think we can work on the conceptual spec and set appropriate tone for target audiences. > > Great points you've raised! > > Kingsley >> >> >> >> ---------------------------------------- >>> From: henry.story@bblfish.net >>> Date: Wed, 30 Nov 2011 14:58:02 +0100 >>> To: public-xg-webid@w3.org >>> Subject: TLS-Light >>> >>> I have updated the spec with the notion of TLS-Light . See the new spec in mercurial and the following diff >>> >>> https://dvcs.w3.org/hg/WebID/rev/3012b63e69f3 >>> >>> The idea is to clarify that the TLS service we use is a simplified TLS service: therefore than any existing TLS service should be useable: i.e. no big backend infrastructure changes needed. >>> >>> Henry >>> >>> Social Web Architect >>> http://bblfish.net/ >>> >>> > > > -- > > Regards, > > Kingsley Idehen > Founder& CEO > OpenLink Software > Company Web: http://www.openlinksw.com > Personal Weblog: http://www.openlinksw.com/blog/~kidehen > Twitter/Identi.ca handle: @kidehen > Google+ Profile: https://plus.google.com/112399767740508618350/about > LinkedIn Profile: http://www.linkedin.com/in/kidehen > > > > > > Social Web Architect http://bblfish.net/
Received on Wednesday, 30 November 2011 15:52:40 UTC