Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

Brian Campbell <bcampbell@pingidentity.com> Thu, 15 May 2014 12:38 UTC

Return-Path: <bcampbell@pingidentity.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 818591A0285 for <oauth@ietfa.amsl.com>; Thu, 15 May 2014 05:38:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.978
X-Spam-Level:
X-Spam-Status: No, score=-2.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8wiYCBqt8T7K for <oauth@ietfa.amsl.com>; Thu, 15 May 2014 05:37:56 -0700 (PDT)
Received: from na3sys009aog101.obsmtp.com (na3sys009aog101.obsmtp.com [74.125.149.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78AB11A04E8 for <oauth@ietf.org>; Thu, 15 May 2014 05:37:55 -0700 (PDT)
Received: from mail-ie0-f177.google.com ([209.85.223.177]) (using TLSv1) by na3sys009aob101.postini.com ([74.125.148.12]) with SMTP ID DSNKU3S1HGl/28CtwJ30X5cYtBIzUOTDsgR7@postini.com; Thu, 15 May 2014 05:37:48 PDT
Received: by mail-ie0-f177.google.com with SMTP id rp18so922477iec.22 for <oauth@ietf.org>; Thu, 15 May 2014 05:37:48 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=XSAjy1cdZc9ZjxaRMVONpQe55/5+0jPupF2lV5La6Ik=; b=IPEzsBY+9fCWqGR+ksmb0seI9gd71amA99h3Iq/WxKyLnfeZQ6ZGQO8k4Bh4Qsd6Xb a9yhMWhICwtmmQ9ajHtHEutwi+UY0IXOJSHP0b12A8M4OmAfIXtjG+bRAZUpK2KA8lbJ 1gDMi60FGlQtQeZfnnClmL1Oe0xwYgT+qPq6iHg58ix54nSvI8dh3IDckBpzjVfHLRpi 26BLVxj31ErdGOoHgRXwzOgUjr8N6jHtUYYgQHQfB3l4n1mKI2giWg8XvhjW7mS7OR9p 6gunUROp/M/bgOuxomCfFXaZ9VD3s4mrGYXGqhp9cPSKzufqPi2IQvbVmV4gglcri5Kz RbHg==
X-Gm-Message-State: ALoCoQn8oTamwdJpa0aBEuHnwI/7V6WUrYQFnDHjlYoe0xaiDb9WmjG0TQGy3m7r53cTU0mV3tTHRMI//nzCroaVjPRb/Mu4KBOa25fG40IgD8K89k6GHldF9+mlwJwK7dUpHnmff6V+
X-Received: by 10.50.4.70 with SMTP id i6mr74498986igi.40.1400157468113; Thu, 15 May 2014 05:37:48 -0700 (PDT)
X-Received: by 10.50.4.70 with SMTP id i6mr74498965igi.40.1400157467914; Thu, 15 May 2014 05:37:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.240.201 with HTTP; Thu, 15 May 2014 05:37:17 -0700 (PDT)
In-Reply-To: <53740C51.1080009@oracle.com>
References: <536BF140.5070106@gmx.net> <CA+k3eCQN5TGSpQxEbO0n83+8JDVJrTHziVmkjzLUyXtgMQPG1A@mail.gmail.com> <29B83890-91B4-4682-B82F-2B11913CCE6A@oracle.com> <a004992672a54c32a2237112dab67050@BLUPR03MB309.namprd03.prod.outlook.com> <5373A8FA.9030601@redhat.com> <53740C51.1080009@oracle.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Thu, 15 May 2014 06:37:17 -0600
Message-ID: <CA+k3eCSXo_r9NK34iEVcHHoDrUt1Ad8F-X7e60E1EmyrvYfTdQ@mail.gmail.com>
To: Prateek Mishra <prateek.mishra@oracle.com>
Content-Type: multipart/alternative; boundary="001a11c32a88814fd504f96f90f8"
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/RA71Uutj2zccc1ErT8BLWYvwWWI
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Thu, 15 May 2014 12:38:04 -0000

"I had personally requested the OIDC community about six months ago to
describe some minimal subset which we could all reasonably implement. I was
told that  the specification was "locked down" and fully debugged and so
on, so no changes could be made. Imagine my surprise to find that in the
final drafts there was a whole new flow - the hybrid flow - that had been
added at the last minute. I had never heard of the hybrid flow in the OAuth
context - have you? So now you have an even larger specification!"

Prateek,

The hybrid flow wasn't new at all. It was an editorial change that
attempted to better explain multiple response types like code+token, which
is something allowed for by OAuth
http://tools.ietf.org/html/rfc6749#section-8.4 and used in Connect since
the very beginning (at least as long as I'd been involved, which is 2+
years).  Nothing was added to the actual protocol.





On Wed, May 14, 2014 at 6:37 PM, Prateek Mishra
<prateek.mishra@oracle.com>wrote:

>  Anil,
>
> the challenge is that OIDC is a rather large set of specifications, and to
> my knowledge even the core specification has NOT found
> a complete implementation at any large IdP. I am not talking here about
> boutique toolkits or startups, I am talking about the folks
> who have 100s of millions of users. And, BTW, implementing a few
> arbitrarily selected features from OIDC is not the same as implementing
> OIDC.
>
> As we all know, the core problem is that of adding an authenticator token
> to OAuth flows, which is a rather modest extension to OAuth.
>
> I had personally requested the OIDC community about six months ago to
> describe some minimal subset which we could all reasonably implement. I was
> told that  the specification was "locked down" and fully debugged and so
> on, so no changes could be made. Imagine my surprise to find that in the
> final drafts there was a whole new flow - the hybrid flow - that had been
> added at the last minute. I had never heard of the hybrid flow in the OAuth
> context - have you? So now you have an even larger specification!
>
> The value of draft-hunt-oauth-v2-user-a4c-01 is that it describes
> precisely a minimal extension to OAuth flows to support an authenticator
> token.  In my experience, this is the subset that most customers and
> implementors are looking for.
>
>
> - prateek
>
>