Re: RDFAuth: an initial sketch

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 Friday, 28 March 2008 12:44:16 UTC