Re: [OAUTH-WG] A Proposal for Dynamic Registration

Leif Johansson <leifj@mnt.se> Mon, 12 August 2013 10:52 UTC

Return-Path: <leifj@mnt.se>
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 52F7321E80CF for <oauth@ietfa.amsl.com>; Mon, 12 Aug 2013 03:52:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.691
X-Spam-Level:
X-Spam-Status: No, score=-1.691 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1]
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 H82rWX8VJ4L4 for <oauth@ietfa.amsl.com>; Mon, 12 Aug 2013 03:52:23 -0700 (PDT)
Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0BB21E8117 for <oauth@ietf.org>; Mon, 12 Aug 2013 02:34:54 -0700 (PDT)
Received: by mail-lb0-f180.google.com with SMTP id a16so4661739lbj.11 for <oauth@ietf.org>; Mon, 12 Aug 2013 02:34:24 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=vCe1kTeBs5FR/xvpQJr6gW+yW0QqOkwv4A7mBX8qLco=; b=RRlxZF3Rb7tJ1NwHlJixfqX56CLxASpCyEFoscLx60+RnD6silUK5qld6gVd9vb9tp kWplcUlDA9YTc7dichQxA96PGaQNvRYiv2H+X9MT1dsm0VmCIHj6ZyQr6F7blOSvLJSv 1ByGsLSmEG3QbQvJjj4dKoDYV7QUjOcY0O8W9fCPALz4Op9IVtPdsALNGv2rd/mDRIoV 9nPYJ2aH4OgjILXqeiYNA6vVOGu3KWjdIv4mktryQYs0Fl9MZI9R0inACIZQmtVV+Rwm ozoBiQ3TGPqYyzDggPx6TMNIQAOt49a34Trg1jfEFaH4d2yVr5Z+fY6Etk/Cpy1OUlDO Q0nA==
X-Gm-Message-State: ALoCoQmZOw43db5f/hI7ETBrXH5URWUVbkI9LRA8PXe7rd3I5p35uajPBIa4iDaJXfW8HEbmeVnc
X-Received: by 10.152.9.194 with SMTP id c2mr11128875lab.83.1376300064117; Mon, 12 Aug 2013 02:34:24 -0700 (PDT)
Received: from [172.20.10.6] (2.69.142.214.mobile.tre.se. [2.69.142.214]) by mx.google.com with ESMTPSA id js17sm11496544lab.5.2013.08.12.02.34.22 for <oauth@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 12 Aug 2013 02:34:23 -0700 (PDT)
Message-ID: <5208AC1A.5060606@mnt.se>
Date: Mon, 12 Aug 2013 11:34:18 +0200
From: Leif Johansson <leifj@mnt.se>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7
MIME-Version: 1.0
To: oauth@ietf.org
References: <52016822.2090703@mitre.org>
In-Reply-To: <52016822.2090703@mitre.org>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [OAUTH-WG] A Proposal for Dynamic Registration
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: Mon, 12 Aug 2013 10:53:19 -0000

On 08/06/2013 11:18 PM, Justin Richer wrote:

<snip>
>  - OAuth Dynamic Registration
>  - SCIM-based OAuth Dynamic Registration
>  - Software Statements for OAuth Dynamic Registration
>

This thread makes me think we should break out the EXPERIMENTAL
track: spin two or more proposed solutions as EXPERIMENTAL. Let the
various groups do what they're gona do (which they'll do anyway) and
the the chips fall where they may.

Tony is right in interpreting the discussions in Berlin as quite fractured.
Pushing for standards track seems premature.

OTOH the transition from EXPERIMENTAL to STANDARDS TRACK can
be as quick as a couple of I-Ds describing the outcome of the
implementation and deployment work that will happen anyway (as
you so correctly observe) after which the WG decides how to move
forward.

Since bb+ and openidc will do dynreg anyway the document track
doesn't really matter which means the usual "vendors won't implement
unless its a real RFC"-argument doesn't apply here anyway.

        Cheers Leif