oltu-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simonetrip...@apache.org>
Subject Re: Followup: Refactoring the Hmac and Rsa signature methods APIs in JWS
Date Mon, 08 Dec 2014 16:47:13 GMT
Hi Antonio!

(restoring dev@)

unfortunately, while APIs are backward compatible, the modification
involves consumer changes, since impls are differenet :/

I have a new proposal, but let discuss about it on a separate thread.
Thanks a lot for reviewing, much more than appreciated! :)
-Simo



http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi

On Sat, Dec 6, 2014 at 2:05 PM, Antonio Sanso <asanso@adobe.com> wrote:

>  hi Simo,
>
>  thanks a lot for the great work so far.
>  Will be this patch fully backward compatible with the previous work?
>
>  regards
>
>  antonio
>
>  On Dec 5, 2014, at 11:25 PM, Simone Tripodi <simonetripodi@apache.org>
> wrote:
>
>  hi all again,
>
>  created OLTU-165 and attached the proposal patch
> If there is no objection, I would like to commit that modification -
> please let me know!
> -Simo
>
>
>  http://people.apache.org/~simonetripodi/
> http://twitter.com/simonetripodi
>
> On Fri, Dec 5, 2014 at 11:18 AM, Simone Tripodi <simonetripodi@apache.org>
> wrote:
>
>> Gentlemen,
>>
>>  I think that it's time to resurrect this thread since crypto issue have
>> been solved - thanks Antonio for leading that!
>>
>>  About handling crypto done with jose4j: I am fine with that, I am never
>> been good on handling crypto manually by myself, if there's something we
>> can reuse and helps us on saving developing time, it is welcome :)
>> Is it a valid OSGi bundle? Do you know some?
>>
>>  TIA and all the best!
>> -Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://twitter.com/simonetripodi
>>
>> On Wed, Aug 6, 2014 at 11:57 PM, Antonio Sanso <asanso@adobe.com> wrote:
>>
>>> thanks a lot for your effort Simone.
>>>
>>> I might need a little more time to dig it deeper though in order to
>>> better review.
>>>
>>> As a side note it would be also nice if we will replace the crypto done
>>> there with jose4j… [0]
>>>
>>> WDYT?
>>>
>>> regards
>>>
>>> antonio
>>>
>>> [0] https://bitbucket.org/b_c/jose4j/wiki/Home
>>> On Jun 26, 2014, at 11:01 AM, Simone Tripodi <simonetripodi@apache.org>
>>> wrote:
>>>
>>> > Hi Antonio, All,
>>> >
>>> > following up the old discussion, I found some spare time to make a
>>> > proposal and pasted in on Gist[1], if it looks fine for you I'd be
>>> > happy to track it on JIRA and continue the discussion/development
>>> > there.
>>> >
>>> > Main concerns I was focused on while making the proposal:
>>> >
>>> > * simplify the RSA/HMAC usage for users not familiar with
>>> > java.security APIs, introducing KeyFactory;
>>> >
>>> > * reduce drastically the magic role of Strings in the RSA algorithms,
>>> > I would avoid end users have to manipulate strings in order to obtain
>>> > different RSA algorithms, but IMHO it has to be clear which algorithm
>>> > they are going to use by simply instantiating classes;
>>> >
>>> > * have classes well organised, collected in different packages
>>> > depending by the signature method.
>>> >
>>> > Any feedback would be much more than appreciated, many thanks in
>>> advance!
>>> > -Simo
>>> >
>>> > [1] https://gist.github.com/simonetripodi/740ec4a8c1fdf06d5f3f
>>> >
>>> > http://people.apache.org/~simonetripodi/
>>> > http://twitter.com/simonetripodi
>>> >
>>> >
>>> > On Fri, Apr 11, 2014 at 1:51 PM, Simone Tripodi
>>> > <simonetripodi@apache.org> wrote:
>>> >> Hi Tonino,
>>> >>
>>> >> just few considerations:
>>> >>
>>> >>> +public class JwsConstants {
>>> >>> +
>>> >>> +    public static final String RS256 = "RS256";
>>> >>> +
>>> >>> +    public static final String RS384 = "RS384";
>>> >>> +
>>> >>> +    public static final String RS512 = "RS512";
>>> >>> +}
>>> >>
>>> >> I'd reduce this class constructor as 'private'
>>> >>
>>> >>>
>>> >>> Added:
>>> oltu/trunk/jose/jws/src/main/java/org/apache/oltu/jose/jws/signature/impl/PrivateKey.java
>>> >>
>>> >> I wouldn't add that classes to a generic 'impl' package, they refer
to
>>> >> specific 'java.security' implementation, so I would suggest to:
>>> >>
>>> >> * having them implemented in a separated module/bundle
>>> >>
>>> >> * package name be renamed
>>> >>
>>> >> WDYT?
>>> >> Best,
>>> >> -Simo
>>>
>>>
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message