On 2/24/15 6:07 AM, Graham Klyne wrote:
Hi Kingsley,In https://lists.w3.org/Archives/Public/public-lod/2015Feb/0116.html You said, re Annalist:My enhancement requests would be that you consider supporting of at least one of the following, in regards to storage I/O: 1. LDP 2. WebDAV 3. SPARQL Graph Protocol 4. SPARQL 1.1 Insert, Update, Delete. As for Access Controls on the target storage destinations, don't worry about that in the RDF editor itself, leave that to the storage provider [1] that supports any combination of the protocols above.Thanks for you comments and feedback - I've taken note of them.My original (and current) plan is to provide HTTP access (GET/PUT/POST/etc) with a little bit of WebDAV to handle "directory" content enumeration., which I think is consistent with your suggestion (cf. [1]).
Yes.
The other options you mention are not ruled out.
Okay.
You say I shouldn't worry too much about access control, but leave that to the back-end store. If by this you mean *just* access control, then that makes sense to me.
Read and Write modalities scoped to an identity principal.
A challenge I face is to understand what authentication tokens are widely supported by existing HTTP stores.
Most will support digest authentication. For more sophisticated solutions you should consider WebID-TLS [1] and WebACL [2] which simply boils down to servers determining identity principals and resource privileges via relations in a WebID-Profile [3] document and a server's WebACL doc.
You can also bolt OAuth on to WebDAV, as we have, but it may be a lot of work.
BTW -- we do have a generic Authentication Layer in Virtuoso that supports Digest Authentication, WebID-TLS, basic PKIX+TLS, OpenID, and OAuth. We are even planning to decouple the aforementioned module from Virtuoso via a Javascript library that will be released in Open Source form to Github. Only hold-up is prioritization, so I can provide a firm ETA.
Annalist itself uses OpenID Connect (ala Google+, etc) is its main authentication mechanism, so I cannot assume that I have access to original user credentials to construct arbitrary security tokens.I had been thinking that something based on OAuth2 might be appropriate (I looked at UMA [2], had some problems with it as a total solution, but I might be able to use some of its elements).
See comment above.
I took a look at the link you provided, but there seem to be a lot of moving parts and couldn't really figure out what you were describing there.
It looks like that on the surface, but it simply boils down to: 1. Javascript2. Ajar (Asynchronous JavaScript and RDF) -- TimBL tried to kick of this "Ajar" meme a few years ago with limited uptake, but its darn neat!)
3. Terms for making Identity Claims from a Certificate Vocabulary 4. A Storage relation described by a Personal Information (PIM) Vocabulary5. WebID-Profile document that includes relations based on terms from the PIM and Certificate vocabularies.
I re-read my original post [4], and realized its could be clearer, so I've tweaked it a little. Thanks for bringing the "many moving parts" perception to my attention.
Links: [1] http://www.w3.org/2005/Incubator/webid/spec/tls -- WebID-TLS protocol[2] http://linkeddata.uriburner.com/c/9D3D4FSF -- a Web Access Control Vocabulary [3] http://www.w3.org/2005/Incubator/webid/spec/identity/#webid-profile-vocabulary -- WebID Profile Document [4] http://kidehen.blogspot.com/2014/07/loosely-coupled-read-write-interactions.html -- slightly revised edition.
Kingsley
Thanks! #g -- [1] https://github.com/gklyne/annalist/issues/32[2] http://en.wikipedia.org/wiki/User-Managed_Access, http://kantarainitiative.org/confluence/display/uma/Home
-- 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
smime.p7s
Description: S/MIME Cryptographic Signature
