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 <asa...@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 <simonetrip...@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 <simonetrip...@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 <asa...@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 <simonetrip...@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 >>> > <simonetrip...@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 >>> >>> >> > >
