oltu-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simone.trip...@gmail.com>
Subject Re: SignatureMethodAlgorithm
Date Wed, 07 Jul 2010 08:39:23 GMT
Hola Pid

On Tue, Jul 6, 2010 at 10:38 PM, Pid <pid@pidster.com> wrote:
> I'm working on a prototype integrating the signature-api with the config
> stuff & the spec api.  Couple of things:
> #1

no problems/objections, feel free to commit it ;)

> #2
> I'm trying to understand whether it would be possible for the
> SignatureMethodAlgorithm interface to be refactored to just use the Key
> interface, or (SigningKey, VerifyingKey) directly.

Unfortunately, nope. That would be easier if we could take in
consideration only algorithms such PLAINTEXT and HMAC_SHA1, where the
same key is used to both sign/verify the signature, but with RSA
things are quite more complicated.
Using RSA involves users have to use a private key to sign, and a
public certificate to validate. Sounds reasonable - at least to me -
that keys have to be typed, since, potentially, trying to verify an
HMAC signature with an RSA public key is wrong.

> I assume it's defined like this so an implementation can require it's
> own key classes to be used?
> The problem is that I don't think we will be able to use the
> ServiceLoader mechanism to discover and use signature implementations.

I think your idea is still valid, adding just minor modifications,
something similar that I already did in the past[1]:
- with the service loader mechanism, you discover all SignatureMethod
implementations and optionally store them in a Registry;
- when a client try to generate/verify a signature, by the key it
could access to the registry and take the relative algorithm.

Quite clean and easy, thoughts?


[1] http://code.google.com/p/asmx-oauth/source/browse/trunk/core/commons/src/main/java/com/asemantics/oauth/core/signers/RequestSignerRegistry.java

View raw message