Hi + (hope at least one will read my message :D)

On Tue, Feb 7, 2012 at 10:03 AM, Tommaso Teofili
<[email protected]> wrote:
> 2012/2/6 Raymond Feng <[email protected]>
>
>> Hi,
>>
>> Adding a layer that supports the extensions of oAuth 2.0 (the spec already
>> mentions the extensions) is definitely desired.
>>
>
> +1
>

 +1 as well

>
>>
>> Based on my usage/experience with Amber, we should probably go beyond just
>> the resource server that allows multiple types of token. I would like to
>> see some SPIs that allow the adopters of oAuth 2.0 to plug in their own
>> infrastructures. To name a few,
>>
>> * TokenGenerator (generating the tokens based on the token types)
>> * TokenManager (managing the tokens)
>> * Authenticator (authenticates the client and resource owners)
>>
>
> definitely +1 here too!
>

that is something Pid and I tried to work on in the spec-api package,
see 
https://svn.apache.org/repos/asf/incubator/amber/trunk/spec-api/src/main/java/org/apache/amber/server

>
>>
>> We also need to have a way to wire the service providers into the oAuth
>> 2.0 base. Something like JAX-RS ContextResolver, Google Guice or the JDK
>> META-INF/services/ pattern can be used to connect the pieces together.
>>
>
> I agree and I'd be keen to use base JDK META-INF/services method to avoid
> introducing other dependencies.
>

+1 for keeping Amber with as less dependencies as possible, but
keeping an eye with external providers (see the BeanValidation
specification) so my *personal* vision is implementing a set of
interfaces for providers AND some _separated_ implementations (like
the one mentioned) but no once defined by default (or maybe the JKD
SPI that comes "for free")

all the best, have a nice day!
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/

Reply via email to