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

Axel.Nennker at telekom.de Axel.Nennker at telekom.de
Tue Aug 19 12:01:25 UTC 2014


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]
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20140819/c9a727c0/attachment-0001.html>


More information about the Openid-specs-ab mailing list