Re: RDFAuth: an initial sketch

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. 

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 Thursday, 27 March 2008 16:45:17 UTC