Hi Hoang, It's great to see your interest in contributing to the Apache Amber project.
For me your explanation looks very good. I agree on points 1 and 2. Existing client registration in Amber is an implementation of the external draft. IMHO would be good to create additional module for point 3 to not mix both specifications. Feel free to submit patch then we will be able to review it and provide a feedback. Cheers, Lukasz Moren On Tue, Jul 12, 2011 at 7:59 AM, Hoang Minh Tien < [email protected]> wrote: > Dear all, > As oAuth 2-18 specification is ready, I have some suggestions for updating > Amber to match with this specification. This is only my first experience > with Amber, so please give me your feedbacks as details as possible. Thank > you all in advance. > In my opinion, the changes should be performed on 3 main processes, mostly > related to validators: > i) Authorization request: there is no more code and token request type, > + The class CodeTokenValidator is obsolete and could be removed > + In OAuthTokenRequest.**initValidator remove the line put > ResponseType.CODE_AND_TOKEN in validators. > ii) Access Token request: the authentication between the client and > authorization enpoint could be happened earlier (Authorization header will > be shown in each request from client) in this case, the client_id or > client_secret will not be considered as required parameters in each access > token request as well as the redirect_uri which is also provided in > registration process. > + My suggestion are removing redirect_url as required parameter and adding > an authorization header check in AbstractValidator, in each constructor of > derived validator check the existence of authorization header in the > request, to decide to add client_id or client_secret as required parameters > or not. The validators involved are: AbstractValidator, > AuthorizationCodeValidator, PasswordValidator, AssertionValidator (only > grant_type is required), RefreshTokenValidator > + There is a newly added profile “client credentials” with > grant_type=client_credentials, which is reserved only for private client and > required only the validation of grant_type value. So we could > • Add a new validator class inherit from AbstractValidator, may be > ClientCredentialValidator with grant_type is set as required parameter. > • Add an enum to GrantType > • In OAuthTokenRequest.**initValidator, add this enum value in validator. > iii) Client registration: a new section for client registration is created > in oAuth 2-18 (the status is still Pending consensus) requires the custom > provide the custom type when perform registration. Could we consider of > adding it to existing client registration code? > Besides, I think we should change oauth_token to access_token in > BodyTokenExtractor.**getAccessToken and QueryTokenExtractor.**getAccessToken > of resource server because oauth_token is no more used. > Waiting for your opinion. > Thanks and kind regards, > Tien. >
