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

Justin Richer <jricher@mitre.org> Fri, 02 December 2011 20:08 UTC

Return-Path: <jricher@mitre.org>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id AB39A1F0C49 for <oauth@ietfa.amsl.com>; Fri, 2 Dec 2011 12:08:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.298
X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id fjhl57XSXeep for <oauth@ietfa.amsl.com>; Fri, 2 Dec 2011 12:08:26 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org []) by ietfa.amsl.com (Postfix) with ESMTP id 68FF11F0C5A for <oauth@ietf.org>; Fri, 2 Dec 2011 12:08:26 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain []) by localhost (Postfix) with SMTP id E11F821B024A for <oauth@ietf.org>; Fri, 2 Dec 2011 15:08:21 -0500 (EST)
Received: from imchub1.MITRE.ORG (imchub1.mitre.org []) by smtpksrv1.mitre.org (Postfix) with ESMTP id CAA4921B013B for <oauth@ietf.org>; Fri, 2 Dec 2011 15:08:21 -0500 (EST)
Received: from [] ( by imchub1.MITRE.ORG ( with Microsoft SMTP Server (TLS) id; Fri, 2 Dec 2011 15:08:21 -0500
Message-ID: <4ED93028.6030206@mitre.org>
Date: Fri, 02 Dec 2011 15:08:08 -0500
From: Justin Richer <jricher@mitre.org>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: "oauth@ietf.org" <oauth@ietf.org>
References: <4ED9300B.3000009@mitre.org>
In-Reply-To: <4ED9300B.3000009@mitre.org>
X-Forwarded-Message-Id: <4ED9300B.3000009@mitre.org>
Content-Type: multipart/alternative; boundary="------------090209000002000004060702"
Subject: [OAUTH-WG] Fwd: Re: 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: Fri, 02 Dec 2011 20:08:27 -0000

Forwarding my response to the list. (oops)

  -- Justin

-------- Original Message --------
Subject: 	Re: [OAUTH-WG] Mandatory-to-implement token type
Date: 	Fri, 02 Dec 2011 15:07:39 -0500
From: 	Justin Richer <jricher@mitre.org>
To: 	Stephen Farrell <stephen.farrell@cs.tcd.ie>

I still don't think that having an MTI token type actually buys us
anything, and what I *really* don't understand from this entire argument
is the weight that's being put behind "Compliance with OAuth2" and what
that means.

With no MTI token type, we can still have interop for people who claim
to be compliant with "OAuth2 + OAuth2 Bearer", or to borrow the example
below, compliant with "OAuth2 + AWESOME". Both of these are compliant
with "OAuth2" because they use OAuth2 to issue their tokens. *Those*
parts of the library should work just fine to interop between each
other. Since you're getting a JSON or fragment-encoded structure back as
the token, you should be able to toss that into some kind of generic
data structure and hand it to the token-handling part of your library,
which is going to need more smarts to know what to do with it.

A robust OAuth2 library, from server or client perspective, will likely
do both Bearer and Mac and let you pick which you want. A good discovery
system will aid that. An extended library will give you AWESOME tokens
as well. *All* of these should be called compliant with OAuth2, in my
opinion, and in this case it would be compliant with "OAuth2 + Bearer +
MAC + AWESOME". A great library indeed!

Making a MTI misses the point of the composability of the system, does
absolutely nothing for real-world interop due to reasons I've already
laid out in previous emails, will cause people to ignore the spec and be
in noncompliance for something they think is dumb, have unused and
untested code just to claim compliance that nobody cares about, and
ultimately makes us look a bit silly for insisting that one solution
will fit all use cases and that we can have any sense of real authority
in this over developers.

I'd like to point out that there's no MTI token-acquisition flow, which
is arguably more important for worldwide interop and just as untenable a
solution given the reality of the internet -- and I can also guarantee
that we will never see agreement over an MTI grant type / token flow due
to the simple fact that some instances will only do client credentials
for 2-legged and some will do code for 3-legged, and the two of those
probably don't want to talk to each other.

In summary, I suggest that "compliance with OAuth2" be defined in terms
of each of the separate composable documents and their combinations, and
that "compliance with OAuth2" not be limited to a particular combination
of any of them.

  -- Justin

On 12/01/2011 09:27 PM, Stephen Farrell wrote:
>  Hiya,
>  On 12/02/2011 02:14 AM, Michael D Adams wrote:
>>  On Thu, Dec 1, 2011 at 5:44 PM, Stephen Farrell
>>  <stephen.farrell@cs.tcd.ie>   wrote:
>>>  On 12/02/2011 01:38 AM, Michael D Adams wrote:
>>>>  So an MTI token type + no client preference is equivalent to there
>>>>  only existing one token type.
>>>  Maybe.
>>>  However, no MTI token type + no client preference = no interop.
>>>  So I don't get your argument. (When thinking of interop.)
>>  I think it's me that doesn't understand your argument.
>  That can be mutual:-)
>>  Suppose an authorization server implements OAuth2 and has some
>>  requirement that the MTI token type doesn't provide (as William Mills
>>  suggested), so the server implements token type AWESOME in addition to
>>  token type MTI.
>>  Whenever a token is requested, the authorization server issues one of
>>  type AWESOME.  Type MTI is never issued.
>>  Why bother implementing type MTI if it's never used?
>  That, I think, assumes that the requesting party only ever works with
>  the AWESOME token-type issuer. Seems a shame to me that whoever wrote
>  that code can't work with any other MTI token-type issuer as well, at
>  least.
>>  Additionally, the authorization server could not implement type MTI
>>  but claim it did.  There's no way for a third party to verify the
>>  claim since the authorization server never issues a token of type MTI.
>  Irrelevant. I could claim to be handsome. Would work equally
>  well.
>>  If tokens of type MTI are never used by this server, how does the MTI
>>  token type help interop?Is your argument that this server would say
>>  "No, we do not support OAuth2.  We do, however, support
>>  OAuth2+AWESOME."?  That semantic argument I understand, but I am
>>  ignorant as to how/if it fits into the RFC.
>  No, my argument is that there are many servers and many clients on
>  the Internet and having them all have a way to interop, if they
>  choose to do so, is a good thing in itself. Writing an RFC so that
>  its a random pick as to whether they do or don't interop is not IMO
>  a good thing.
>  S.
>  _______________________________________________
>  OAuth mailing list
>  OAuth@ietf.org
>  https://www.ietf.org/mailman/listinfo/oauth