Re: RDFAuth: an initial sketch

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