Re: [oauth] OAUTH Charter Proposal

"Hannes Tschofenig" <Hannes.Tschofenig@gmx.net> Sat, 31 January 2009 21:37 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 C1F763A6857; Sat, 31 Jan 2009 13:37:09 -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 4DF9A3A6857 for <oauth@core3.amsl.com>; Sat, 31 Jan 2009 13:37:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.349
X-Spam-Level:
X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.250, 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 YeEUyz4X9wW9 for <oauth@core3.amsl.com>; Sat, 31 Jan 2009 13:37:07 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 0365D3A67E9 for <oauth@ietf.org>; Sat, 31 Jan 2009 13:37:06 -0800 (PST)
Received: (qmail invoked by alias); 31 Jan 2009 21:36:45 -0000
Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp001) with SMTP; 31 Jan 2009 22:36:45 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX19c0/Eq8BRci+PDVnPGl8vnDShVeJY8VpV0+vVOlT qsE3NZBrXKFL2W
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
To: 'Krishna Sankar' <ksankar@gte.net>
References: <C5A8C0A3.11CC5%eran@hueniverse.com> <4983D6C7.8070201@gte.net> <044801c98398$34fd6860$0201a8c0@nsnintra.net> <49849DFD.4020607@gte.net>
Date: Sat, 31 Jan 2009 23:37:27 +0200
Message-ID: <045601c983ec$1e919e30$0201a8c0@nsnintra.net>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
In-Reply-To: <49849DFD.4020607@gte.net>
Thread-Index: AcmD1RuIJO0h8Ed8Qd+/qfZDUf/3MAAFGRsg
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.61
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-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: oauth-bounces@ietf.org
Errors-To: oauth-bounces@ietf.org

Hi Krishna, 

Thanks for your quick response. 

>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.

A description on how OAUTH can (or should) be extended is certainly useful
(better explicit than implicit). This could, for example, be part of the
main specification. I have also seen separate documents that illustrate how
a protocol (or a set of protocols) can be extended. Example: Design
Guidelines for RADIUS
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-05.txt
This document has been written some time after the deployment happened and
provides a sort of best current practice on how to build RADIUS extensions.
I believe it is a bit early for these type of documents. 

So, my proposal would be to capture the most important extensibility aspects
within the main specification itself. Later, when some expertise can be
gained with OAUTH extensions one can start thinking about capturing the
design experience in a document. 

I guess we are doing fine with the security considerations as every IETF
document needs to contain a section describing them. 

In any case, if you already have some ideas for text (or already a text
proposal) for the OAUTH draft feel free to post something to the list (even
though it is not directly related to the charter discussion itself). 

>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

Explicitly stating extensibility in the charter sounds useful to me. 
I added it to the charter text. 
 
>
>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.

Ok.

Ciao
Hannes

>
>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