Re: [OAUTH-WG] OAuth WG Re-Chartering

George Fletcher <gffletch@aol.com> Wed, 21 March 2012 20:50 UTC

Return-Path: <gffletch@aol.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 6D9DF21F85B6 for <oauth@ietfa.amsl.com>; Wed, 21 Mar 2012 13:50:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 1vJvXtKYGuC7 for <oauth@ietfa.amsl.com>; Wed, 21 Mar 2012 13:50:48 -0700 (PDT)
Received: from imr-ma04.mx.aol.com (imr-ma04.mx.aol.com [64.12.206.42]) by ietfa.amsl.com (Postfix) with ESMTP id 1A38921F855D for <oauth@ietf.org>; Wed, 21 Mar 2012 13:50:48 -0700 (PDT)
Received: from mtaout-db06.r1000.mx.aol.com (mtaout-db06.r1000.mx.aol.com [172.29.51.198]) by imr-ma04.mx.aol.com (8.14.1/8.14.1) with ESMTP id q2LKoYCf011006; Wed, 21 Mar 2012 16:50:34 -0400
Received: from palantir.office.aol.com (palantir.office.aol.com [10.181.186.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-db06.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 8E7EAE0000D4; Wed, 21 Mar 2012 16:50:34 -0400 (EDT)
Message-ID: <4F6A3F22.6060809@aol.com>
Date: Wed, 21 Mar 2012 16:50:42 -0400
From: George Fletcher <gffletch@aol.com>
Organization: AOL LLC
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: "oauth@ietf.org" <oauth@ietf.org>
References: <B327D847-B059-41D7-A468-8B8A5DB8BFCE@gmx.net> <CAAz=scnGaFzNNHv1xEQa0hCiA2gup_J_86HyzCnd7P0YTqfFxw@mail.gmail.com> <999913AB42CC9341B05A99BBF358718D01382ADC@FIESEXC035.nsn-intra.net> <90C41DD21FB7C64BB94121FBBC2E723453AFF089FE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4F6A2D9E.3050503@lodderstedt.net> <9E23B8E0-057F-42C1-807D-36F35690C7B2@ve7jtb.com>
In-Reply-To: <9E23B8E0-057F-42C1-807D-36F35690C7B2@ve7jtb.com>
Content-Type: multipart/alternative; boundary="------------010701050101070003030507"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20110426; t=1332363034; bh=GUqsvWn8/hSpO6PH9wK9hksv3oc0iPe1a12V7ekPJxU=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=nrGYN8J3v5l3F/Y85bxdL4fSb81Xkx6UzWrm1SZzAVyOMBeWzVVCv2m5Po2qerMBW Y+4QPYWnxXuDTzcdApaH0lbqsiKozLFoE6LFIcSzsM2LgNTe9bNnZ60dW0Bn/RAZr9 Zt6UjSokf8TRzhcvHzAAqvwBbLL4vPbAeUJclYMA=
X-AOL-SCOLL-SCORE: 0:2:427461120:93952408
X-AOL-SCOLL-URL_COUNT: 0
x-aol-sid: 3039ac1d33c64f6a3f1a77aa
X-AOL-IP: 10.181.186.254
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
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: Wed, 21 Mar 2012 20:50:49 -0000

+1 to JWT and AS-RS communication over dynamic registration

On 3/21/12 3:52 PM, John Bradley wrote:
> I don't think dynamic registration completely removes the need for a public client, that can't keep secrets.
>
> While we did do dynamic client registration for Connect that is a more constrained use case.
> I would put JWT and AS-RS communication as higher priorities than dynamic registration.
> Partially because they are more self contained issues.
>
> John B.
> On 2012-03-21, at 4:35 PM, Torsten Lodderstedt wrote:
>
>> In my opinion, dynamic client registration would allow us to drop public client thus simplifying the core spec.
>>
>> regards,
>> Torsten.
>>
>> Am 15.03.2012 16:00, schrieb Eran Hammer:
>>> I believe most do, except for the dynamic client registration. I don't have strong objections to it, but it is the least important and least defined / deployed proposal on the list. The AS->RS work is probably simpler and more useful at this point.
>>>
>>> EH
>>>
>>>> -----Original Message-----
>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>>>> Of Tschofenig, Hannes (NSN - FI/Espoo)
>>>> Sent: Thursday, March 15, 2012 4:47 AM
>>>> To: ext Blaine Cook; Hannes Tschofenig
>>>> Cc: oauth@ietf.org
>>>> Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
>>>>
>>>> Hi Blaine,
>>>>
>>>> These are indeed good requirements you stated below.
>>>>
>>>> When you look at the list of topics do you think that the proposed items
>>>> indeed fulfill them?
>>>>
>>>> Ciao
>>>> Hannes
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>>>>> Of ext Blaine Cook
>>>>> Sent: Thursday, March 15, 2012 1:31 PM
>>>>> To: Hannes Tschofenig
>>>>> Cc: oauth@ietf.org WG
>>>>> Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
>>>>>
>>>>> On 14 March 2012 20:21, Hannes Tschofenig
>>>> <hannes.tschofenig@gmx.net>
>>>>> wrote:
>>>>>> So, here is a proposal:
>>>>>>
>>>>>> [Editor's Note: New work for the group. 5 items maximum! ]
>>>>>>
>>>>>> Aug. 2012    Submit 'Token Revocation' to the IESG for consideration
>>>>> as a Proposed Standard
>>>>>> Nov. 2012    Submit 'JSON Web Token (JWT)' to the IESG for
>>>>> consideration as a Proposed Standard
>>>>>> Nov. 2012    Submit 'JSON Web Token (JWT) Bearer Token Profiles for
>>>>> OAuth 2.0' to the IESG for consideration
>>>>>> Jan. 2013    Submit 'OAuth Dynamic Client Registration Protocol' to
>>>>> the IESG for consideration as a Proposed Standard
>>>>>> Sep. 2012    Submit 'OAuth Use Cases' to the IESG for consideration
>>>>> as an Informational RFC
>>>>>
>>>>> This looks great to me.
>>>>>
>>>>> I have serious concerns about feature-creep, and think that the OAuth
>>>>> WG should strongly limit its purview to these issues. In general, I
>>>>> think it prudent for this working group in particular to consider
>>>>> standardisation of work only under the following criteria:
>>>>>
>>>>> 1. Proposals must have a direct relationship to the mechanism of OAuth
>>>>> (and not, specifically, bound to an application-level protocol).
>>>>> 2. Proposals must have significant adoption in both enterprise and
>>>>> startup environments.
>>>>> 3. Any proposal must be driven based on a consideration of the
>>>>> different approaches, as adopted in the wild, and strive to be a
>>>>> better synthesis of those approaches, not a means to an end.
>>>>>
>>>>> These are the constraints with which I started the OAuth project, and
>>>>> they're more relevant than ever. I'd hate to see OAuth fail in the end
>>>>> because of a WS-*-like death by standards-pile-on.
>>>>>
>>>>> b.
>>>>> _______________________________________________
>>>>> 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
>>> _______________________________________________
>>> 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
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth