Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-introspection-09: (with COMMENT)

Barry Leiba <barryleiba@computer.org> Tue, 09 June 2015 16:57 UTC

Return-Path: <barryleiba@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0FCC1A9133; Tue, 9 Jun 2015 09:57:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOCLse0iStzZ; Tue, 9 Jun 2015 09:57:18 -0700 (PDT)
Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E291F1A0BE8; Tue, 9 Jun 2015 09:57:17 -0700 (PDT)
Received: by igblz2 with SMTP id lz2so15997831igb.1; Tue, 09 Jun 2015 09:57:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=PuRQv7MulisP2CX/HNo5/NhP9ipLgGWZlCnhXAX5UNo=; b=abK9ffxhPjKIWsKjhi4CWWHU6Axs/3m5gI0nyXIM2J4uShNpWtpZ1KzOdD2NTbYdxP g5EyNzIGU9gPMXdhrjwD2OfdnMwZVuKqvu6959ejW/W7unAlf8ZvcvPfZCiMIOcOTE0g sUy0B/0nKlFy6t7j9X7oprIm6RjeEX562CRlil5WSpXcr0FVfHnJJcpD0IXCHZYF9QEo 6Ii3SKtZaslLY2QzN6ZNCjH6tK/cH7G8Zbp+zW6J3q8nelQMZYVq3MCtw/hRNplmfPLg fXCaVEsrLM+2tidddya9cukDRF+A9AzIYOapGBdKX5bK/yOsKPo2GbSKmSIT5XPxvWB+ +kGA==
MIME-Version: 1.0
X-Received: by 10.43.34.205 with SMTP id st13mr30509908icb.4.1433869037465; Tue, 09 Jun 2015 09:57:17 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.107.16.222 with HTTP; Tue, 9 Jun 2015 09:57:17 -0700 (PDT)
In-Reply-To: <A62D61C9-C6A0-4988-B7DC-73B39F69FCD5@mit.edu>
References: <20150608123617.6617.42932.idtracker@ietfa.amsl.com> <A62D61C9-C6A0-4988-B7DC-73B39F69FCD5@mit.edu>
Date: Tue, 9 Jun 2015 17:57:17 +0100
X-Google-Sender-Auth: D-xzMbp_FwqrTTTcSKbSHjqn8T8
Message-ID: <CALaySJ+XpvcnStdK3JC_3j9ztQVaRVc0OK=hTOQB2eO06C_XZg@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: Justin Richer <jricher@mit.edu>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/EpzbfyvV5KD4HDtsV6FlXS8zQA0>
Cc: draft-ietf-oauth-introspection@ietf.org, draft-ietf-oauth-introspection.ad@ietf.org, oauth-chairs@ietf.org, draft-ietf-oauth-introspection.shepherd@ietf.org, The IESG <iesg@ietf.org>, "<oauth@ietf.org>" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-introspection-09: (with COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 09 Jun 2015 16:57:19 -0000

Hi, Justin.  Thanks for the response and discussion.

>> -- Section 2 --
>>
>>    The introspection endpoint MUST be protected by a transport-layer
>>    security mechanism as described in Section 4.
>>
>> I know what it means for a communication path to be protected by TLS, but
>> I don't know what it means for an endpoint to be.  Can you explain that?
>
> The gist is simple: It must be served over HTTPS, not HTTP.

Right; that's protecting the communication path.  So I suggest this
(and it's a minor point; I'm OK with no further discussion, whether
you agree with the change or not):

NEW
   The introspection communication path MUST be protected by a
   transport-layer security mechanism as described in Section 4.
END

>> -- Section 2.1 --
>> The server MUST support POST, and MAY support GET.  What's the value in
>> that?  I don't see any way for a client (I mean HTTP client, not Oauth
>> client, here) to know, so all clients will have to send POST to be sure
>> it will work.  Are you really expecting to have clients that want to ask
>> this, but that can't send POST?  Given that you call out privacy concerns
>> with GET, I don't see why it's there at all.
>
> GET is a deployment optimization that some servers will offer, and the
> OAuth client will tell the HTTP client which verb to use. The OAuth client
> might know through configuration (assuming a tighter coupling than
> defined by the interoperable protocol)

Two things:

1. Why is GET an optimization?  It has privacy disadvantages, and I
don't see any advantages.

2. This "tight coupling" thing is something that I think weakens the
interoperability of the OAuth protocol in general, and I've never
liked it.  In this case, in particular, I don't see any advantage to
it, and I don't understand why it's useful to have an option that only
works if you have inside knowledge, for no benefit.

Why is it ever good to have clients that only work with certain
servers, when it's just as easy to make sure that all clients work
with all servers?

Barry