Re: [OAUTH-WG] Extensibility for OAuth?

Thomas Hardjono <hardjono@MIT.EDU> Wed, 23 June 2010 18:26 UTC

Return-Path: <hardjono@mit.edu>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC0D63A6AF4 for <oauth@core3.amsl.com>; Wed, 23 Jun 2010 11:26:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.579
X-Spam-Level:
X-Spam-Status: No, score=-0.579 tagged_above=-999 required=5 tests=[AWL=-0.580, BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZcDktA7qWmN for <oauth@core3.amsl.com>; Wed, 23 Jun 2010 11:26:54 -0700 (PDT)
Received: from dmz-mailsec-scanner-5.mit.edu (DMZ-MAILSEC-SCANNER-5.MIT.EDU [18.7.68.34]) by core3.amsl.com (Postfix) with ESMTP id CE2E43A6AE7 for <oauth@ietf.org>; Wed, 23 Jun 2010 11:26:53 -0700 (PDT)
X-AuditID: 12074422-b7b3aae000000a51-ba-4c2251f56eb4
Received: from mailhub-auth-1.mit.edu (MAILHUB-AUTH-1.MIT.EDU [18.9.21.35]) by dmz-mailsec-scanner-5.mit.edu (Symantec Brightmail Gateway) with SMTP id F6.07.02641.5F1522C4; Wed, 23 Jun 2010 14:27:01 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-EXCHANGE-1.MIT.EDU [18.9.28.15]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id o5NIR0Vb020811; Wed, 23 Jun 2010 14:27:00 -0400
Received: from oc11exedge2.exchange.mit.edu (OC11EXEDGE2.EXCHANGE.MIT.EDU [18.9.3.18]) ) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id o5NIQwpn017095; Wed, 23 Jun 2010 14:26:59 -0400
Received: from w92exhub10.exchange.mit.edu (18.7.73.18) by oc11exedge2.exchange.mit.edu (18.9.3.18) with Microsoft SMTP Server (TLS) id 8.1.393.1; Wed, 23 Jun 2010 14:26:10 -0400
Received: from EXPO10.exchange.mit.edu ([18.9.4.15]) by w92exhub10.exchange.mit.edu ([18.7.73.18]) with mapi; Wed, 23 Jun 2010 14:26:58 -0400
From: Thomas Hardjono <hardjono@MIT.EDU>
To: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>, OAuth WG <oauth@ietf.org>
Date: Wed, 23 Jun 2010 14:26:54 -0400
Thread-Topic: Extensibility for OAuth?
Thread-Index: AcsSmmOz8+Jt3DWXRJyOV1i4UkJelAAZPRCA
Message-ID: <DADD7EAD88AB484D8CCC328D40214CCD017A07BE31@EXPO10.exchange.mit.edu>
References: <3D3C75174CB95F42AD6BCC56E5555B4502BE07CC@FIESEXC015.nsn-intra.net>
In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4502BE07CC@FIESEXC015.nsn-intra.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_005F_01CB12E0.21309F40"
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [OAUTH-WG] Extensibility for OAuth?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 23 Jun 2010 18:26:55 -0000

Thanks Hannes. Great list of to-do items for the WG :)

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Tschofenig, Hannes (NSN - FI/Espoo)
> Sent: Wednesday, June 23, 2010 2:08 AM
>
> This is probably the most important item were people will want to 
> write
> extensions for. Currently, we have the following onces in the 
> document:
>   1) Web Server
>   2) User Agent
>   3) Native Application
>   4) Autonomous
>   Note that the actual profile identifiers aren't clearly listed in 
> the
> document at the moment (or are inconsistent, such as "user_agent" and
> "user-agent" for the user agent profile).

Is the plan to have a separate document for each profile?  I'm assuming 
that we are all waiting for the draft-oath-v2 to stabilize (ps. it's 
gone from version 05 to 08 in a matter of 2-3 weeks, and now going to 
09). We need to lock-down, I think. Need to distinguish between 
major/significant changes to minor/typo fixes.


> An open question might be whether there is a possibility for an
> extension (other than a new profile) to define an optional parameter
> that may get used with an existing profile. Note that at the moment
> there is no registry for parameters.

It depends on what meaning of "profile" and "extension". If the optional 
parameter is used in one of the profiles (use-cases) only, then it 
should not be place into the core draft-oauth-v2. If the optional 
parameter ends-up being used in all the profiles (use-cases), then add 
it to the core. I think this is where you draw the line (otherwise all 
sorts of weird and wonderful parameters ends-up in the core draft).

/thomas/