[Openid-specs-ab] Session - session_state in UTF-8?

Mike Jones Michael.Jones at microsoft.com
Wed Aug 20 01:21:37 UTC 2014


Of course, per the discussion during the last call, we could eliminate the space ambiguity by saying that by “space”, we mean the ASCII space character 0x20.  That by itself doesn’t necessitate the restriction.

I am a little worried that some clever implementer may be representing session state as a JSON object.  If we outlaw double-quote, we’ll break their code.

                                                                -- Mike

From: Nat Sakimura [mailto:sakimura at gmail.com]
Sent: Tuesday, August 19, 2014 6:19 PM
To: Axel Nennker
Cc: Mike Jones; openid-specs-ab at lists.openid.net
Subject: Re: [Openid-specs-ab] Session - session_state in UTF-8?

I am no expert on it, but apparently unicode defines bunch of space chars like:

U+2000 en quad
U+2001 em quad
U+2002 en space
U+2003 em space
U+2004 three-per-em space
U+2005 four-per-em space

So, my concern is two fold:


  1.  If we say "space", if it were to be chosen form NQCHAR, it always will be 0x20. Otherwise, it is ambiguous.
  2.  If we allowed the string to be UTF-8, is there not some chance that  underlying processing middleware normalizes these space chars to 0x20?

Nat


2014-08-19 21:01 GMT+09:00 <Axel.Nennker at telekom.de<mailto:Axel.Nennker at telekom.de>>:
Nat, where do you think that problems might arise? Could you please be more specific?

Regarding the spec in general:

-          I guess the spec does the space-delimited-string trickery because some implementations of postMessage barf on message being a JSON object, right?

Do we really need to handle these implementation’s fault?
Why not use (example in 4.1)
var mes = {‘client_id’: client_id, ‘session_state’:session_state};
and handle this fault through JSON.stringify only if necessary as an implementers note?
if the values are JSON strings: do we have a problem with charsets? Or does this potential problem arise from the use of the hash function in the example?

-          I think that the required test “Validate message origin” should be part of the example


   // Do we trust the sender of this message?
        If (event.origin !== rp_origin)
               return;

-          The variable “message” appears from nowhere in the example
var message = e.data; // {‘client_id’: client_id, ‘session_state’:session_state}

Do we really need the hashing stuff in the example? Why the double use of salt in the 4.2 example?

-Axel

http://www.w3.org/html/wg/drafts/html/master/infrastructure.html#safe-passing-of-structured-data
https://developer.mozilla.org/en-US/docs/Web/API/Window.postMessage



From: openid-specs-ab-bounces at lists.openid.net<mailto:openid-specs-ab-bounces at lists.openid.net> [mailto:openid-specs-ab-bounces at lists.openid.net<mailto:openid-specs-ab-bounces at lists.openid.net>] On Behalf Of Mike Jones
Sent: Tuesday, August 19, 2014 2:04 AM
To: Nat Sakimura

Cc: openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>
Subject: Re: [Openid-specs-ab] Session - session_state in UTF-8?

I’m not sure.  It would be good to hear from implementers.

From: Nat Sakimura [mailto:sakimura at gmail.com]
Sent: Monday, August 18, 2014 4:53 PM
To: Mike Jones
Cc: openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>
Subject: Re: [Openid-specs-ab] Session - session_state in UTF-8?

Agreed. NQCHAR would be good.

Is it a good idea or am I just being overly anxious?

Nat

2014-08-19 8:43 GMT+09:00 Mike Jones <Michael.Jones at microsoft.com<mailto:Michael.Jones at microsoft.com>>:
If we’re going to do this, we should restrict it to the NQCHAR set from http://tools.ietf.org/html/rfc6749#appendix-A.1:

     NQCHAR     = %x21 / %x23-5B / %x5D-7E

(printable ASCII without double quote or backslash)

                                                                -- Mike

From: openid-specs-ab-bounces at lists.openid.net<mailto:openid-specs-ab-bounces at lists.openid.net> [mailto:openid-specs-ab-bounces at lists.openid.net<mailto:openid-specs-ab-bounces at lists.openid.net>] On Behalf Of Nat Sakimura
Sent: Monday, August 18, 2014 4:38 PM
To: openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>
Subject: [Openid-specs-ab] Session - session_state in UTF-8?

One question. This just occurred to me when reading the proposed text on issue #915 ( https://bitbucket.org/openid/connect/issue/915/ ).

Do we want to restrict the repertoire allowed in the session_state string?
I am a bit concerned that bunch of unexpected consequences may happen when multi-bytes chars are used in it as it will be transmitted over the http param and usually is dealt with the middleware the software is using.
If we are sure that it would not, I am fine with it, but if we are not sure, it may be better to constrain the repertoire to ASCII etc. to be on the safe side.

Perhaps I should reopen issue #917 (https://bitbucket.org/openid/connect/issue/917) ?

--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en



--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en



--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20140820/2944fd7a/attachment-0001.html>


More information about the Openid-specs-ab mailing list