IETF Logo Mail Archive

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

"Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com> Tue, 20 August 2013 14:53 UTC

Return-Path: <hannes.tschofenig@nsn.com>
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 2D4EF11E8238 for <oauth@ietfa.amsl.com>; Tue, 20 Aug 2013 07:53:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.196
X-Spam-Level:
X-Spam-Status: No, score=-106.196 tagged_above=-999 required=5 tests=[AWL=0.403, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 XAorXdxn01kS for <oauth@ietfa.amsl.com>; Tue, 20 Aug 2013 07:53:29 -0700 (PDT)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 149A711E80E3 for <oauth@ietf.org>; Tue, 20 Aug 2013 07:53:24 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r7KErMF5013345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 Aug 2013 16:53:22 +0200
Received: from USCHHTC001.nsn-intra.net ([10.159.161.14]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r7KEqbm6023017 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 20 Aug 2013 16:53:21 +0200
Received: from USCHHTC004.nsn-intra.net (10.159.161.17) by USCHHTC001.nsn-intra.net (10.159.161.14) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 20 Aug 2013 09:51:50 -0500
Received: from USCHMBX001.nsn-intra.net ([169.254.1.221]) by USCHHTC004.nsn-intra.net ([10.159.161.17]) with mapi id 14.03.0123.003; Tue, 20 Aug 2013 09:51:50 -0500
From: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
To: ext Phil Hunt <phil.hunt@oracle.com>, Hannes Tschofenig <hannes.tschofenig@gmx.net>
Thread-Topic: [OAUTH-WG] Dynamic Client Registration Conference Call: Thu 22 Aug, 2pm PDT
Thread-Index: AQHOnHFT52T2wsUCcUGLqz5mo8MPjZmd+56w
Date: Tue, 20 Aug 2013 14:51:49 +0000
Message-ID: <1373E8CE237FCC43BCA36C6558612D2AA26F2C@USCHMBX001.nsn-intra.net>
References: <DD8AFCA4-6F49-40F1-A65E-C1DDE45A9B32@gmx.net> <76E10B6F-F28D-456D-84EA-65FF25AEB744@oracle.com>
In-Reply-To: <76E10B6F-F28D-456D-84EA-65FF25AEB744@oracle.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.159.161.118]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 4201
X-purgate-ID: 151667::1377010402-00003561-AEDAEAB7/0-0/0-0
Cc: oauth mailing list <oauth@ietf.org>
Subject: Re: [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: Tue, 20 Aug 2013 14:53:49 -0000

Hi Phil, 


> I think we should start by reviewing use cases taxonomy.


What do you mean by "use cases taxonomy"? What exactly would we discuss under that item?

> 
> Then a discussion on any client_id assumptions and actual requirements
> for each client case. Why is registration needed for each case?

I guess you are bringing the use case to the table where there is no client id needed (?) or where the client id is provided by yet another party (other than the one running the AS). 

> 
> The statement can solve some complication but should be put in context
> of use cases.
> 

Ciao
Hannes

> Phil
> 
> On 2013-08-18, at 15:01, Hannes Tschofenig <hannes.tschofenig@gmx.net>
> wrote:
> 
> > -----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-----
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

v2.23.0 | Report a Bug | By Email