- From: Benjamin Nowack <bnowack@semsol.com>
- Date: Fri, 28 Mar 2008 14:07:36 +0100
- To: Renato Golin <renato@ebi.ac.uk>
- Cc: Story Henry <henry.story@bblfish.net>, foaf-dev of a Friend <foaf-dev@lists.foaf-project.org>, Semantic Web <semantic-web@w3.org>
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