Re: [OAUTH-WG] Mandatory-to-implement token type

Justin Richer <jricher@mitre.org> Thu, 17 November 2011 15:24 UTC

Return-Path: <jricher@mitre.org>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC7F21F9A1B for <oauth@ietfa.amsl.com>; Thu, 17 Nov 2011 07:24:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.599
X-Spam-Level:
X-Spam-Status: No, score=-7.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4]
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 5yntKX4fXwWI for <oauth@ietfa.amsl.com>; Thu, 17 Nov 2011 07:24:35 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id F2E0021F9975 for <oauth@ietf.org>; Thu, 17 Nov 2011 07:24:34 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3081121B16E2; Thu, 17 Nov 2011 10:24:32 -0500 (EST)
Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 219F621B16E0; Thu, 17 Nov 2011 10:24:32 -0500 (EST)
Received: from [129.83.50.8] (129.83.31.51) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server id 14.1.339.1; Thu, 17 Nov 2011 10:24:31 -0500
Message-ID: <1321543457.7567.137.camel@ground>
From: Justin Richer <jricher@mitre.org>
To: Barry Leiba <barryleiba@computer.org>
Date: Thu, 17 Nov 2011 10:24:17 -0500
In-Reply-To: <CALaySJJ+2au5rxEQmSSpXO42KmgCu=NhiLPBCx-3AH0hud=5CQ@mail.gmail.com>
References: <CALaySJJ+2au5rxEQmSSpXO42KmgCu=NhiLPBCx-3AH0hud=5CQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.2.1-
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
Cc: oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Mandatory-to-implement token type
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
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, 17 Nov 2011 15:24:35 -0000

> 1. Should we specify some token type as mandatory to implement?  Why
> or why not (*briefly*)?

No, since I do not believe that the force of compliance with this one
point of the spec will be enough to persuade those who don't want to use
whatever the MTI token type ends up being to use it. Let's say that we
were to pick Bearer, but Example.com decides to only support MAC for
their API. Is it correct to say that Example.com is not really doing
OAuth2? I would argue no, since they're doing everything within spec to
issue tokens, and the tokens that they're issuing are well defined and
within spec as well. So then let's say, hypothetically, that in order
comply with the letter of the law, they implement a Bearer token as well
as MAC. But which type do they issue to clients? Clients have no way of
choosing or discovering which what kind of token comes back (yet). If
Bearer is MTI, how do you even use another token type?

Which brings us to MTI in clients, which makes even less sense. Let's
say that I'm writing a client to talk to Example.com, which hands back
MAC tokens. I want to comply with the spec, so I implement Bearer
support in my client, code paths which will never see the light of day. 

Then there's the argument that a generic library is what's really meant
by "client" here, and that those MUST follow the MTI guidelines. I also
find this to be ludicrous, since client libraries will implement
whatever servers support. A good client library will support *both* MAC
and Bearer together, along with whatever magical tokens that haven't
been dreamed up yet that are getting traction.

Ultimately, I think that our declaring something MTI is a position of
hubris that won't affect how people really use this thing.

 -- Justin