IETF Logo Mail Archive

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

Michael Thomas <mike@mtcc.com> Thu, 17 November 2011 16:49 UTC

Return-Path: <mike@mtcc.com>
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 1B5E421F9886 for <oauth@ietfa.amsl.com>; Thu, 17 Nov 2011 08:49:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 uqU974VAATup for <oauth@ietfa.amsl.com>; Thu, 17 Nov 2011 08:49:08 -0800 (PST)
Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 60A9521F9885 for <oauth@ietf.org>; Thu, 17 Nov 2011 08:49:08 -0800 (PST)
Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id pAHGn2gB030640 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 17 Nov 2011 08:49:03 -0800
Message-ID: <4EC53AFE.5020506@mtcc.com>
Date: Thu, 17 Nov 2011 08:49:02 -0800
From: Michael Thomas <mike@mtcc.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0
MIME-Version: 1.0
To: Justin Richer <jricher@mitre.org>
References: <CALaySJJ+2au5rxEQmSSpXO42KmgCu=NhiLPBCx-3AH0hud=5CQ@mail.gmail.com> <1321543457.7567.137.camel@ground>
In-Reply-To: <1321543457.7567.137.camel@ground>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1519; t=1321548543; x=1322412543; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20<mike@mtcc.com> |Subject:=20Re=3A=20[OAUTH-WG]=20Mandatory-to-implement=20t oken=20type |Sender:=20 |To:=20Justin=20Richer=20<jricher@mitre.org> |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=K1sKWCikZGseKZqL3t6Z0IPNdEGljOuCn5L5LSoRato=; b=cy1HJYc1+ERzDxHa8l/ULFxoNE+zF4hEvA9XpmVWdJ8XWwfKeftX7KPwXL J4nU2ujgJGUu3TKFsWG8OMlumztEdpLtpOmUMUBer7gos2f//l/e8+ANPog4 SKbhFvO1IhGq5BI0cYl/l9jFlMahDI2CEk74Ixg9ab2M9ZJaWp7vQ=;
Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com
Cc: Barry Leiba <barryleiba@computer.org>, 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 16:49:09 -0000

On 11/17/2011 07:24 AM, Justin Richer wrote:
> 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.
>    

I think this is really the key problem. To date, there isn't a
unified library that clients and servers are using that could
force this issue: every server/site is rolling their own oauth
sdk, and they don't have much reason *now* to change that.
If/when something emerged as being the oauth equivalent of
openssl, then it would make sense to tighten requirements on
such a library to achieve better interoperability. It would also
coincide with actual real world _knowledge_ of what the
appropriate MUST-IMPLEMENT's are instead of guessing.
All a mandatory requirement will do now is alienate a lot
implementations who are otherwise striving to be compliant.

So my bottom line to Stephen: defer this to a later recycle of the
rfc.

Mike

v2.23.0 | Report a Bug | By Email