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

Nat Sakimura sakimura at gmail.com
Wed Aug 20 01:18:48 UTC 2014


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>:

> 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] *On Behalf Of *Mike Jones
> *Sent:* Tuesday, August 19, 2014 2:04 AM
> *To:* Nat Sakimura
>
> *Cc:* 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 <sakimura at gmail.com>]
> *Sent:* Monday, August 18, 2014 4:53 PM
> *To:* Mike Jones
> *Cc:* 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>:
>
> 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] *On Behalf Of *Nat Sakimura
> *Sent:* Monday, August 18, 2014 4:38 PM
> *To:* 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/dc9bef75/attachment.html>


More information about the Openid-specs-ab mailing list