[Openid-specs-ab] POST body encoded bearer token

[Breno de Medeiros]

Mike, thanks for the explanation. I agree with the proposed resolution of
making it a WARNING.

On Wed, Mar 25, 2015 at 10:07 AM, Mike Jones <Michael.Jones at microsoft.com>
wrote:

>  Thanks for bringing this to our attention, Breno.
>
>
>
> Reading
> http://openid.net/specs/openid-connect-core-1_0.html#UserInfoRequest,
> http://openid.net/specs/openid-connect-basic-1_0.html#UserInfoRequest,
> and http://tools.ietf.org/html/rfc6750#section-2.2, not requiring this
> functionality seems like a reasonable request, from a conformance
> perspective.
>
>
>
> From an interop perspective, it’s there to give RPs that can’t generate an Authorization: Bearer header a way to request the information without sending the bearer token as a query parameter – a bad security practice.  http://tools.ietf.org/html/rfc6750#section-2.2 motivates the existence of the body method as being for “contexts where participating browsers do not have access to the "Authorization" request header field”.  Whereas http://tools.ietf.org/html/rfc6750#section-2.3 says that the query parameter method “its use is not recommended, due to its security deficiencies”.
>
>
>
> Since there is a good reason, from an interop perspective, for servers to support this method, but that it clearly shouldn’t be required for certification, I would propose that we leave the test, but change the result of not passing it from being an ERROR to being a WARNING.  That way, servers can still test their support for the feature, but not supporting it doesn’t prevent certification.
>
>
>
> Please consider that resolution.  Given that the test suite is now frozen, it will require a working group decision to make this change.  We will take this up on the working group call at 7am Pacific Time tomorrow - https://www3.gotomeeting.com/join/181372694 or +1 (646) 982-0002, access code 181-372-694.  Please join it if you can.
>
>
>
>                                                                             -- Mike
>
>
>
> P.S.  I’ll note that the certification tests have two purposes – certification and increasing interop, which are related, but not strictly the same.  The test software tests include a bunch of functionality that isn’t strictly required for certification, such as returning specific requested claims in response to using scopes, that you can pass certification without.  It issues warnings if the preferred behavior isn’t implemented.  This would be another such a case.
>
>
>
> *From:* Breno de Medeiros [mailto:breno at google.com]
> *Sent:* Wednesday, March 25, 2015 11:01 AM
> *To:* Roland Hedberg
> *Cc:* William Denniss; Adam Dawes; Roshni Chandrashekhar; Naveen Agarwal;
> Mike Jones
> *Subject:* POST body encoded bearer token
>
>
>
> We have noticed that the compliance suite enforces that userinfo endpoint
> supports authentication via www-form-url-encoded parameter.
>
>
>
> This test is not implied by the specs.'
>
>
>
> 1. The bearer spec mandates header parameter. Body encoded is MAY, not
> even SHOULD.
>
> 2. The OpenID connect spec only mandates support for UserInfo POST
> requests and compliance with Bearer header spec.
>
>
>
> Supporting only the encoding of the bearer as Header transport in a POST
> request is compliant with both specs.
>
>
>
> Years ago, when the Bearer spec reached final form, we made a conscious
> decision not to support it because of extensive ramifications for
> performance of our shared API serving infrastructure. This decision is not
> going to be revisited.
>
>
>
> Please remove the test OP-UserInfo-Body as it is not part of spec
> compliance surface in what I believe is a natural reading of the specs.
>
>
>
> Thanks,
>
>
>
> --
>
> --Breno
>



-- 
--Breno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20150325/a4078d4e/attachment.html>