[OAUTH-WG] items for the Vancouver agenda

Phil Hunt <phil.hunt@oracle.com> Fri, 25 October 2013 20:41 UTC

Return-Path: <phil.hunt@oracle.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id C80E811E81ED for <oauth@ietfa.amsl.com>; Fri, 25 Oct 2013 13:41:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.267
X-Spam-Status: No, score=-6.267 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id my8QMfUyPt6O for <oauth@ietfa.amsl.com>; Fri, 25 Oct 2013 13:41:15 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com []) by ietfa.amsl.com (Postfix) with ESMTP id 498E111E8108 for <oauth@ietf.org>; Fri, 25 Oct 2013 13:41:14 -0700 (PDT)
Received: from acsinet22.oracle.com (acsinet22.oracle.com []) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r9PKfClV008036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <oauth@ietf.org>; Fri, 25 Oct 2013 20:41:13 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com []) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9PKfCGe011563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <oauth@ietf.org>; Fri, 25 Oct 2013 20:41:12 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com []) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9PKfCTO000905 for <oauth@ietf.org>; Fri, 25 Oct 2013 20:41:12 GMT
Received: from [] (/ by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 25 Oct 2013 13:41:12 -0700
From: Phil Hunt <phil.hunt@oracle.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_0416F88A-F6DE-4B63-9932-BDA48B745925"
Message-Id: <CA6AC362-0A04-4C9F-BFFA-A0190858D73F@oracle.com>
Date: Fri, 25 Oct 2013 13:41:14 -0700
To: oauth list <oauth@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
X-Mailer: Apple Mail (2.1510)
X-Source-IP: acsinet22.oracle.com []
Subject: [OAUTH-WG] items for the Vancouver agenda
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
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: Fri, 25 Oct 2013 20:41:21 -0000


I'd like to request some time to present the Software Statement and Client Association drafts as part of the overall Client registration discussion. The method Tony and I have proposed reflects a pattern (token swap using the 4.5 extension) that is actually in wide use today.

I would also like to hear more about John Bradley and Justin Richer's new http://www.ietf.org/internet-drafts/draft-bradley-stateless-oauth-client-00.txt draft.

There is also yet another method of handling "association" (by using a split client with a server side client component holding client creds) that Dick Hardt talked about at IIW.  If Dick is unable to attend, I would be happy to try to do justice to his idea.

If we have time, it may be worthwhile discussing authentication draft that Tony and I submitted in Berlin.  In particular, now that OIDC is finalizing, we should discuss whether it is better to align the user authen for clients draft 100% with OIDC or whether to keep it in a different direction.  As it stands now, the draft is only partially aligned.  I recognize this draft is NOT within the current charter, however if the group wants to discuss it (because it is timely), I am willing to put something together.

Nat's TSCE draft also falls into the category of non-charter items. I think this is potentially an important extension or an errata to the current draft and is also a worthwhile new business item.

Finally, I'm not sure who might be able to lead this (Tim?), but there was some interesting views expressed by Google staffers at this weeks IIW in Mountain View that seem to indicate that the need for client credentials in mobile apps may not need to be as strong as we thought or needed at all. This has interesting implications for the registration drafts we are discussing.