Re: [OAUTH-WG] What are the OAuth design principles?

Anthony Nadalin <tonynad@microsoft.com> Mon, 22 March 2010 23:58 UTC

Return-Path: <tonynad@microsoft.com>
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 AF5EB3A695C for <oauth@core3.amsl.com>; Mon, 22 Mar 2010 16:58:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.631
X-Spam-Level:
X-Spam-Status: No, score=-9.631 tagged_above=-999 required=5 tests=[AWL=-0.968, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5]
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 G4vCD8WAo50N for <oauth@core3.amsl.com>; Mon, 22 Mar 2010 16:58:12 -0700 (PDT)
Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 5B41D3A690C for <oauth@ietf.org>; Mon, 22 Mar 2010 16:58:12 -0700 (PDT)
Received: from TK5EX14CASC131.redmond.corp.microsoft.com (157.54.52.38) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 22 Mar 2010 16:58:30 -0700
Received: from TK5EX14MBXC103.redmond.corp.microsoft.com ([169.254.3.164]) by TK5EX14CASC131.redmond.corp.microsoft.com ([157.54.52.38]) with mapi; Mon, 22 Mar 2010 16:58:30 -0700
From: Anthony Nadalin <tonynad@microsoft.com>
To: Eve Maler <eve@xmlgrrl.com>, OAuth WG <oauth@ietf.org>
Thread-Topic: [OAUTH-WG] What are the OAuth design principles?
Thread-Index: AQHKyhOstpe8mjHGhk2MVj3aCCUO2pH+oMPQ
Date: Mon, 22 Mar 2010 23:58:27 +0000
Message-ID: <A08279DC79B11C48AD587060CD93977125ED9942@TK5EX14MBXC103.redmond.corp.microsoft.com>
References: <0E4475A4-8014-419B-A20E-15DDF04300FD@xmlgrrl.com>
In-Reply-To: <0E4475A4-8014-419B-A20E-15DDF04300FD@xmlgrrl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] What are the OAuth design principles?
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: Mon, 22 Mar 2010 23:58:13 -0000

My design principles would be the following as we already have protocols that solve many complex usecases  

1. Simple programming model
3. Reduce deployment barriers 
2. Limited or no client side code (works with a browser)
3. Replace username/password scenarios 
4. No client side key distribution nightmares    

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Eve Maler
Sent: Monday, March 22, 2010 4:01 PM
To: OAuth WG
Subject: [OAUTH-WG] What are the OAuth design principles?

Since the discussion in the "OAuth after-party" seemed to warrant bringing it up, I mentioned the UMA design principles/requirements document.  You can find it here:

http://kantarainitiative.org/confluence/display/uma/UMA+Requirements

The discussion is around "Why can't Kerberos just be used for your use cases?"  The UMA principles might be able to inform how the OAuth WG makes its case for why Kerberos doesn't suffice.  (If we discover it does, hey, our work here is done. :-)

	Eve

Eve Maler
eve@xmlgrrl.com
http://www.xmlgrrl.com/blog

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