Re: "Microsoft Access" for RDF?

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. Javascript
2. 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) Vocabulary
5. 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