Re: RDFAuth: an initial sketch

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