Amber's implementation goals/policy

[Antonio Sanso <as...@adobe.com>]

Hi *,

I'd have a question/doubt about a Jira ticket I have issued yesterday [0] and I hope this list might help me to address it correctly.
Now as you can see from [0] it is about parts of the specification like :

state
        REQUIRED if the "state" parameter was present in the client
        authorization request.  The exact value received from the
        client.

Now IMHO there are two distinct way a "library" can address it:

a) provide the API namely OAuthAuthorizationResponseBuilder#setState and "trust" that the AMBER user will do the right thing e.g. using the API in his implementation, as in [1]


OAuthResponse resp = OAuthASResponse
             .authorizationResponse(HttpServletResponse.SC_FOUND)
             .setCode(oauthIssuerImpl.authorizationCode())

             .setState(request#getParameter)
             .location(redirectURI)
             .buildQueryMessage();

b) integrate this "rule" in the AMBER "framework"

IMHO b) fits more with the description of AMBER provided e.g. in the report  "....an unconditionally compliant implementation".

I also think that the specification is full of cases like  [0] and we need to take a clear steering where we would like to go ( a) or b) ??)

WDYT?

Regards

Antonio

[0] https://issues.apache.org/jira/browse/AMBER-45
[1] https://cwiki.apache.org/confluence/display/AMBER/OAuth+2.0+Authorization+Server

Re: Amber's implementation goals/policy

[Tommaso Teofili <to...@gmail.com>]

Hello Antonio,

I do agree the option b) is the definitely the way to go.
Cases like this one you mention are quite common in wide specifications
(think to HTTP 1.x spec which is full of COULD / SHOULD rules) but I agree
it is part of our effort to provide strict unconditional compliance to
OAuth spec.

My 2 cents.
Tommaso

2011/12/9 Antonio Sanso <as...@adobe.com>

> Hi *,
>
> I'd have a question/doubt about a Jira ticket I have issued yesterday [0]
> and I hope this list might help me to address it correctly.
> Now as you can see from [0] it is about parts of the specification like :
>
> state
>        REQUIRED if the "state" parameter was present in the client
>        authorization request.  The exact value received from the
>        client.
>
> Now IMHO there are two distinct way a "library" can address it:
>
> a) provide the API namely OAuthAuthorizationResponseBuilder#setState and
> "trust" that the AMBER user will do the right thing e.g. using the API in
> his implementation, as in [1]
>
>
> OAuthResponse resp = OAuthASResponse
>             .authorizationResponse(HttpServletResponse.SC_FOUND)
>             .setCode(oauthIssuerImpl.authorizationCode())
>
>             .setState(request#getParameter)
>             .location(redirectURI)
>             .buildQueryMessage();
>
> b) integrate this "rule" in the AMBER "framework"
>
> IMHO b) fits more with the description of AMBER provided e.g. in the
> report  "....an unconditionally compliant implementation".
>
> I also think that the specification is full of cases like  [0] and we need
> to take a clear steering where we would like to go ( a) or b) ??)
>
> WDYT?
>
> Regards
>
> Antonio
>
> [0] https://issues.apache.org/jira/browse/AMBER-45
> [1]
> https://cwiki.apache.org/confluence/display/AMBER/OAuth+2.0+Authorization+Server
>