Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration

Mike Jones <Michael.Jones@microsoft.com> Wed, 22 May 2013 18:30 UTC

Return-Path: <Michael.Jones@microsoft.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 DDF8C11E8106 for <oauth@ietfa.amsl.com>; Wed, 22 May 2013 11:30:35 -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=[AWL=-0.000, 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 fNQLJbSCvx+Z for <oauth@ietfa.amsl.com>; Wed, 22 May 2013 11:30:24 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0208.outbound.protection.outlook.com [207.46.163.208]) by ietfa.amsl.com (Postfix) with ESMTP id A402621F8D69 for <oauth@ietf.org>; Wed, 22 May 2013 11:30:23 -0700 (PDT)
Received: from BL2FFO11FD011.protection.gbl (10.173.161.203) by BL2FFO11HUB012.protection.gbl (10.173.161.118) with Microsoft SMTP Server (TLS) id 15.0.698.0; Wed, 22 May 2013 18:30:22 +0000
Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD011.mail.protection.outlook.com (10.173.161.17) with Microsoft SMTP Server (TLS) id 15.0.698.0 via Frontend Transport; Wed, 22 May 2013 18:30:21 +0000
Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.161]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0318.003; Wed, 22 May 2013 18:30:06 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: Justin Richer <jricher@mitre.org>, "oauth@ietf.org" <oauth@ietf.org>
Thread-Topic: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration
Thread-Index: AQHOVxj2kVRUbqGmb0Chrsy2ymzpkpkRhUOw
Date: Wed, 22 May 2013 18:30:05 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739436774FFFA@TK5EX14MBXC283.redmond.corp.microsoft.com>
References: <MLQM-20130520122606192-37488@mlite.mitre.org> <519D0C4D.60002@mitre.org>
In-Reply-To: <519D0C4D.60002@mitre.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.34]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436774FFFATK5EX14MBXC283r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(78114002)(189002)(51444003)(24454002)(479174002)(377454002)(54316002)(49866001)(74662001)(6806003)(16406001)(512954002)(16236675002)(31966008)(33656001)(53806001)(81342001)(4396001)(46102001)(44976003)(15202345002)(79102001)(47976001)(81542001)(55846006)(47736001)(47446002)(74502001)(54356001)(76482001)(51856001)(71186001)(56776001)(69226001)(74366001)(50986001)(74876001)(74706001)(20776003)(77982001)(80022001)(56816002)(63696002)(59766001)(65816001)(66066001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB012; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en;
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 0854128AF0
Subject: Re: [OAUTH-WG] Proposed Syntax Changes in 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: Wed, 22 May 2013 18:30:36 -0000

I'm neutral with changing (1) and (2) because they're not highly breaking changes.  These are optional parameters and code already has to be prepared to not receive them and to ignore not understood parameters.  If the change is made, the result would be that existing implementations wouldn't receive issuance and expiration times that they understand until they change their code.  That being said, the documentation for these parameters is already clear, so I don't think that much confusion is likely to arise if we change nothing.

I am very strongly against changing (3) because this is truly a gratuitous and fully breaking change.  There's only thing that authenticates to token endpoints - clients - and so adding "client_" to the name adds no semantic or disambiguating value.

                                                            -- Mike

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer
Sent: Wednesday, May 22, 2013 11:20 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration

Speaking as an implementor, I'm actually in favor of changing "expires_at" and "issued_at" to the values proposed below. It would require some minor code changes on my end, but the impact would be minimal, and I think that the new names are *much* more clear to new developers. I think it will save us a lot of questions and headaches going forward. I believe that changing it now will have minimal impact on any deployed and running code (there are no large-scale services that I am aware of), and it will make things clearer. So I vote for "B" for #1 and #2.

I believe "token_endpoint_auth_method" is sufficient as is, since the client is the only thing that authenticates to the token endpoint.


[[ Note: As an editor, I don't believe it's really in my power to make that change unless there's support in the working group for making it. I really want more feedback from people, with explanation if you can. ]]

 -- Justin

On 05/20/2013 11:09 AM, Justin Richer wrote:
Phil Hunt's review of the Dynamic Registration specification has raised a couple of issues that I felt were getting buried by the larger discussion (which I still strongly encourage others to jump in to). Namely, Phil has suggested a couple of syntax changes to the names of several parameters.


1) expires_at -> client_secret_expires_at
2) issued_at -> client_id_issued_at
3) token_endpoint_auth_method -> token_endpoint_client_auth_method


I'd like to get a feeling, especially from developers who have deployed this draft spec, what we ought to do for each of these:

 A) Keep the parameter names as-is
 B) Adopt the new names as above
 C) Adopt a new name that I will specify

In all cases, clarifying text will be added to the parameter *definitions* so that it's more clear to people reading the spec what each piece does. Speaking as the editor: "A" is the default as far as I'm concerned, since we shouldn't change syntax without very good reason to do so. That said, if it's going to be better for developers with the new parameter names, I am open to fixing them now.

Naming things is hard.

 -- Justin




_______________________________________________

OAuth mailing list

OAuth@ietf.org<mailto:OAuth@ietf.org>

https://www.ietf.org/mailman/listinfo/oauth