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

[Barry Leiba <[e-mail]>]

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.

Barry