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 <[email protected]> > 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 >
