[foaf-dev] Re: RDFAuth: an initial sketch
Benjamin Nowack
bnowack at semsol.com
Thu Mar 27 16:44:34 GMT 2008
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/
More information about the foaf-dev
mailing list