- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Tue, 22 Jul 2014 21:41:08 -0400
- To: Peter Williams <home_pw@msn.com>, "public-rww@w3.org" <public-rww@w3.org>
- CC: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
- Message-ID: <53CF12B4.1070801@openlinksw.com>
On 7/22/14 8:37 PM, Peter Williams wrote: > anytime an SSL session is created (based on a webid authentication > event), dont suppose a “private” resource could be created - bearing > the sessionid number? Only if some implementation decides to act that way. Likewise, an ACL can be derived from an combination of relations in an identity card (be it the x.509 cert used during the handshake and/or public profile document at some later stage). > > > The point is to showcase, widely, how easy it is to track ssl sessions > (as a generalized privacy buster) and identity inferences from them. Since this shouldn't happen by default, I don't think we have the generalized privacy buster. In fact, we have the opposite since actual ACLs don't need to be shared with a human driving a Web browser, as part of the protected resource access workflow. Example: Let's say I have a picture that I only want to share with you. My ACL doesn't have to be based solely on the fact that you present an X.509 cert bearing a WebID that triangulates back to a profile document that mirrors the relations in the x.509 cert. etc.. You (the browser user) has little knowledge over the actual ACLs applied to a protected resource, let alone the sniffers out there, assuming my actual ACLs aren't revealed in a compromising way. SPARQL ASK queries over Linked Data will drive the more sophisticated ACLs, declaratively. > > with that set of reference points, its also a means, on a massive > scale, to let ssl session management - now represented as just another > referencible resource - protect metadata-based infrastructure - from > systemic metadata-trawling vulnerabilities. Yes, ultimately, but (modulo typos) your suggestion would get the opposite of what you state above, if I am understanding you correctly :-) > > Cannot say how, in short missive, but assume that layers of security > leverage the fixed point of sessions to create complex worlds through > which other channels of metadata can be passed. I assume the worst, there's a little more to showcase re. ACLs + Encryption at Rest (EAR) once we get some basic interop going. Ultimately, you will need to not only navigate the ACLs that protect a document, you will also have to be able to decrypt the document's content :-) Kingsley > > > Sent from Surface Pro > > *From:* peter Msn <mailto:home_pw@msn.com> > *Sent:* Tuesday, July 22, 2014 11:01 AM > *To:* Kingsley Idehen <mailto:kidehen@openlinksw.com>, > public-rww@w3.org <mailto:public-rww@w3.org> > *Cc:* public-ldp-wg@w3.org <mailto:public-ldp-wg@w3.org> > > https://homepw.rww.io/storage/mb/ch1/post1 > > I think this is your breakthrough moment (though Ive said that BEFORE…) > > For the first time, that https scheme is more than just a way of > making an tls transport happen. Now its a real URI, with true > https “semantics” around identity and referencing. > > Well done. Took 5+ years for webbt processes to do their thing, but > then you were collectively undoing 20 years of wrong thinking - > probably due to the web being overly controlled by IETF at the > protocol level (and its “strange crypto” setup, to cite Vint Cert). > > Somebody pat Henry on the back to, for teaching even the likes of me > the pure logic approach of this stuff. I was taught it all, at school, > but never “really got stuff like ‘denotational semantics’”. This makes > it obvious - and easy. > > Sent from Surface Pro > > *From:* Kingsley Idehen <mailto:kidehen@openlinksw.com> > *Sent:* Tuesday, July 22, 2014 10:40 AM > *To:* peter Msn <mailto:home_pw@msn.com>, public-rww@w3.org > <mailto:public-rww@w3.org> > *Cc:* public-ldp-wg@w3.org <mailto:public-ldp-wg@w3.org> > > On 7/22/14 1:16 PM, Peter Williams wrote: > > http://yorkporc.wordpress.com/2014/07/22/cimba-co/ > > worked fine, baring some 25 year old issues that noone wants > solved (since it puts W3C in the hot seat on crypto complicity). > Easy to work around. > > Windows 8.1 phone trial not a success (being a communications > device, more regulated that an PC for crypto). Windows 8.1 PC did > fine. > > > Peter, > > Please share the URI of your sample post since I see you successfully > reached that point. Once you share the URI that denotes your sample > post we can simply lookup up the rest, pun intended too :-) > > > Kingsley > > > > Sent from Surface Pro > > *From:* Kingsley Idehen <mailto:kidehen@openlinksw.com> > *Sent:* Tuesday, July 22, 2014 8:53 AM > *To:* public-rww@w3.org <mailto:public-rww@w3.org> > *Cc:* public-ldp-wg@w3.org <mailto:public-ldp-wg@w3.org>, peter > Msn <mailto:home_pw@msn.com> > > On 7/22/14 11:23 AM, Melvin Carvalho wrote: > > > You're almost there! Now you just need to create a > channel for your posts. > > > Did you attempt to create a new channel? > > > One other thing > > Logging in to http://cimba.co > > > I am not on there in an obvious way i.e., not via the WebIDs you > know (see comments below). I'll connect back there one this side > of interop is done, by that I mean: > > 1. Support for any WebID re. CIMBA -- as opposed to WebIDs where > rww.io as the Idp > 2. Loosely coupling the CIMBA app, deployment platform Virtuoso, > and actual data storage -- e.g., Dropbox, Google Drive, OneDrive etc.. > 3. Having Public mean "Public" as opposed to "Public with a WebID > that's verifiable using WebID-TLS" -- by not being really Public > the user has to manually make each blog post "Really Public" etc.. > > > I can find 3 profiles for you ( 1 normal, 2 QA) in webizen, > but I cannot find any channels in them. When I click your > name, I get the spinner which never completes. > > > Yes, because that WebID resolves to document hosted by an instance > that didn't initially work with CIMBA. Note the comments in our > pull request [1] > > [1] https://github.com/linkeddata/cimba/pull/19 > > -- > Regards, > > Kingsley Idehen > Founder & CEO > OpenLink Software > Company Web:http://www.openlinksw.com > Personal Weblog 1:http://kidehen.blogspot.com > Personal Weblog 2:http://www.openlinksw.com/blog/~kidehen > Twitter Profile:https://twitter.com/kidehen > Google+ Profile:https://plus.google.com/+KingsleyIdehen/about > LinkedIn Profile:http://www.linkedin.com/in/kidehen > Personal WebID:http://kingsley.idehen.net/dataspace/person/kidehen#this > > > > -- > Regards, > > Kingsley Idehen > Founder & CEO > OpenLink Software > Company Web:http://www.openlinksw.com > Personal Weblog 1:http://kidehen.blogspot.com > Personal Weblog 2:http://www.openlinksw.com/blog/~kidehen > Twitter Profile:https://twitter.com/kidehen > Google+ Profile:https://plus.google.com/+KingsleyIdehen/about > LinkedIn Profile:http://www.linkedin.com/in/kidehen > Personal WebID:http://kingsley.idehen.net/dataspace/person/kidehen#this -- Regards, Kingsley Idehen Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog 1: http://kidehen.blogspot.com Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen Twitter Profile: https://twitter.com/kidehen Google+ Profile: https://plus.google.com/+KingsleyIdehen/about LinkedIn Profile: http://www.linkedin.com/in/kidehen Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Wednesday, 23 July 2014 01:41:32 UTC