Re: RDFAuth: an initial sketch

On 31.03.2008 14:25:31, Story Henry wrote:
[...]
>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.
Yeah, I think Renato suggested something similar. The problem is still
that my target servers don't (necessarily) support PGP, and that a server 
may host lots of user profiles. So, (side-info: danbri correctly pointed
out in an off-list thread that the RDFAuth name is too premature and
presumptuous, so Henry and I decided to drop it for now) the idea was 
to have a list of personal token services that you could use, extend, 
or change easily. A knowee installation would be client as well as 
resource server and token service (the latter could be implemented in 10
lines of PHP code or so), but anyone can freely choose which token 
service to use. There needs to be some trust relation between a user 
and his token servers (via simple assertions in the user's RDF profile).

The resource server should have an easy way to verify a sent token. This
*could* be some public PGP-based verification service.

So, that probably boils down to: is it possible to replace the PGP part
in the client app with a comparable mechanism that can be implemented 
on simple web hosts (i.e. using only plain php/perl etc), and that 
allows the efficient generation of loads of tokens for its registered 
users?

Best,
Benji



>
>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/
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>

Received on Monday, 31 March 2008 13:22:17 UTC