Re: [kitten] Barry Leiba's No Objection on draft-ietf-kitten-sasl-oauth-22: (with COMMENT)

Bill Mills <> Thu, 28 May 2015 18:50 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A9D251A1AE3 for <>; Thu, 28 May 2015 11:50:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.724
X-Spam-Status: No, score=0.724 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LW9tfS9qLRKV for <>; Thu, 28 May 2015 11:50:28 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9FC291A1AFB for <>; Thu, 28 May 2015 11:50:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s2048; t=1432839027; bh=srSPz3z76ieaNiwk0+5Bu8bR8q5kCqpqDkyYFIUVM2A=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=VrsCVllBDTbPHPUeAHVAYSgaX1JOlQVFNWAtjfxKMev4sOxjnN0rD50Xl2jfZkPlv5Nt5nI/9vo0xvmb1+R0eyf6KUKOVwFy6oZ1uAPiSBMyzpoT/Rx5Ar8TkRCXNx9ux7agHhruWXEmR2606FsU1Jr2uqZgvz8EPhXZENXCcHbzsw5F+rMeF/hvklISq44o5km4abzQ+1qAua81pEWWRq+2SEMlhPY0dr4GvDeLrro8S59UnTOCacPdvNmolnBapLA58YP10LDiAdkSxueCRCQ8cg7T7phlOo0wawByhjTsCozNFpa+pCpqbcqaiZUNioxXwq52kXQtTwv9b0/k8w==
Received: from [] by with NNFMP; 28 May 2015 18:50:27 -0000
Received: from [] by with NNFMP; 28 May 2015 18:47:38 -0000
Received: from [] by with NNFMP; 28 May 2015 18:47:37 -0000
Received: from [] by with NNFMP; 28 May 2015 18:47:37 -0000
Received: from [] by with NNFMP; 28 May 2015 18:47:37 -0000
X-Yahoo-Newman-Property: ymail-4
X-YMail-OSG: Ai2f1iUVM1mo_WJkeoLgBvhsZTZ_ISECfwcHfZp0syiYNZuDlNidkgGOyXlx1Vs 6qi7EWSl.D8FRApOJX3YA6xBXezb7v2sb3kypkbPhTJmeDFFdldodNEEjtWID2NlgRE7n231dywf 5oPzF4LyQWcRGg1btpily0kpC__Rt26_FHmT5n43J2.v2s2.WAHqq8Z6uGerL30YSa80VlcEPxlR YeBuUtyXLrn7Pu_Tp14bJogKpZFsZsyujX_77Jk1qJqiPFosHlnwibZ6aJE4nNmkBSIwgVp0i3NU RQ45AH951LTNm7SAA9n9E5DaJxivllTmSW7ngYbLT9o08lfE2z2ysU6ZEPZMUM2nYLpdJXZY_BH4 R_Kjbw5zYDpgKFud9pJoVxWcUQEr8jEwQ1tFimMVgpWPaNbYIkXykK4q_iepeLD6z3kb5QxIM6jf XziQpLeFRPVoRklO_N8JYHi_8287JnCnOMtHZlT4ZrukjkU3CAfGLlcZG_u5qsduu2Qy_JS0a.GZ bGETeYy1qaRsUhJTrKf7Hrko-
Received: by; Thu, 28 May 2015 18:47:37 +0000
Date: Thu, 28 May 2015 18:47:33 +0000 (UTC)
From: Bill Mills <>
To: Barry Leiba <>
Message-ID: <>
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_760410_1042265162.1432838853598"
Archived-At: <>
Cc: "" <>, "" <>, "" <>, The IESG <>, "" <>, "" <>
Subject: Re: [kitten] Barry Leiba's No Objection on draft-ietf-kitten-sasl-oauth-22: (with COMMENT)
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Bill Mills <>
List-Id: Common Authentication Technologies - Next Generation <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 28 May 2015 18:50:30 -0000

OK.  Modified the scope language to say 
"If a scope is specified then a single scope is preferred. At the time  this document was written there were several implementations that do  not properly support space separated lists of scopes, so the use of  a space separated list of scopes is NOT RECOMMENDED." 

     On Thursday, May 28, 2015 11:27 AM, Barry Leiba <> wrote:

 Bill and Ben, thanks for the reply.  Mixing my replies to the two of
you here, since it's mostly the same.  And I've eliminated anything
that there's complete agreement on.

>> -- Section 3.2.2 --
>>      scope (OPTIONAL):  An OAuth scope which is valid to access the
>>          service.  This may be omitted which implies that unscoped
>>          tokens are required.  If a scope is specified then a single
>>          scope is preferred, use of a space separated list of scopes is
>>          NOT RECOMMENDED.
>> Why is it "NOT RECOMMENDED"?  What interoperability or security issue is
>> in play here that makes this "SHOULD NOT"?
> This isn't my preference for language, but some folks have concerns about
> using multiple scopes and how that all gets resolved and whether the client
> needs to understand scope strings to determine if they already have the
> scope they need.

Ben's response:
> I am a little hazy on this, but I seem to recall that some deployed
> software assumes that only a single scope will be used, so this is for
> interoperability.  (Bill, please jump in if I'm confused.)

OK, both wrinkles are fine.  If you don't mind, please put a sentence
or so of explanation, then.  Maybe making it something like "is NOT
RECOMMENDED because multiple scopes are problematic for currently
deployed software," or whatever makes sense to say here.

>>          The server MAY return different URLs for users in
>>          different domains and the client SHOULD NOT cache a single
>>          returned value and assume it applies for all users/domains that
>>          the server suports.  The returned discovery document SHOULD
>>          have all data elements required by the OpenID Connect Discovery
>>          specification populated.
>> Similar questions for the SHOULD NOT and SHOULD here.  In this case, I
>> don't understand why they aren't "MUST NOT" and "MUST": for the first, I
>> don't understand how a client can interoperate with a server if it violates
>> this, and for the second, if they data elements are "required", why isn't
>> including them a "MUST"?
> There are implementations now that don't support Dynamic Client Reg. and
> requiring it would make no sense for them.

Ben's response:
> This section was one of the repeated areas of contention over the last
> calls, so I am somewhat reluctant to bring it back to the WG for
> discussion.  I think there would be somewhat more support for SHOULD NOT
> --> MUST NOT; the SHOULD for discovery is, IIRC, something of a
> compromise, since some parties did not want to bring in a hard dependency
> on OpenID Connect's choices.  The only reason I can come up for the SHOULD
> NOT, off the top of my head, is if some vendor distributed a mail client
> that was only ever going to talk to that same vendor's server.

Given that it's been discussed and decided, you guys should do the
right thing, noting that my comment is non-blocking.  I'll just add my
further comment that I'm not a fan of using "SHOULD" (or its negative)
as a sort of compromise.  I very much prefer specifying the protocol
the way we think it should be specified, and accepting that not all
implementations will meet every aspect of the spec.

For Ben's explanation (at the end), for example, I think we should not
aim at those sorts of implementations, but at the normal,
open-Internet, multi-vendor scenario, which is what the protocol is
meant for.  And, of course, if a vendor wants to tailor their
implementation to a closed scenario, they're always free to do so.

But, again: resolve this however you think is right to make the
protocol right and to represent the consensus of the working group.
No need to further explain to me.

>> (Nit: The "if available" at the end of the paragraph is unnecessary; if
>> one is not available, it certainly can't be used.)
> We were leaving the door open for other discovery mechanisms so that this
> isn't MTI if there are other options.

Ben's response:
> That's true, but I like the flow of the sentence with the extra
> redundancy better than without it.

Cool.  Let it remain as written.