[OAUTH-WG] Dynamic Client Registration Conference Call: Thu 22 Aug, 2pm PDT

Hannes Tschofenig <hannes.tschofenig@gmx.net> Sun, 18 August 2013 22:01 UTC

Return-Path: <hannes.tschofenig@gmx.net>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C55621F9343 for <oauth@ietfa.amsl.com>; Sun, 18 Aug 2013 15:01:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jR9ZuuqhAhqi for <oauth@ietfa.amsl.com>; Sun, 18 Aug 2013 15:01:11 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id F091321F91B7 for <oauth@ietf.org>; Sun, 18 Aug 2013 15:01:10 -0700 (PDT)
Received: from [172.16.42.99] ([80.168.129.202]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LgZ7h-1Vpmls3uC5-00numZ for <oauth@ietf.org>; Mon, 19 Aug 2013 00:01:10 +0200
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 19 Aug 2013 00:01:02 +0200
Message-Id: <DD8AFCA4-6F49-40F1-A65E-C1DDE45A9B32@gmx.net>
To: oauth mailing list <oauth@ietf.org>
Mime-Version: 1.0 (Apple Message framework v1085)
X-Pgp-Agent: GPGMail 1.4.1
X-Mailer: Apple Mail (2.1085)
X-Provags-ID: V03:K0:DvpC5ssrkvJ0f1/vPkTT7WGEGQB3OPmkDZ/+qeFbcfjkcHmJ99L Y9pSv9enZdCHsjX3TzIbc0nbkBxgErLh24YEp/Lkfevni2RN1KET7m4L0ofEuDAXU+pcrlC XYDJPnAsnin/CAzTlbO91lknDvc3a2nwIeI0jidL4dGcTMr1BLBcMdja/K1rhLa5jolM4v2 U8Xi5zYRRvAVRXFW0IgJA==
Subject: [OAUTH-WG] Dynamic Client Registration Conference Call: Thu 22 Aug, 2pm PDT
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: Sun, 18 Aug 2013 22:01:15 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Based on your feedback via the poll let us start with August 22nd with the first conference call. I will distribute the conference call details on Tuesday. 

Let us talk about the agenda. There were several items brought up in discussions, namely 

* Software assertions / software statements

We briefly discussed this topic at the IETF OAuth session but we may need more time to understand the implications for the current dynamic client registration document: 
http://www.ietf.org/proceedings/87/slides/slides-87-oauth-2.pptx

* SCIM vs. current dynamic client registration approach for interacting with the client configuration endpoint

In the past we said that it would be fine to have a profile defined in SCIM to provide the dynamic client registration for those who implement SCIM and want to manage clients also using SCIM. It might, however, be useful to compare the two approaches in detail to see what the differences are. 

* Interactions with the client registration endpoint 

Justin added some "life cycle" description to the document to motivate some of the design decisions. Maybe we need to discuss those in more detail and add further text. 
Additional text could come from the NIST Blue Button / Green Button usage. 

* Aspects that allow servers to store less / no state

- - From the discussions on the list it was not clear whether this is actually accomplishable with the current version of OAuth. We could explore this new requirement and try to get a better understanding how much this relates to dynamic client registration and to what extend it requires changes to the core spec. 


What would you like to start with? Other topics you would like to bring up? 
- -----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJSEULvAAoJEGhJURNOOiAtttEH/Aogg8Q/R/L9/mzU05IQbnze
AdXB1ZvySkV3jZT4I5shmP7hQr6mc6P6UdvyOrSjrvPlBHen55/oa5z7Cwchd1dk
dcDUEavbodjnm9SrOs0nKaTvdeZimFSBkGMrfhoTYLXpymP24F9PZgwUXdOcFocF
OiCs3qDajYaA395DCg5+4mOLQQgDnmy4drlgj2NPv1nMBRDBubzgAhJccwF2BLN9
IW7MAwTEu7vYT/gwIFzriPkui7gYpf8sAqsnzf/z7FtXbsP8imgOKUlQxzZzeSSP
QEb6+syyMD9Gt6wxQfWzyl5T0bYLP6DQ+ldZR8yGKCwb+2k3LN6Q8bIpj4mIERI=
=tkGT
- -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJSEUQfAAoJEGhJURNOOiAt8wkIAI3xgdsWuOB36KLiMLRUG+Zb
RvYqV+rOH80m7YVJcdOLjQJcpPqOIBdzq/yuNiAaF1uFJCqBn97ZQ/NLXLNGcg8x
wI/Laz7kP2U4B2trBTMtAf2wsY9uYw4Eh+eOEDKGF6cmkEzrzrlw4q/Sfu6vy181
VI+kqwzZ+iYX4iL3NYPlkg3rwF4OZ1v3T08Erg2SPrbmNd1TRfJJU8HrYFEJQo1q
p0RiLjcFFDCEZs0gDr9zliCXllV7J9h2ttqLq8+xwPATDuO6buQdFS9vZQ8t1u36
a0FIuy3NM8PQbblC3B5WumUjW4kntLV09ytYV8h6S8C/dgFwMqzAwEAeNx1exyE=
=3qNI
-----END PGP SIGNATURE-----