You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@oltu.apache.org by Antonio Sanso <as...@adobe.com> on 2012/01/18 20:01:10 UTC
Amber Oauth Client - was: [tidying-up the SVN space]
Hi Simone,
On Jan 16, 2012, at 4:25 PM, Simone Tripodi wrote:
> Hola,
> The question I have is - and please take in consideration today I'm an
> outdated OAuth guy :) - : how hard is putting 1.0a support in current
> 2.0 client?
I have started to give a look at it and evaluated the effort.
So at first glance it seems there is some effort but we probably can reuse something from the implementation of 1.0 we already have.
This is basically what I am think to do:
- create a new module e.g. oauth2-client-extension that has 2 dependencies (oauth-common, oauh2-client)
- create an abstract class/intefrace OAuthClient
- the current OAuthClient will become e.g. OAuth20ClientImpl (extends OAuthClient)
- the OAuhClient10aImpl (that extends OAuthClient) will be contained in the new project (oauth2-client-extension)
- potentially reuse the crypto/signture code of the existing 1.0 implementation (moving it in the new SVN space) in order to support the bullet above (I am not a big expert of Oauth 1.0(a) so I might need some help here)
As a final consideration we might need the crypto module also in the Oauth 2 implementation. Indeed while the Bearer token doesn't have any crypto overhead the MAC token (included in OAuth2 [0])
should be basically identical than Oauth 1.0(a).
WDYT?
Regards
Antonio
[0] http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-00
> TIA,
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
>
> On Mon, Jan 16, 2012 at 10:19 AM, Tommaso Teofili
> <to...@gmail.com> wrote:
>> 2012/1/14 Antonio Sanso <as...@adobe.com>
>>
>>>
>>> On Jan 12, 2012, at 5:04 PM, Simone Tripodi wrote:
>>>
>>>> Ciao Antonio,
>>>>
>>>>>
>>>>> unless I am doing something wrong it looks like I still do not have any
>>> write/edit permission on the wiki.
>>>>>
>>>>
>>>> I am worried you'll have to contact INFRA[1]
>>>>
>>>>> If I am not completely wrong some major sites (e.g. twitter) are still
>>> using version 1.0a of the spec.
>>>>> For this reason, if we want to gather any crowd to use Amber it would
>>> be good to support at least client side also version 1.0a otherwise people
>>> would be oriented to use some other Java libraries (e.g. Scribe).
>>>>> The effort to do it for the client module should not be to huge, but
>>> there is obviously an overhead.
>>>>
>>>> That sounds a more than valid reason to implement 1.0a - can you make
>>>> a quick search to verify that please? TIA!
>>>
>>> Hi Simone, I can confirm Twitter is still using 1.0a .
>>> As a general consideration I also think that there are much more users
>>> interested to the client part than the one interested to the server part
>>> (like me :)).
>>>
>>
>> I agree that the client is an important part so I agree on the 1.0a
>> implementation.
>>
>>
>>> For this reason we could even think about a two phase release (first one
>>> we focus on the client/common modules) and second we focus on everything
>>> else.
>>>
>>
>> I think the best way of doing that is putting down a quick roadmap of
>> things to be done so that we can prioritize tasks and, eventually, split
>> those items in different phases.
>> BTW we are in the Incubator for a long time now so it'd be good to include
>> also a release / graduation plan.
>>
>>
>>> I hope you agree than one of our goal is to be mentioned here [0]and here
>>> [1] in order to increase the project exposure.
>>>
>>> WDYT?
>>>
>>
>> +1
>>
>> Tommaso
>>
>>
>>
>>>
>>> Regards
>>>
>>> Antonio
>>>
>>> [0] http://oauth.net/code/
>>> [1] http://oauth.net/2/
>>>
>>>
>>>>
>>>> I would propose to add that implementation in the current 2.0 impl,
>>>> rather than continue developing old stuff...
>>>>
>>>> best,
>>>> -Simo
>>>>
>>>> [1] https://issues.apache.org/jira/browse/INFRA
>>>>
>>>> http://people.apache.org/~simonetripodi/
>>>> http://simonetripodi.livejournal.com/
>>>> http://twitter.com/simonetripodi
>>>> http://www.99soft.org/
>>>
>>>
Re: Amber Oauth Client - was: [tidying-up the SVN space]
Posted by Pid <pi...@pidster.com>.
On 19/01/2012 08:58, Antonio Sanso wrote:
> Hi Pid
>
> On Jan 19, 2012, at 9:49 AM, Pid wrote:
>
>> On 19/01/2012 00:34, Raymond Feng wrote:
>>> Hi, Antonio.
>>>
>>> Good thoughts. BTW, we could also have an OAuthClientFactory that can be used to create version 1.0a and 2.0 clients.
>>
>> One of the original reasons for the spec-api stuff was to provide a
>> common facade for multiple versions of the spec, with an attempt to hide
>> the operations internally.
>
> agreed.
> The only think to take in consideration is that at the moment Amber code style is not really "homogeneous".
> Whit this I mean (I might be wrong here) that the original code (e.g. spec-api) and the 2.0 part (former Leeloo) have been developed separately and for this reason they follow different nomenclature/code style/ etc...
> Now at this point I think we might take the decision of which way we want to follow and adapt the remaining code accordingly.
Yes, maybe we can make a merge/commonality an objective as part of our
planning process.
p
> Regards
>
> Antonio
>
>>
>> I still think this is possible - as most of the interaction from an
>> Amber users point of can be relatively simple if we use a factory, as
>> Raymond says.
>>
>>
>> p
>>
>>
>>> Thanks,
>>> Raymond
>>>
>>> On Jan 18, 2012, at 11:01 AM, Antonio Sanso wrote:
>>>
>>>> Hi Simone,
>>>>
>>>>
>>>> On Jan 16, 2012, at 4:25 PM, Simone Tripodi wrote:
>>>>
>>>>> Hola,
>>>>> The question I have is - and please take in consideration today I'm an
>>>>> outdated OAuth guy :) - : how hard is putting 1.0a support in current
>>>>> 2.0 client?
>>>>
>>>> I have started to give a look at it and evaluated the effort.
>>>>
>>>> So at first glance it seems there is some effort but we probably can reuse something from the implementation of 1.0 we already have.
>>>> This is basically what I am think to do:
>>>>
>>>> - create a new module e.g. oauth2-client-extension that has 2 dependencies (oauth-common, oauh2-client)
>>>> - create an abstract class/intefrace OAuthClient
>>>> - the current OAuthClient will become e.g. OAuth20ClientImpl (extends OAuthClient)
>>>> - the OAuhClient10aImpl (that extends OAuthClient) will be contained in the new project (oauth2-client-extension)
>>>> - potentially reuse the crypto/signture code of the existing 1.0 implementation (moving it in the new SVN space) in order to support the bullet above (I am not a big expert of Oauth 1.0(a) so I might need some help here)
>>>>
>>>> As a final consideration we might need the crypto module also in the Oauth 2 implementation. Indeed while the Bearer token doesn't have any crypto overhead the MAC token (included in OAuth2 [0])
>>>> should be basically identical than Oauth 1.0(a).
>>>>
>>>> WDYT?
>>>>
>>>> Regards
>>>>
>>>> Antonio
>>>>
>>>> [0] http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-00
>>>>
>>>>> TIA,
>>>>> Simo
>>>>>
>>>>> http://people.apache.org/~simonetripodi/
>>>>> http://simonetripodi.livejournal.com/
>>>>> http://twitter.com/simonetripodi
>>>>> http://www.99soft.org/
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Jan 16, 2012 at 10:19 AM, Tommaso Teofili
>>>>> <to...@gmail.com> wrote:
>>>>>> 2012/1/14 Antonio Sanso <as...@adobe.com>
>>>>>>
>>>>>>>
>>>>>>> On Jan 12, 2012, at 5:04 PM, Simone Tripodi wrote:
>>>>>>>
>>>>>>>> Ciao Antonio,
>>>>>>>>
>>>>>>>>>
>>>>>>>>> unless I am doing something wrong it looks like I still do not have any
>>>>>>> write/edit permission on the wiki.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I am worried you'll have to contact INFRA[1]
>>>>>>>>
>>>>>>>>> If I am not completely wrong some major sites (e.g. twitter) are still
>>>>>>> using version 1.0a of the spec.
>>>>>>>>> For this reason, if we want to gather any crowd to use Amber it would
>>>>>>> be good to support at least client side also version 1.0a otherwise people
>>>>>>> would be oriented to use some other Java libraries (e.g. Scribe).
>>>>>>>>> The effort to do it for the client module should not be to huge, but
>>>>>>> there is obviously an overhead.
>>>>>>>>
>>>>>>>> That sounds a more than valid reason to implement 1.0a - can you make
>>>>>>>> a quick search to verify that please? TIA!
>>>>>>>
>>>>>>> Hi Simone, I can confirm Twitter is still using 1.0a .
>>>>>>> As a general consideration I also think that there are much more users
>>>>>>> interested to the client part than the one interested to the server part
>>>>>>> (like me :)).
>>>>>>>
>>>>>>
>>>>>> I agree that the client is an important part so I agree on the 1.0a
>>>>>> implementation.
>>>>>>
>>>>>>
>>>>>>> For this reason we could even think about a two phase release (first one
>>>>>>> we focus on the client/common modules) and second we focus on everything
>>>>>>> else.
>>>>>>>
>>>>>>
>>>>>> I think the best way of doing that is putting down a quick roadmap of
>>>>>> things to be done so that we can prioritize tasks and, eventually, split
>>>>>> those items in different phases.
>>>>>> BTW we are in the Incubator for a long time now so it'd be good to include
>>>>>> also a release / graduation plan.
>>>>>>
>>>>>>
>>>>>>> I hope you agree than one of our goal is to be mentioned here [0]and here
>>>>>>> [1] in order to increase the project exposure.
>>>>>>>
>>>>>>> WDYT?
>>>>>>>
>>>>>>
>>>>>> +1
>>>>>>
>>>>>> Tommaso
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Regards
>>>>>>>
>>>>>>> Antonio
>>>>>>>
>>>>>>> [0] http://oauth.net/code/
>>>>>>> [1] http://oauth.net/2/
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> I would propose to add that implementation in the current 2.0 impl,
>>>>>>>> rather than continue developing old stuff...
>>>>>>>>
>>>>>>>> best,
>>>>>>>> -Simo
>>>>>>>>
>>>>>>>> [1] https://issues.apache.org/jira/browse/INFRA
>>>>>>>>
>>>>>>>> http://people.apache.org/~simonetripodi/
>>>>>>>> http://simonetripodi.livejournal.com/
>>>>>>>> http://twitter.com/simonetripodi
>>>>>>>> http://www.99soft.org/
>>>>>>>
>>>>>>>
>>>>
>>>
>>
>>
>> --
>>
>> [key:62590808]
>>
>
--
[key:62590808]
Re: Amber Oauth Client - was: [tidying-up the SVN space]
Posted by Simone Tripodi <si...@apache.org>.
> The only think to take in consideration is that at the moment Amber code style is not really "homogeneous".
> Whit this I mean (I might be wrong here) that the original code (e.g. spec-api) and the 2.0 part (former Leeloo) have been developed separately and for this reason they follow different nomenclature/code style/ etc...
> Now at this point I think we might take the decision of which way we want to follow and adapt the remaining code accordingly.
yup, that was part of the purposes of the older "svn tide-up" thread.
proposals?
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
Re: Amber Oauth Client - was: [tidying-up the SVN space]
Posted by Antonio Sanso <as...@adobe.com>.
Hi Pid
On Jan 19, 2012, at 9:49 AM, Pid wrote:
> On 19/01/2012 00:34, Raymond Feng wrote:
>> Hi, Antonio.
>>
>> Good thoughts. BTW, we could also have an OAuthClientFactory that can be used to create version 1.0a and 2.0 clients.
>
> One of the original reasons for the spec-api stuff was to provide a
> common facade for multiple versions of the spec, with an attempt to hide
> the operations internally.
agreed.
The only think to take in consideration is that at the moment Amber code style is not really "homogeneous".
Whit this I mean (I might be wrong here) that the original code (e.g. spec-api) and the 2.0 part (former Leeloo) have been developed separately and for this reason they follow different nomenclature/code style/ etc...
Now at this point I think we might take the decision of which way we want to follow and adapt the remaining code accordingly.
Regards
Antonio
>
> I still think this is possible - as most of the interaction from an
> Amber users point of can be relatively simple if we use a factory, as
> Raymond says.
>
>
> p
>
>
>> Thanks,
>> Raymond
>>
>> On Jan 18, 2012, at 11:01 AM, Antonio Sanso wrote:
>>
>>> Hi Simone,
>>>
>>>
>>> On Jan 16, 2012, at 4:25 PM, Simone Tripodi wrote:
>>>
>>>> Hola,
>>>> The question I have is - and please take in consideration today I'm an
>>>> outdated OAuth guy :) - : how hard is putting 1.0a support in current
>>>> 2.0 client?
>>>
>>> I have started to give a look at it and evaluated the effort.
>>>
>>> So at first glance it seems there is some effort but we probably can reuse something from the implementation of 1.0 we already have.
>>> This is basically what I am think to do:
>>>
>>> - create a new module e.g. oauth2-client-extension that has 2 dependencies (oauth-common, oauh2-client)
>>> - create an abstract class/intefrace OAuthClient
>>> - the current OAuthClient will become e.g. OAuth20ClientImpl (extends OAuthClient)
>>> - the OAuhClient10aImpl (that extends OAuthClient) will be contained in the new project (oauth2-client-extension)
>>> - potentially reuse the crypto/signture code of the existing 1.0 implementation (moving it in the new SVN space) in order to support the bullet above (I am not a big expert of Oauth 1.0(a) so I might need some help here)
>>>
>>> As a final consideration we might need the crypto module also in the Oauth 2 implementation. Indeed while the Bearer token doesn't have any crypto overhead the MAC token (included in OAuth2 [0])
>>> should be basically identical than Oauth 1.0(a).
>>>
>>> WDYT?
>>>
>>> Regards
>>>
>>> Antonio
>>>
>>> [0] http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-00
>>>
>>>> TIA,
>>>> Simo
>>>>
>>>> http://people.apache.org/~simonetripodi/
>>>> http://simonetripodi.livejournal.com/
>>>> http://twitter.com/simonetripodi
>>>> http://www.99soft.org/
>>>>
>>>>
>>>>
>>>> On Mon, Jan 16, 2012 at 10:19 AM, Tommaso Teofili
>>>> <to...@gmail.com> wrote:
>>>>> 2012/1/14 Antonio Sanso <as...@adobe.com>
>>>>>
>>>>>>
>>>>>> On Jan 12, 2012, at 5:04 PM, Simone Tripodi wrote:
>>>>>>
>>>>>>> Ciao Antonio,
>>>>>>>
>>>>>>>>
>>>>>>>> unless I am doing something wrong it looks like I still do not have any
>>>>>> write/edit permission on the wiki.
>>>>>>>>
>>>>>>>
>>>>>>> I am worried you'll have to contact INFRA[1]
>>>>>>>
>>>>>>>> If I am not completely wrong some major sites (e.g. twitter) are still
>>>>>> using version 1.0a of the spec.
>>>>>>>> For this reason, if we want to gather any crowd to use Amber it would
>>>>>> be good to support at least client side also version 1.0a otherwise people
>>>>>> would be oriented to use some other Java libraries (e.g. Scribe).
>>>>>>>> The effort to do it for the client module should not be to huge, but
>>>>>> there is obviously an overhead.
>>>>>>>
>>>>>>> That sounds a more than valid reason to implement 1.0a - can you make
>>>>>>> a quick search to verify that please? TIA!
>>>>>>
>>>>>> Hi Simone, I can confirm Twitter is still using 1.0a .
>>>>>> As a general consideration I also think that there are much more users
>>>>>> interested to the client part than the one interested to the server part
>>>>>> (like me :)).
>>>>>>
>>>>>
>>>>> I agree that the client is an important part so I agree on the 1.0a
>>>>> implementation.
>>>>>
>>>>>
>>>>>> For this reason we could even think about a two phase release (first one
>>>>>> we focus on the client/common modules) and second we focus on everything
>>>>>> else.
>>>>>>
>>>>>
>>>>> I think the best way of doing that is putting down a quick roadmap of
>>>>> things to be done so that we can prioritize tasks and, eventually, split
>>>>> those items in different phases.
>>>>> BTW we are in the Incubator for a long time now so it'd be good to include
>>>>> also a release / graduation plan.
>>>>>
>>>>>
>>>>>> I hope you agree than one of our goal is to be mentioned here [0]and here
>>>>>> [1] in order to increase the project exposure.
>>>>>>
>>>>>> WDYT?
>>>>>>
>>>>>
>>>>> +1
>>>>>
>>>>> Tommaso
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> Antonio
>>>>>>
>>>>>> [0] http://oauth.net/code/
>>>>>> [1] http://oauth.net/2/
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> I would propose to add that implementation in the current 2.0 impl,
>>>>>>> rather than continue developing old stuff...
>>>>>>>
>>>>>>> best,
>>>>>>> -Simo
>>>>>>>
>>>>>>> [1] https://issues.apache.org/jira/browse/INFRA
>>>>>>>
>>>>>>> http://people.apache.org/~simonetripodi/
>>>>>>> http://simonetripodi.livejournal.com/
>>>>>>> http://twitter.com/simonetripodi
>>>>>>> http://www.99soft.org/
>>>>>>
>>>>>>
>>>
>>
>
>
> --
>
> [key:62590808]
>
Re: Amber Oauth Client - was: [tidying-up the SVN space]
Posted by Pid <pi...@pidster.com>.
On 19/01/2012 00:34, Raymond Feng wrote:
> Hi, Antonio.
>
> Good thoughts. BTW, we could also have an OAuthClientFactory that can be used to create version 1.0a and 2.0 clients.
One of the original reasons for the spec-api stuff was to provide a
common facade for multiple versions of the spec, with an attempt to hide
the operations internally.
I still think this is possible - as most of the interaction from an
Amber users point of can be relatively simple if we use a factory, as
Raymond says.
p
> Thanks,
> Raymond
>
> On Jan 18, 2012, at 11:01 AM, Antonio Sanso wrote:
>
>> Hi Simone,
>>
>>
>> On Jan 16, 2012, at 4:25 PM, Simone Tripodi wrote:
>>
>>> Hola,
>>> The question I have is - and please take in consideration today I'm an
>>> outdated OAuth guy :) - : how hard is putting 1.0a support in current
>>> 2.0 client?
>>
>> I have started to give a look at it and evaluated the effort.
>>
>> So at first glance it seems there is some effort but we probably can reuse something from the implementation of 1.0 we already have.
>> This is basically what I am think to do:
>>
>> - create a new module e.g. oauth2-client-extension that has 2 dependencies (oauth-common, oauh2-client)
>> - create an abstract class/intefrace OAuthClient
>> - the current OAuthClient will become e.g. OAuth20ClientImpl (extends OAuthClient)
>> - the OAuhClient10aImpl (that extends OAuthClient) will be contained in the new project (oauth2-client-extension)
>> - potentially reuse the crypto/signture code of the existing 1.0 implementation (moving it in the new SVN space) in order to support the bullet above (I am not a big expert of Oauth 1.0(a) so I might need some help here)
>>
>> As a final consideration we might need the crypto module also in the Oauth 2 implementation. Indeed while the Bearer token doesn't have any crypto overhead the MAC token (included in OAuth2 [0])
>> should be basically identical than Oauth 1.0(a).
>>
>> WDYT?
>>
>> Regards
>>
>> Antonio
>>
>> [0] http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-00
>>
>>> TIA,
>>> Simo
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://simonetripodi.livejournal.com/
>>> http://twitter.com/simonetripodi
>>> http://www.99soft.org/
>>>
>>>
>>>
>>> On Mon, Jan 16, 2012 at 10:19 AM, Tommaso Teofili
>>> <to...@gmail.com> wrote:
>>>> 2012/1/14 Antonio Sanso <as...@adobe.com>
>>>>
>>>>>
>>>>> On Jan 12, 2012, at 5:04 PM, Simone Tripodi wrote:
>>>>>
>>>>>> Ciao Antonio,
>>>>>>
>>>>>>>
>>>>>>> unless I am doing something wrong it looks like I still do not have any
>>>>> write/edit permission on the wiki.
>>>>>>>
>>>>>>
>>>>>> I am worried you'll have to contact INFRA[1]
>>>>>>
>>>>>>> If I am not completely wrong some major sites (e.g. twitter) are still
>>>>> using version 1.0a of the spec.
>>>>>>> For this reason, if we want to gather any crowd to use Amber it would
>>>>> be good to support at least client side also version 1.0a otherwise people
>>>>> would be oriented to use some other Java libraries (e.g. Scribe).
>>>>>>> The effort to do it for the client module should not be to huge, but
>>>>> there is obviously an overhead.
>>>>>>
>>>>>> That sounds a more than valid reason to implement 1.0a - can you make
>>>>>> a quick search to verify that please? TIA!
>>>>>
>>>>> Hi Simone, I can confirm Twitter is still using 1.0a .
>>>>> As a general consideration I also think that there are much more users
>>>>> interested to the client part than the one interested to the server part
>>>>> (like me :)).
>>>>>
>>>>
>>>> I agree that the client is an important part so I agree on the 1.0a
>>>> implementation.
>>>>
>>>>
>>>>> For this reason we could even think about a two phase release (first one
>>>>> we focus on the client/common modules) and second we focus on everything
>>>>> else.
>>>>>
>>>>
>>>> I think the best way of doing that is putting down a quick roadmap of
>>>> things to be done so that we can prioritize tasks and, eventually, split
>>>> those items in different phases.
>>>> BTW we are in the Incubator for a long time now so it'd be good to include
>>>> also a release / graduation plan.
>>>>
>>>>
>>>>> I hope you agree than one of our goal is to be mentioned here [0]and here
>>>>> [1] in order to increase the project exposure.
>>>>>
>>>>> WDYT?
>>>>>
>>>>
>>>> +1
>>>>
>>>> Tommaso
>>>>
>>>>
>>>>
>>>>>
>>>>> Regards
>>>>>
>>>>> Antonio
>>>>>
>>>>> [0] http://oauth.net/code/
>>>>> [1] http://oauth.net/2/
>>>>>
>>>>>
>>>>>>
>>>>>> I would propose to add that implementation in the current 2.0 impl,
>>>>>> rather than continue developing old stuff...
>>>>>>
>>>>>> best,
>>>>>> -Simo
>>>>>>
>>>>>> [1] https://issues.apache.org/jira/browse/INFRA
>>>>>>
>>>>>> http://people.apache.org/~simonetripodi/
>>>>>> http://simonetripodi.livejournal.com/
>>>>>> http://twitter.com/simonetripodi
>>>>>> http://www.99soft.org/
>>>>>
>>>>>
>>
>
--
[key:62590808]
Re: Amber Oauth Client - was: [tidying-up the SVN space]
Posted by Raymond Feng <en...@gmail.com>.
Hi, Antonio.
Good thoughts. BTW, we could also have an OAuthClientFactory that can be used to create version 1.0a and 2.0 clients.
Thanks,
Raymond
On Jan 18, 2012, at 11:01 AM, Antonio Sanso wrote:
> Hi Simone,
>
>
> On Jan 16, 2012, at 4:25 PM, Simone Tripodi wrote:
>
>> Hola,
>> The question I have is - and please take in consideration today I'm an
>> outdated OAuth guy :) - : how hard is putting 1.0a support in current
>> 2.0 client?
>
> I have started to give a look at it and evaluated the effort.
>
> So at first glance it seems there is some effort but we probably can reuse something from the implementation of 1.0 we already have.
> This is basically what I am think to do:
>
> - create a new module e.g. oauth2-client-extension that has 2 dependencies (oauth-common, oauh2-client)
> - create an abstract class/intefrace OAuthClient
> - the current OAuthClient will become e.g. OAuth20ClientImpl (extends OAuthClient)
> - the OAuhClient10aImpl (that extends OAuthClient) will be contained in the new project (oauth2-client-extension)
> - potentially reuse the crypto/signture code of the existing 1.0 implementation (moving it in the new SVN space) in order to support the bullet above (I am not a big expert of Oauth 1.0(a) so I might need some help here)
>
> As a final consideration we might need the crypto module also in the Oauth 2 implementation. Indeed while the Bearer token doesn't have any crypto overhead the MAC token (included in OAuth2 [0])
> should be basically identical than Oauth 1.0(a).
>
> WDYT?
>
> Regards
>
> Antonio
>
> [0] http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-00
>
>> TIA,
>> Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>>
>>
>> On Mon, Jan 16, 2012 at 10:19 AM, Tommaso Teofili
>> <to...@gmail.com> wrote:
>>> 2012/1/14 Antonio Sanso <as...@adobe.com>
>>>
>>>>
>>>> On Jan 12, 2012, at 5:04 PM, Simone Tripodi wrote:
>>>>
>>>>> Ciao Antonio,
>>>>>
>>>>>>
>>>>>> unless I am doing something wrong it looks like I still do not have any
>>>> write/edit permission on the wiki.
>>>>>>
>>>>>
>>>>> I am worried you'll have to contact INFRA[1]
>>>>>
>>>>>> If I am not completely wrong some major sites (e.g. twitter) are still
>>>> using version 1.0a of the spec.
>>>>>> For this reason, if we want to gather any crowd to use Amber it would
>>>> be good to support at least client side also version 1.0a otherwise people
>>>> would be oriented to use some other Java libraries (e.g. Scribe).
>>>>>> The effort to do it for the client module should not be to huge, but
>>>> there is obviously an overhead.
>>>>>
>>>>> That sounds a more than valid reason to implement 1.0a - can you make
>>>>> a quick search to verify that please? TIA!
>>>>
>>>> Hi Simone, I can confirm Twitter is still using 1.0a .
>>>> As a general consideration I also think that there are much more users
>>>> interested to the client part than the one interested to the server part
>>>> (like me :)).
>>>>
>>>
>>> I agree that the client is an important part so I agree on the 1.0a
>>> implementation.
>>>
>>>
>>>> For this reason we could even think about a two phase release (first one
>>>> we focus on the client/common modules) and second we focus on everything
>>>> else.
>>>>
>>>
>>> I think the best way of doing that is putting down a quick roadmap of
>>> things to be done so that we can prioritize tasks and, eventually, split
>>> those items in different phases.
>>> BTW we are in the Incubator for a long time now so it'd be good to include
>>> also a release / graduation plan.
>>>
>>>
>>>> I hope you agree than one of our goal is to be mentioned here [0]and here
>>>> [1] in order to increase the project exposure.
>>>>
>>>> WDYT?
>>>>
>>>
>>> +1
>>>
>>> Tommaso
>>>
>>>
>>>
>>>>
>>>> Regards
>>>>
>>>> Antonio
>>>>
>>>> [0] http://oauth.net/code/
>>>> [1] http://oauth.net/2/
>>>>
>>>>
>>>>>
>>>>> I would propose to add that implementation in the current 2.0 impl,
>>>>> rather than continue developing old stuff...
>>>>>
>>>>> best,
>>>>> -Simo
>>>>>
>>>>> [1] https://issues.apache.org/jira/browse/INFRA
>>>>>
>>>>> http://people.apache.org/~simonetripodi/
>>>>> http://simonetripodi.livejournal.com/
>>>>> http://twitter.com/simonetripodi
>>>>> http://www.99soft.org/
>>>>
>>>>
>