Re: [Unbearable] WGLC 3 on core documents
Brian Campbell <bcampbell@pingidentity.com> Thu, 02 March 2017 13:45 UTC
Return-Path: <bcampbell@pingidentity.com>
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 647B512953C for <unbearable@ietfa.amsl.com>; Thu, 2 Mar 2017 05:45:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
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 cByxzzT1G-eC for <unbearable@ietfa.amsl.com>; Thu, 2 Mar 2017 05:45:00 -0800 (PST)
Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002: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 DAA0712944C for <unbearable@ietf.org>; Thu, 2 Mar 2017 05:44:59 -0800 (PST)
Received: by mail-yw0-x234.google.com with SMTP id s15so33309551ywg.0 for <unbearable@ietf.org>; Thu, 02 Mar 2017 05:44:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IgNiCIS5An9KfTlPNTWeuJyFRsEqrEkatENH0/p1Ld8=; b=a+rkgZvWQMDZJWnOqoFS0rV8+DlBb8CQzxvHp3nq8YdM2ScKc1XCm0+AUL71d6VkUE UIhd/40zHWkBfX1KEatwKc4251nI3G0jWKecUl6aQkk+ejNTxEQsARrChoe8SE3QMyWX ZIhCvpdx1+iEFFMugnv6sVpv3Zv4PTtEWvq1w=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IgNiCIS5An9KfTlPNTWeuJyFRsEqrEkatENH0/p1Ld8=; b=hwb8MUkjfhUkAk2ViJcleQ1+mXIhmr7WU1EscEiRMkv3lyGet+ABi6b+DzvWaYrQME /PH73F9wdPjdxVT5COBEIz3mX9f+V7lY7fRmDK/+qgk2GitkQboTSb9l9BjqeUv3Mkyg 1ybpAe79SqwdtTGZtl7bDhvdo4WVt0NU3EHyNUMTcJ9qUv+MBHubIeQLfwGAE3oMrpIF j08jN6dKW3PFoxSJ2Rue57oPxyid0bE2Z5pXNPW6rMiFMscBOTOr04jUFr7ETeDhHrNE GvdBfGdkd2FxiEVkpac7EWMKe4zlA6FMurwLhZxZC0P+smPZx/BubYTjQ27eZeQkmdRT hOsQ==
X-Gm-Message-State: AMke39lj5EELnDkj+MTFddQd1Mm9d8O+BAvmMpOTX15DOiZp2yd0bYEP5vx8dMoxHH2q6mJszTUVmWzh2xLU6QK0
X-Received: by 10.129.68.31 with SMTP id r31mr4505781ywa.307.1488462299003; Thu, 02 Mar 2017 05:44:59 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.43.4 with HTTP; Thu, 2 Mar 2017 05:44:28 -0800 (PST)
In-Reply-To: <CABkgnnUnMFRh7bJVsaxBaiZbwbCq9h3KBpkChd=47XWRkQo-Fg@mail.gmail.com>
References: <90198679-4549-2893-6d91-f4415df217ad@sunet.se> <CABkgnnUPNRS1AUaVZy-Hkk6TD_yxLT8d_fG6LyFbPaJAJg4_cg@mail.gmail.com> <DM2PR21MB0091415B10C6C05BFFB841EC8C290@DM2PR21MB0091.namprd21.prod.outlook.com> <CA+k3eCS4-8uc=k6cupk=x-CGmC-ytE9SsmWrLZGjNkvjKFz3gA@mail.gmail.com> <CABkgnnUnMFRh7bJVsaxBaiZbwbCq9h3KBpkChd=47XWRkQo-Fg@mail.gmail.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Thu, 02 Mar 2017 06:44:28 -0700
Message-ID: <CA+k3eCQM51jqQNBDjvfSMfuqTetJwsvzjT2eONOj+Gc5wzZ_HQ@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Content-Type: multipart/alternative; boundary="f403045eb89c982e680549bfa220"
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/YK_3YMo8FSfGLPjbd2-bMGwKe58>
Cc: "unbearable@ietf.org" <unbearable@ietf.org>, Andrei Popov <Andrei.Popov@microsoft.com>, Leif Johansson <leifj@sunet.se>
Subject: Re: [Unbearable] WGLC 3 on core documents
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" <unbearable.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/unbearable>, <mailto:unbearable-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/unbearable/>
List-Post: <mailto:unbearable@ietf.org>
List-Help: <mailto:unbearable-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/unbearable>, <mailto:unbearable-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Mar 2017 13:45:01 -0000
On Wed, Mar 1, 2017 at 4:43 PM, Martin Thomson <martin.thomson@gmail.com> wrote: > On 2 March 2017 at 08:21, Brian Campbell <bcampbell@pingidentity.com> > wrote: > >> I believe there was some opposition to MUST, for deployments where the > >> client has knowledge of the cooperating servers. If nobody opposes a > switch > >> to MUST, I think it may be a good change to make. > > > > > > Yes there's a desire for the allowance of different scoping rules for > > application protocols where there's already knowledge of the cooperating > > servers and/or correlatable info is already being sent in a token to > > different servers. > > That's not an argument for SHOULD, that's an argument for flexibility > in scoping rules, which you already have. Since the application > protocol determines the scoping rules, you can let the MUST stand and > define scoping rules for the application protocol that suit your > needs. > Yes it's an argument for flexibility. My concern is with how the text might be interrupted. With the SHOULD to MUST change you're suggesting, it would say, "In order to prevent cooperating servers from linking user identities, different keys MUST be used by the client for connections to different servers, according to the token scoping rules of the application protocol." And I worry that some will zero in on the "different keys MUST be used by the client for connections to different servers" and take it very literally (especially the "to different servers" part) and out of context of the rest of the sentence that qualifies it with respect to the application protocol token scoping rules. Maybe that worry is unfounded but having it be SHOULD felt like it helps give that flexibility. I take your point though. What if it just said, "In order to prevent cooperating servers from linking user identities, different keys MUST be used by the client, according to the token scoping rules of the application protocol." taking the "different servers" bit out?
- [Unbearable] WGLC 3 on core documents Leif Johansson
- Re: [Unbearable] WGLC 3 on core documents Denis
- Re: [Unbearable] WGLC 3 on core documents Nick Harper
- Re: [Unbearable] WGLC 3 on core documents Denis
- Re: [Unbearable] WGLC 3 on core documents Leif Johansson
- Re: [Unbearable] WGLC 3 on core documents Martin Thomson
- Re: [Unbearable] WGLC 3 on core documents Andrei Popov
- Re: [Unbearable] WGLC 3 on core documents Brian Campbell
- Re: [Unbearable] WGLC 3 on core documents Martin Thomson
- Re: [Unbearable] WGLC 3 on core documents Nick Harper
- Re: [Unbearable] WGLC 3 on core documents Martin Thomson
- Re: [Unbearable] WGLC 3 on core documents Martin Thomson
- Re: [Unbearable] WGLC 3 on core documents Martin Thomson
- Re: [Unbearable] WGLC 3 on core documents Nick Harper
- Re: [Unbearable] WGLC 3 on core documents Andrei Popov
- Re: [Unbearable] WGLC 3 on core documents Martin Thomson
- Re: [Unbearable] WGLC 3 on core documents Andrei Popov
- Re: [Unbearable] WGLC 3 on core documents Martin Thomson
- Re: [Unbearable] WGLC 3 on core documents Brian Campbell
- Re: [Unbearable] WGLC 3 on core documents Andrei Popov
- Re: [Unbearable] WGLC 3 on core documents Brian Campbell
- Re: [Unbearable] WGLC 3 on core documents Andrei Popov