Re: RDFAuth: an initial sketch

Ok so I think I am starting to understand your problem.

Knowee is playing a dual role:

  1. it is playing the role of a client in that it is fetching  
information from the web ( some of which may be protected by a  
mechanism that we have been calling RDFAuth, but that we have not  
clearly specified yet )
  2. it is playing the role of a server of RDF, so that clients like  
Beatnik ( https://sommer.dev.java.net/ ) can GET the user's foaf file  
from Knowee
(as shown in the HTTP headers in my recent post http://blogs.sun.com/bblfish/entry/rdfauth_sketch_of_a_buzzword 
  )

Now there is no problem with private keys when Knowee is playing role  
2. At that level Knowee just needs to be able to use a public key to  
decrypt a string, and as suggested in a response by Ed Davies to my  
blog post, encrypt the content too. At no point is there a need for  
the private key.

When Knowee is playing Role 1. then it is in the situation of a pure  
client such as Beatnik. Beatnik needs to know where Romoe's private  
key is, and has to be able to accept a password in order to encrypt  
stuff, and decrypt responses  sent to it by other Knowee servers. Now  
with Beatnik I am assuming the User (Romeo) is trusting his software  
not to take the password and private key and send it off to someone  
else. Your worry is the same on the server side.

Ok so at this level we both may need a protocol for communicating with  
what you are calling a token server, a server we can trust to encrypt  
and decrypt stuff with a password and private key. This server would  
know where the private key and password are, and it would know which  
applications it can trust to act on the user's (Romeo's) behalf. It  
could provide a log of all the agents that had asked it to encrypt  
something and when. So in this scenario Beatnik would not encrypt urls 
+nonces, nor would Beatnik decrypt responses. It would always forward  
this to the one, trusted, token/crypt server. Similarly with knowee:  
it could call a crypt server somewhere on the web.

I can see that this may work locally, but would be a bit awkward  
perhaps on a more global level, and we now have a bottleneck of a  
crypt server (perhaps there are smart crypto ways to make this less of  
a bottleneck when decrypting stuff).

So why not perhaps do things differently? Why not be honest?
After all if knowee is asking for something why should it pretend it  
is me? Would it not be better if it had it's own private key and  
password? It could then publish its public key and I could add to my  
foaf file, that it is an agent acting on my behalf. It would then be  
important for Server Agents acting on behalf of information publishers  
(such as Juliette) to understand how to trust agents I trust.

Does this make sense?

Henry




