- From: Renato Golin <renato@ebi.ac.uk>
- Date: Fri, 28 Mar 2008 11:35:40 +0000
- To: Story Henry <henry.story@bblfish.net>
- CC: foaf-dev of a Friend <foaf-dev@lists.foaf-project.org>, Semantic Web <semantic-web@w3.org>
Story Henry wrote: > It is the MUST there which is problematic. That is why I was thinking it > may be nice to have a 207 - partial content, more when authenticated, > response. Hi Henry, I see the problem, the client must include it's personal range instead of letting the server to decide which range it's allowed. Maybe if we say that the range everybody is allowed is 0 (as in security level zero)... that would still be a hack, for sure. > Ok, so avoiding reading the whole of RFC 2617 I jumped to > http://en.wikipedia.org/wiki/Basic_access_authentication > which gives a good idea of how this works. (I always do that too...) ;) > - it would be really nice again if a basic representation could be > returned, > if this is not possible then perhaps the basic foaf file should be > available to all and contain a statement such as > <> rdfs:seeAlso </protected/juliette> . > </protected/juliette> would then be the resource requiring > authentication. > > And the client in 3 would respond with > > GET /protected/juliette HTTP/1.0 > Host: juliette.org > Authorization: RdfAuth id="http://romeo.name/#romeo" > key="THE_REALM_AND_NONCE_ENCRYPTED" > Content-Type: application/rdf+xml, text/rdf+n3 I guess we have a different view of the scheme here. As far as I could tell, you see the communication as RDF all over, even for authentication. I'm seeing the authentication as a primitive process, pretty much as the HTTPS does with the keys, so then you can get the file via the regular methods, ie. RDF. So, all authentication is done via HTTP headers and you only include the body (as RDF) after that process. > This is getting more complex though. I wonder if one can make a simple > spec that would easily be extensible to your suggestion. > And it would also be nice if one could have one that could work with ssl > as stated. I think it's good to put all ideas on the table (even if they're very complex) because you can, in the end, we can rubbish everything out and extract the gems... ;) > In fact if such a protocol took off, this would create a big incentive > for having a minimal public foaf file such as the above. I see. And by trying to access someone's private data means that you have to have at least the minimum infrastructure, such as registering to a community website (like Facebook) is today. > Though I really like the simplicity of having a public key available at > an http url. It makes it easier to change keys, update them, and > deprecate them. But then you could create a phony website and easily get the contents you're not allowed to, unless Juliette knows that Romeo is at romeo.com and not romeo.net or romeo.pornsite.net etc. At least by using emails (and public key servers) you can always send romeo an email confirming that he really wanted to access Juliette's private contents. > It may be nice also to have the file containing the pgp key itself be > RDF so that it can point back to the owner of the file, and also > specify if this is the actual key. That would even allow the key to be > placed in the foaf file, though as I mentioned it would be somewhat less > RESTful. But all libraries of today rely on public servers and they've already solved lots of small problems that by implementing on the semantic server or embed in a foaf file we'd have to solve again. I think we should always re-use what's been well done... > I am not sure I understand this. There may be a misunderstanding. > Juliette's server now has a public key, and she has an string Crypt(S) > encrypted by Romeo's User Agent UA with his private key. > If Cyrpt(S) decrypts with the public key back to the original S, then > she knows that UA had access to the private key, and so that the foaf > file which pointed to the public key is owned by the person owning the > private key. (or else the foaf file would not point to that public key > in that way) I see, I guess you're right here... > Yes, though this protocol does not need to decide how the permissions > are granted by Juliette's server. > > Another protocol, that would do something like oAuth, could use > foaf:Groups to allow foaf:Agents to access resources, using POWDER perhaps. Exactly. cheers, --renato
Received on Friday, 28 March 2008 11:36:19 UTC