- From: Olivier Rossel <olivier.rossel@gmail.com>
- Date: Thu, 27 Mar 2008 17:40:12 +0100
- To: "Semantic Web" <semantic-web@w3.org>
what about the data deliverer exposing to the world a set of SPARQL that can be run on his data (*). his private data being always hidden behind these "SPARQL" views. and access rights are applied on queries instead of data. typically, you can use URL schemes to expose these queries, a la REST. and REST URLs are managed by the classical HTTP authentification processes we all know. On Thu, Mar 27, 2008 at 2:59 PM, Renato Golin <renato@ebi.ac.uk> wrote: > > > Hi Henry, > > > Story Henry wrote: > > 2. the server responds with either: > > - some minimal information and a yet to be invented return code of > > 207 PARTIAL INFORMATION > > You can use the already existent 206 "Partial Content" for that, I guess. > > > > - a 403 Forbidden > > 401 "Authentication required" will trigger some form of authentication > on normal browsers (such as htaccess). > > > > In either case a header returning some information regarding the type > > of authentication required is sent back > > via WWW-Authenticate header... > > > > 3. the client sends a GET back with some header information: > > - the URL of Romeo <http://romeo.name/#romeo> > > - an encrypted string (perhaps a string sent in the previous response) > > A three-way challenge response would be nice here... > > 1. Romeo gets random text + hash from romeo's > 2. Romeo encrypts text with private key and send to juliette's with hash > 3. Juliette's sends hash to romeo's and gets text + public key > 4. Juliette's decrypts text and compare with romeo's text > > The key could be in a public key server though. > > > > 4. The server controlling Juliette's foaf doc sends a GET request to the > > foaf file > > 5. The server controlling Romeo's foaf doc returns his foaf file, in any > > number of formats, or perhaps even a GRDDLable document the server can > > understand, containing a link to one of his public pgp keys > > You're not taking into account that Romeo might not want Juliette to > access his foaf file too... I he doesn't you got caught in a deadlock. > > The auth scheme should never rely on foaf files, it must be completely > independent of them because it's a step before actually getting foaf > files in the first place. > > > > 7. Juliette uses the answer in 6 to GET the PGP key. > > (what to do if someone has more that one PGP key?) > > Try all of them in descending order of creation time. > > > > > 8. Romeo's server returns the PGP key > > Easier to get them from public servers... keeping a list of all trusted > public servers on Juliette's. > > > > > 9. Juliette's server uses the public key to decrypt the string passed in > > 3. Having done this Juliette's server now knows that the request in 3 came > > from software owned by <http://romeo.name/#romeo>. > > Passing the same string as before doesn't show that you are romeo, but > getting the string from a trusted place (like romeo's server) and > comparing to what "the guy that says he's romeo" encripted with romeo's > private key might. > > > > 10. Juliette's server after consulting her policies for > > <http://romeo.name/#rome>, returns the appropriate response; a 200 > > perhaps with a fuller foaf file. Perhaps something else needs to be > > returned, a token to give access to a number of resources (expressed in > > POWDER perhaps). > > You're not dealing with multiple levels of security. You can follow the > Unix style of groups or hierarchy or even per-person style (very user > unfriendly) but would be good to say which resources from which files > each user/group/level might be able to access. > > > > > Some thoughts that just arose from going through the exercise of > > specifying each of the steps precisely: > > - what kind of response should be returned in 2? Should this redirect > > to an authentication server perhaps which would then return some token > > to give access to all the resources in a domain? > > - 401 if you haven't authenticated > - 206 if you have and is not Juliette (or someone she trusts > completely to give full access) > - 200 else > > > > - What about multiple pgp keys? > > Try all, although that would lead to a DOS if one creates hundreds of > keys just for the sake of killing your server. Even restraining by time > or only re-reading if the email is different you can still DOS by > creating hundreds of emails on your own domain in the last 10 minutes. > > I say we should restrict the number and if the user have a problem with > that he should specify the key server as an additional parameter (HTTP > header) to get from where he knows he have less than N keys where N > should be *really* small (say 5 or 10). If he still have problems he > should clean his pgp keys. ;) > > my 2 cents... > > cheers, > --renato > >
Received on Thursday, 27 March 2008 16:41:03 UTC