On 28 Mar 2008, at 13:43, Benjamin Nowack wrote:
>
> Hmm, ok, but wouldn't users also have to upload a private key
> to my server? And my app would have to send the private key
> to the encryption service, which I guess isn't too cool either.
>
> Benji
>
>
> On 28.03.2008 12:32:28, Story Henry wrote:
>> Well as I mention it would be easy to create a PGP encryption
>> decryption web service. That should be very easy to set up. What is
>> the problem?
>>
>> Henry
>>
>> On 28 Mar 2008, at 12:20, Benjamin Nowack wrote:
>>>
>>> Hi,
>>>
>>> using PGP is interesting, and as I wrote, there should be a way to
>>> transparently combine it with RDFAuth. The protocol itself, however,
>>> does not rely on it. Neither the [client app] nor the [resource
>>> server]
>>> require PGP. I wouldn't be able to use RDFAuth on the platforms I'm
>>> going to deploy my apps to (shared, hosted LAMP servers) if PGP was
>>> a prerequisite.
>>>
>>>
>>> Best,
>>> Benji
>>>
>>> --
>>> Benjamin Nowack
>>> http://bnode.org/
>>>
>>> On 28.03.2008 10:15:22, Story Henry wrote:
>>>> Hi Benjamin,
>>>>
>>>>
>>>> On 27 Mar 2008, at 17:44, Benjamin Nowack wrote:
>>>>>
>>>>>
>>>>> Hi, just some clarifications:
>>>>> RDFAuth doesn't use public/private key encryption, but simple
>>>>> token servers. Thanks to RDF, eRDFa, MFs, and GRDDL, it also
>>>>> doesn't need AX, sREG, or anything like that for data exchange
>>>>> and discovery.
>>>>
>>>> Well RDFAuth is not finalised yet, as far as I understand. The
>>>> proposal I am putting forward here does rely on public/private key
>>>> encryption, at least at the first stage. I suppose this can be
>>>> combined with a token that can then be passed at a later stage when
>>>> the initial identification of the client is clear.
>>>>
>>>> The advantage of this proposal is that it does not need a token
>>>> server. It is much more RESTful in this respect, since there is no
>>>> need for a dynamic web service. Placing a file on the web is all  
>>>> that
>>>> is needed. Furthermore the private key can remain on the client
>>>> machine, so there is no need for passwords to travel over the
>>>> internet, increasing security still further. Finally since there is
>>>> no
>>>> need for a token server, the OpenId Identity Provider, there is no
>>>> centralised point of control which can be used to track your
>>>> behavior.
>>>> True, everyone can use their OpenId server of choice, and even  
>>>> set up
>>>> their own, but currently most people are going to be using one of  
>>>> the
>>>> big openid providers listed http://openid.net/get/ .
>>>> With the RESTful publication of a PGP key, anywhere you wish,  
>>>> even if
>>>> the large players wished to publish your key, they could not
>>>> distinguish a simple GET of your public key, from one that may be
>>>> used
>>>> to authenticate you at one site.
>>>>
>>>> Here is the diagram again, this time with the public and protected
>>>> resources a little more clearly distinguished. In the previous
>>>> diagram
>>>> I assumed that Juliette's public foaf representation and her
>>>> protected
>>>> were different representations of the same resource. I am not  
>>>> sure if
>>>> in HTTP protocol one can do this, and also it caused confusion
>>>> because
>>>> people were wondering how the whole thing would get going,  
>>>> especially
>>>> in stage 5 below. Distinguishing this makes it clearer. Public foaf
>>>> files would have a link to public keys, and as much other  
>>>> information
>>>> as the author wanted to make public.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Now if you find encryption and decryption in 3 and 8 to be too
>>>> difficult to implement with some of the commonly used tools, that  
>>>> is
>>>> easy to fix. Just create an web service to do this for you. But  
>>>> there
>>>> is clearly no need to add this to the specification.
>>>>
>>>>
>>>>
>>>>> Long-term-ish, this mechanism should be partly replaced by  
>>>>> whatever
>>>>> oAuth offers WRT server-side token generation, but the main
>>>>> motivation right now is to build something very easy that works
>>>>> for basic use cases and which can then be extended once we have
>>>>> prototypes.
>>>>>
>>>>>
>>>>> So, the idea is more or less:
>>>>>
>>>>> Prerequisites:
>>>>> The [user] of the [client app] maintains a public RDF profile
>>>>> that contains a [personal identifier] (foaf:homepage, foaf:openid,
>>>>> a personal URI, xfn:me, whatever) and an rdfauth:tokenServer
>>>>> triple pointing at the personal [token server]. The identifier
>>>>> is ideally a personal URI directly related to the profile to
>>>>> simplify "follow your nose" discovery, maybe we should make that
>>>>> mandatory to simplify things, not sure.
>>>>>
>>>>> Scenario A
>>>>>
>>>>> 1. The [client app] knows/assumes that there is private info
>>>>> available at the [resource server]
>>>>> 2. The [client app] creates a [token] at the [user]'s [token
>>>>> server] (identical to openID, the "how" is not part of the spec)
>>>>> 3. The [client app] requests a resource from the [resource  
>>>>> server],
>>>>> via standard HTTP, plus an "Authorization" header that contains
>>>>> the [token], and the [user]'s [personal identifier]
>>>>> 4. The [resource server] detects the "Authorization" header,
>>>>> extracts the [token] and the [personal identifier] and tries to
>>>>> identify the [user]'s [token server].
>>>>> 5. The [resource server] validates the [token] via the [token
>>>>> server]
>>>>> 6. Based on the available data (named/trusted graphs, a list of
>>>>> trusted token serves, etc.) and app logic, the [resource server]
>>>>> decides whether it accepts/trusts the [personal identifier] and
>>>>> which information to serve to the [client app]. It may  
>>>>> additionally
>>>>> create and send a [session token] which might be used for later
>>>>> requests. When or how this session token expires is up to the
>>>>> [resource server].
>>>>>
>>>>>
>>>>> Scenario B
>>>>>
>>>>> 1. The [client app] does not know/assume upfront that there is
>>>>> private
>>>>> information available at the [resource server]
>>>>> 2. The [client app] requests a resource from the [resource  
>>>>> server],
>>>>> via standard HTTP
>>>>> 3. The [resource server] serves whatever it decides to serve to
>>>>> unauthorized clients. This can for example be a partial RDF or
>>>>> HTML file. Together with the (possibly "200 OK") response, a
>>>>> "WWW-Authenticate" header is sent.
>>>>> 4. The [client app] detects the "WWW-Authenticate" header and
>>>>> decides
>>>>> whether it'll try to authenticate to retrieve more information.
>>>>> 5.-9. = step 2.-6. in Scenarion A
>>>>>
>>>>>
>>>>> Scenario C
>>>>>
>>>>> 1. The [client app] has a [session token] from an earlier request
>>>>> 2. The [client app] requests a resource from the [resource  
>>>>> server],
>>>>> via standard HTTP, plus an "Authorization" header that contains
>>>>> the [session token]
>>>>> 3. The [resource server] detects the "Authorization" header and
>>>>> extracts the [session token].
>>>>> 4. The [resource server] validates the [session token] and detects
>>>>> the associated [personal identifier]
>>>>> 5. = step 6. in Scenario A
>>>>>
>>>>>
>>>>> Now, the sent [token] could indeed contain a portion that is
>>>>> generated
>>>>> using PGP-encrypted information. In that case the personal [token
>>>>> server]
>>>>> could be a PGP verifier. This would be transparent to the  
>>>>> [resource
>>>>> server]
>>>>> and the RDFAuth protocol, though. The token will have a certain
>>>>> structure
>>>>> to make sure that it can only be used for one [user] and one
>>>>> [resource
>>>>> server].
>>>>>
>>>>>
>>>>> Cheers,
>>>>> Benji
>>>>>
>>>>> --
>>>>> Benjamin Nowack
>>>>> http://bnode.org/
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>