Re: RDFAuth: an initial sketch

Yeah, as mentioned, an RDFAuth client *can* use PGP to create a token, 
it's just not mandatory. Hmmm, what about this:

We define a token structure that makes it clear whether the token is
PGP-generated or not. If it is a PGP key, the [resource server] could
use PGP to decrypt/verify the token w/o an additional request to a
[token server]. Should the [resource server] not support PGP, it could
use a public PGP decryption service, as proposed by Henry. This can
be implemented transparently to the [resource server] when the user's 
foaf file indicates that the rdfauth:tokenServer is actually
an (RDFAuth-enabled) PGP-decryption service.

Is that an acceptable compromise? (I won't have time to flesh things 
out in more detail before mid April, I'm buried in other work ATM)

A [resource server] could of course always reject non-PGP-encrypted 
tokens, or PGP-encrypted tokens. After all, it's the [resource server]'s 
decision what to accept. RDFAuth-wise, we just have to make sure that
both methods can be implemented easily.

Benji

--
Benjamin Nowack
http://bnode.org/

On 28.03.2008 11:51:38, Renato Golin wrote:
[..]
>Not talking about the difficulties of implementing a PGP service on your 
>platform, but I'd always say to reuse good platforms. If we are to use 
>key distribution and storage we should never start a new protocol when 
>the PGP is already so successful.
>
>Maybe that's a call for a mod_pgp on Apache (if there isn't one already)
>
>cheers,
>--renato
>

Received on Friday, 28 March 2008 13:08:12 UTC