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

William Mills <> Thu, 01 December 2011 23:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9332A11E80CC for <>; Thu, 1 Dec 2011 15:37:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.357
X-Spam-Status: No, score=-17.357 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5eL7vqaFr1BY for <>; Thu, 1 Dec 2011 15:37:09 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id 8297211E80B6 for <>; Thu, 1 Dec 2011 15:37:09 -0800 (PST)
Received: from [] by with NNFMP; 01 Dec 2011 23:37:04 -0000
Received: from [] by with NNFMP; 01 Dec 2011 23:37:04 -0000
Received: from [] by with NNFMP; 01 Dec 2011 23:37:04 -0000
X-Yahoo-Newman-Property: ymail-3
Received: (qmail 25779 invoked by uid 60001); 1 Dec 2011 23:37:04 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=ginc1024; t=1322782624; bh=2SacPa8HtiriRqf+aw0iuwZOh3TaDdxcyNpDDAeDgyg=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=KoTwX2I80rykurRTym1AUu17Yb3O2ZDUlISLc5MPjFKYCvacK3DkDjK+GT7hoYuQhZVE/VhUln4FMyGbHvs16uNleZ8e6FNqSgQP+6QK7iXCBm0Wlv2TL/P5c9+bjMYek/xUCQ+X5z7mRIS5Zd6+d7ulCliyltu9eOL0Emspg8g=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024;; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=VjOUjjZFjqS2NbDy56BUfOzLSUggI8L1gH7zvlqTz+c+NVqZFF8a+R2DYikoYbO8Nop7VT2XpY092GSkrul9Uc3DISCkVzMMpjsaNlcXXvM+hwpY8udVg422Eh6vqeYaxzAgme0HhmBxFuuibwFKd6a47Fy2xxyUA+zTWy0drjk=;
X-YMail-OSG: TnCrXaYVM1kDSK.u1Wh8Pj0s99rJa4.vbLyXb_o3JKTaVn5 dL7fU20A5jHndsSbJKxDQljT_dhhU5Sxu.SDxkyqZYtivvAS04k3azIGcvVx iBUM9.xGUaei11x9sWYTZ6g8tv5SQsdzQLtzgVWT8XtVbnVfwEkc8XaRxiRR o1Z5FKKCBp5y5VHMSchGxkPIAEc6lkhQHM6NyZ6JpkKD1H1.t_DA99IpyoIz hWWUnMIWwugOfX3oIXuEm2es7Tm3SS.pq2y5S.pyyH3PIMrN91PReoIbI01T tLriuB9339xfADWCG3Mtb_UtTPANTa4CyIGU0FOsTTjTM2KyJSTtChXALsCN MwEXnPtvhAw9cipdV0HXjZsqRjt9wTIIqicw_SDmy_J2GtdGHlK3yX_wAUsf Tw6QNbAnOV.zM5_E59ivz55kI2joiBuJnPDgnvp7UtQ--
Received: from [] by via HTTP; Thu, 01 Dec 2011 15:37:04 PST
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/
References: <> <>
Message-ID: <>
Date: Thu, 01 Dec 2011 15:37:04 -0800
From: William Mills <>
To: Stephen Farrell <>, Barry Leiba <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="767760015-2036876281-1322782624=:25300"
Cc: oauth WG <>
Subject: Re: [OAUTH-WG] Mandatory-to-implement token type
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills <>
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 01 Dec 2011 23:37:10 -0000

Re: "So, pick one (my strong personal preference) or establish and
document why you're not picking one seem to me to be the choices

We don't have discovery done (enough) yet to lean on it in the core spec, but if we did I'd be in favor of something that says that you must implement either an MTI token OR a discovery mechanism that advertises at least one token.  Would that be workable?  

We could bang on the discovery stuff in pretty short order I think if we needed to.


 From: Stephen Farrell <>
To: Barry Leiba <> 
Cc: oauth WG <> 
Sent: Thursday, December 1, 2011 1:25 PM
Subject: Re: [OAUTH-WG] Mandatory-to-implement token type

Barry, all,

First, apologies for being so slow responding, various
travels got in the way. I hope we can quickly resolve this now.

Bit of process first: at the meeting we discussed this and at the
end of that discussion, there were quite a few more folks for the
"pick one" position. People who favour that outcome and really
care about that need to speak up on the list, since the list
consensus trumps the sense of the room in the chairs' evaluation
of the WG consensus.

Second, at the meeting I said that I'd like to see either MAC or
bearer picked as MTI, and if not, that I want the draft to say
why its ok to have no MTI token type. So the WG either need to
pick one, or else explicitly and convincingly justify not
picking one. That's the "firm" AD position to which Barry
referred. (I didn't properly call out the "if not" part of
that in my AD review, sorry.)

My own argument for picking one is simple: if every relevant
piece of code has to know how to handle one then it becomes
easier to get interop. If everyone decides for themselves
then interop is less likely since there are currently two
choices and may be more in future.

I do realise that the background here and current practice
is that code tends to be written that is specific to a
resource server (or however that's best phrased) but that's
maybe where the IETF differs from the community that produced
OAuth - here we want two independent implementers who've
never talked to produce code that interops even so.

I also realise that that's not the full story for getting
interop with OAuth and that more is needed. However, this
aspect is otherwise fully specified and so I don't buy the
argument that this isn't worth doing just because we don't
have the full registration story etc. figured out. If we don't
sort this out now, then later specs will have to update
this one in this respect. possibly making existing code
"non-compliant" in some sense, so just going ahead and doing
it right now is better.

So, pick one (my strong personal preference) or establish and
document why you're not picking one seem to me to be the choices


On 11/17/2011 08:28 AM, Barry Leiba wrote:
> Stephen, as AD, brought up the question of mandatory-to-implement
> token types, in the IETF 82 meeting.  There was some extended
> discussion on the point:
> - Stephen is firm in his belief that it's necessary for
> interoperability.  He notes that mandatory to *implement* is not the
> same as mandatory to *use*.
> - Several participants believe that without a mechanism for requesting
> or negotiating a token type, there is no value in having any type be
> mandatory to implement.
> Stephen is happy to continue the discussion on the list, and make his
> point clear.  In any case, there was clear consensus in the room that
> we *should* specify a mandatory-to-implement type, and that that type
> be bearer tokens.  This would be specified in the base document, and
> would make a normative reference from the base doc to the bearer token
> doc.
> We need to confirm that consensus on the mailing list, so this starts
> the discussion.  Let's work on resolving this over the next week or
> so, and moving forward:
> 1. Should we specify some token type as mandatory to implement?  Why
> or why not (*briefly*)?
> 2. If we do specify one, which token type should it be?
> Barry, as chair
> _______________________________________________
> OAuth mailing list
OAuth mailing list