[OAUTH-WG] session status change notification questions

"Brock Allen" <brockallen@gmail.com> Mon, 12 January 2015 13:11 UTC

Return-Path: <brockallen@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB39F1A0191 for <oauth@ietfa.amsl.com>; Mon, 12 Jan 2015 05:11:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ezMcQrqJ_2R for <oauth@ietfa.amsl.com>; Mon, 12 Jan 2015 05:11:41 -0800 (PST)
Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3AAC1A1B9B for <OAuth@ietf.org>; Mon, 12 Jan 2015 05:11:40 -0800 (PST)
Received: by mail-pa0-f47.google.com with SMTP id kq14so31952694pab.6 for <OAuth@ietf.org>; Mon, 12 Jan 2015 05:11:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:thread-index:content-language; bh=Z00FmXzeIAa5DY1m21bHz68eVr8W0oXGgp8zYSQR/dk=; b=qGv416x3dvgq9Jo6NQ2uosR0JYZjJGAG9QdtdKRh5kp25TI/i/hLvDl3bkhAC4Yccf sfozmLe6FaQqxAWfgnCYS1nI559FVs/z+5jYhTbTUhVtbyId4uy7+PtsRkQpsjK0bTTB K+6oIws356K43J5mSrIxLljzB4NGyJu0SshGnTNz4sWl+uDOh7hGwHD+1V29QMdsJxN+ cTZptWROeevqBCA02440aLZcfnOoZ3k61o3D1Qm2sVsfRAjvQtr2Za2A64szAvWEhGbA q1Z6slU8mRR2g+cdep9JewiGORnmBlgSVEznfU6cMXH4Y0cBf4J16X0l5FNuiijw98QB VJgQ==
X-Received: by 10.66.121.230 with SMTP id ln6mr43996415pab.82.1421068300087; Mon, 12 Jan 2015 05:11:40 -0800 (PST)
Received: from monk (ip24-250-56-242.ri.ri.cox.net. [24.250.56.242]) by mx.google.com with ESMTPSA id pf10sm14319866pbc.82.2015.01.12.05.11.37 for <OAuth@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 12 Jan 2015 05:11:38 -0800 (PST)
From: Brock Allen <brockallen@gmail.com>
To: OAuth@ietf.org
References:
In-Reply-To:
Date: Mon, 12 Jan 2015 08:11:20 -0500
Message-ID: <002401d02e69$43284220$c978c660$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0025_01D02E3F.5A5372A0"
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AdAlLOwe2gYzYJeGR8SIW2KjtIM6ngJPC9cQ
Content-Language: en-us
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/SofnYlYZf-75rFrrxT2e7kWyB6Y>
Subject: [OAUTH-WG] session status change notification questions
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Jan 2015 13:11:43 -0000

A couple of questions about the session management spec related to the status change notifications (section 4): 

 

1) Is there a working reference implementation of the JavaScript that goes with the current draft of the spec?

 

 

2) For the statement from section 4.2: “The OP iframe MUST enforce that the caller has the same origin as its parent frame.” I’m uncertain how to do this in the OP iframe, given that it seems to be a cross-origin security concern to ascertain the origin of the parent window. I don’t think ‘referrer’ is the most reliable approach.

 

 

3) The spec states that the OP iframe and the RP iframe should be both contained within the main RP window (so the iframes are siblings). Is there a reason the RP iframe can’t contain the OP iframe?

 

If it can, then this would address my question #2 above, as the source.window (on the message event args) can be compared to the parent.window to ensure that only the parent is sending the messages.

 

 

Thanks.

 

-Brock