Re: [oauth] OAUTH Charter Proposal

Krishna Sankar <ksankar@gte.net> Sat, 31 January 2009 18:53 UTC

Return-Path: <oauth-bounces@ietf.org>
X-Original-To: oauth-archive@ietf.org
Delivered-To: ietfarch-oauth-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52FA33A69D0; Sat, 31 Jan 2009 10:53:18 -0800 (PST)
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 2E4EC28C13C for <oauth@core3.amsl.com>; Sat, 31 Jan 2009 10:53:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 EIhY7CD6IzTu for <oauth@core3.amsl.com>; Sat, 31 Jan 2009 10:53:16 -0800 (PST)
Received: from vms173009pub.verizon.net (vms173009pub.verizon.net [206.46.173.9]) by core3.amsl.com (Postfix) with ESMTP id 48FA83A69D0 for <oauth@ietf.org>; Sat, 31 Jan 2009 10:53:16 -0800 (PST)
Received: from [192.168.1.66] ([71.146.5.160]) by vms173009.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KEC00JQLMVTIPH5@vms173009.mailsrvcs.net> for oauth@ietf.org; Sat, 31 Jan 2009 12:47:54 -0600 (CST)
Message-id: <49849DFD.4020607@gte.net>
Date: Sat, 31 Jan 2009 10:52:45 -0800
From: Krishna Sankar <ksankar@gte.net>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-version: 1.0
To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
References: <C5A8C0A3.11CC5%eran@hueniverse.com> <4983D6C7.8070201@gte.net> <044801c98398$34fd6860$0201a8c0@nsnintra.net>
In-reply-to: <044801c98398$34fd6860$0201a8c0@nsnintra.net>
Cc: oauth@ietf.org
Subject: Re: [oauth] OAUTH Charter Proposal
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Oauth bof discussion <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/pipermail/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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: oauth-bounces@ietf.org
Errors-To: oauth-bounces@ietf.org

Three vectors:

a)   While we cannot legislate extensibility, an extensibility guideline 
document need to be part of the deliverables. When the main OAuth 
discussions occur, there will be things we will say "this is not core 
but belongs to extensions" or we might make certain assumptions that we 
need to explicitly state or we might have certain insights. This 
document can systemically capture all these artifacts. We also might 
need to add security considerations as well as interoperability and 
conformance for extensions.

b) As a part of the charter we should add :

* Promote interoperability
* Provide guidelines for extensibility

The group should think about extensibility & document the results of the 
deliberations

c)   While I like an extensibility framework, it might prove to be too 
much and might not be practical. So am happy at the level of guidelines, 
insights and suggestions.

Cheers
<k/>
Hannes Tschofenig wrote:
>  >Should we mention anything about extensions or any 
>   
>> extensibility framework ?
>>
>> Cheers
>> <k/>
>>     
>
> What specifically do you have in mind? 
> A document that describes an extensibility framework?
> Highlighting in the charter what extension points could/should be used?
>
> Ciao
> Hannes
>
>
>   

_______________________________________________
oauth mailing list
oauth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth