[Openid-specs-ab] Issue #887: Multiple Response Types - Content that SHOULD be fragment encoded MUST NOT be query encoded (openid/connect)

Breno de Medeiros breno at google.com
Tue Oct 15 02:09:28 UTC 2013


Another transport mode (in addition to posmessage) that is available in
immediate mode is CORS.

Agree with the proposed clarification of disallowing query encoding.


On Mon, Oct 14, 2013 at 5:42 PM, Michael Jones
<issues-reply at bitbucket.org>wrote:

> New issue 887: Multiple Response Types - Content that SHOULD be fragment
> encoded MUST NOT be query encoded
>
> https://bitbucket.org/openid/connect/issue/887/multiple-response-types-content-that
>
> Michael Jones:
>
> We talked about this on the call today.  I asked why responses are
> described as “SHOULD be fragment encoded”, rather than “MUST be fragment
> encoded” in the OAuth Multiple Response Types document.  John said that the
> SHOULDs are to leave the door open for using PostMessage - not to allow
> query encoding.
>
> He pointed out that the HTTP Referer header includes query parameters, and
> so any query parameter encoded content will leak to third parties.  This is
> a huge security hole that is prevented by the fragment encoding.
>
> The only OAuth value that can be safely query encoded is "code", and then
> when using a confidential client.  That's OK because the Code is not useful
> to a third party that doesn't have the Client Secret.
>
> The working group decided to clarify the specs to explicitly prohibit
> (MUST NOT) query encoding any parameters other than Code.
>
> Responsible: mbj
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>



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


More information about the Openid-specs-ab mailing list