Re: RDFAuth: an initial sketch

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