Re: Oauth blog post

Hannes Tschofenig <hannes.tschofenig@gmx.net> Thu, 02 August 2012 21:35 UTC

Return-Path: <hannes.tschofenig@gmx.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB4DA21F88E5 for <ietf@ietfa.amsl.com>; Thu, 2 Aug 2012 14:35:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 f2BjenCQtDy4 for <ietf@ietfa.amsl.com>; Thu, 2 Aug 2012 14:35:14 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id D7A8C21F85AD for <ietf@ietf.org>; Thu, 2 Aug 2012 14:35:13 -0700 (PDT)
Received: (qmail invoked by alias); 02 Aug 2012 21:35:11 -0000
Received: from dhcp-172b.meeting.ietf.org (EHLO dhcp-172b.meeting.ietf.org) [130.129.23.43] by mail.gmx.net (mp029) with SMTP; 02 Aug 2012 23:35:11 +0200
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX18FRLUv+qoFBJ4dBLoD038ppwq9YSNCNsvpRBF8yq yemwHDK6AjLN5T
Subject: Re: Oauth blog post
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
In-Reply-To: <CD5674C3CD99574EBA7432465FC13C1B22726A0BED@DC-US1MBEX4.global.avaya.com>
Date: Thu, 02 Aug 2012 14:35:08 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <CABC742E-0DD2-412D-B60E-879C30D01769@gmx.net>
References: <501531F7.5040404@gmail.com> <6.2.5.6.2.20120729073422.06d8fe10@resistor.net> <39B73AD9-4E8F-4E94-A538-69BE5D8C0E18@gmx.net> <6.2.5.6.2.20120730101231.047f2550@resistor.net>, <CAL0qLwYNRW6FSC4kMQkn81+4HgKdv591D43Z31rLAg3ArRsSZg@mail.gmail.com> <CD5674C3CD99574EBA7432465FC13C1B22726A0BED@DC-US1MBEX4.global.avaya.com>
To: "Worley, Dale R (Dale)" <dworley@avaya.com>
X-Mailer: Apple Mail (2.1084)
X-Y-GMX-Trusted: 0
Cc: SM <sm@resistor.net>, "ietf@ietf.org" <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Aug 2012 21:35:15 -0000

In the identity management case we are not necessarily talking about solutions that are "good" or "bad". The issue is that certain people care about one use case and other people care about other use cases.  I use the term "use case" in a generic sense to also include certain deployment assumptions (e.g., has to work with existing programming languages, deployment environments), or design themes (e.g., XML vs. JSON). 

So, for example, in the OAuth case there are people who care a lot about different Websites sharing data between each other (the photo sharing / photo printing use case). Again others think that the smart phone use case is more important. The solutions for these two cases are slightly different (because they can rely on different assumptions). 

Initially, people start with a single use case they care about. The work gets attention and other people start to use the protocol as well and notice that it does not meet their use cases. So, they add functionality. Over time the set of specification becomes more complex and a beginner does not see through the specification jungle anymore. Then, these newcomers start from scratch to fix all these "complex protocols". Typically, these persons like to reject any idea that was done in the past (such as learning from the experience the previous generation had made). The cycle starts from the beginning. We went through these cycles several times already in the identity management world. 

We had seen this with the transition from Kerberos to SAML, from SAML to OpenID, from OpenID to OAuth. 

At some point we should ask ourselves whether the problem that is being solved is multi-faceted and the resulting solution will just not be a 10 page document (unless it is incomplete). 

I believe that application developers shouldn't even worry about the details of the protocol suite. They should be using a library instead. We use libraries all the time and particularly with security protocols. Take TLS as an example. No application developer would come up with the idea to write their own TLS stack either. They let security professionals write those libraries. 


On Aug 2, 2012, at 1:58 PM, Worley, Dale R (Dale) wrote:

>> From: Murray S. Kucherawy [superuser@gmail.com]
>> 
>> I think it's impossible to determine with certainty whether someone
>> standing at the mic and asserting a position is doing so based on what
>> an employer is insisting on doing, or that person's opinion.
> 
> But it is possible, over a period of time, to get a good estimate of
> whether someone promotes technically poor solutions that are
> commercially advantageous for their employers.
> 
> Indeed, relative to our fundamental principle of openness, "All may
> speak; not all are listened to.", in order to be listened to, someone
> has to spend some time to establish a reputation for technical quality
> of their contributions, and not being a shill for poor ideas advanced
> by their employers.
> 
> Dale