Re: [secdir] Security review of draft-ietf-oauth-token-exchange-14

Brian Campbell <> Mon, 13 August 2018 17:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B1176130FCA for <>; Mon, 13 Aug 2018 10:37:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7nJdamV_fRL3 for <>; Mon, 13 Aug 2018 10:37:33 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A4397130FCD for <>; Mon, 13 Aug 2018 10:37:18 -0700 (PDT)
Received: by with SMTP id h23-v6so15251455ita.5 for <>; Mon, 13 Aug 2018 10:37:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dOLuwW7Oh3OKvHzH+9QHpgxZjeBwR6YsL1CuAyt581o=; b=L9vHMc0ta+XeZyMxvNruyWH0bYlOC/Av5RMkjmAgxpvPdII+tEYvIVTr3cIApe2LtB NqkIQIlGW0ESO09oLroWuVT5xOycJz8m6C3jWOqZeFOyzcxaBvOIFkSeEUPEcNjrvHfs Gx2Fq1idWullFN/t9bWcl4mrjbMCorPCNv1gU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dOLuwW7Oh3OKvHzH+9QHpgxZjeBwR6YsL1CuAyt581o=; b=KrECdh2KT+T04SIwyj1RzMpyapq/usWSrAoDdYsXxdKvXCK/HhwD2JbSRImdiII9vT Lyy6HrRFAReqPb1RPEDdSlhx5BKOfEHfHNSF/YUgmNBwKlAXwbqB1tgCUJH77+1t6phJ qvqW7iAlu+IunnUD322lZrq1AvOlkD12FaTL/IcMIV6955B0WA+Ru728nVjvGw0UrnFg Y0Hjoe3N/G/wV5FV/LiXYNiG6rBc1PgjspEXuUETs5Ei7r2eEWOBBQ1ntpx+65WFZ8cw 3rO3QxnGaSWPMbaULVO8eyA3XaaoTW979wlx+05wJsY22jfbpuYaq2bmfDdo9rdQVzWr dbwA==
X-Gm-Message-State: AOUpUlHo3iZC1QdiGJXxVnNlvaeCleYxu8NiQmEU6MK0EADvmFvCwDNw ZSHenzH4RnqDXLFGssWFOrSqYEzBmoYR507TDNefZk5QI3clfRS+aaB9Nm1KrJhEdv9ZA/hob2u 6VLHjIkAeg+Umgg0=
X-Google-Smtp-Source: AA+uWPyRrI6tXPc917DaPmN5rN9Vok97wRtVyciPjv/NClBTYD0C7XWED/qgjMZh8ZAaSQHlE1I0pxe3f85hhKAp18I=
X-Received: by 2002:a24:a308:: with SMTP id p8-v6mr11770302ite.53.1534181837673; Mon, 13 Aug 2018 10:37:17 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Brian Campbell <>
Date: Mon, 13 Aug 2018 11:36:49 -0600
Message-ID: <>
To: Benjamin Kaduk <>
Cc:, The IESG <>,,
Content-Type: multipart/alternative; boundary="00000000000074d42f0573548b3f"
Archived-At: <>
Subject: Re: [secdir] Security review of draft-ietf-oauth-token-exchange-14
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 13 Aug 2018 17:37:36 -0000

On Fri, Aug 10, 2018 at 3:26 PM Benjamin Kaduk <> wrote:

> ...
> With the disclaimer that I haven't read token-exchange recently and am
> mostly going off my memory of the mailing list discussions, it seems like
> the key consideration here is that token exchange allows you to convert a
> token that may be opaque to you into one that has inspectable fields, and
> those fields can be privacy sensitive.  So a JWT response should only be
> given to a requestor that trusted to know such information; a lot of the
> time, that has large overlap with being trusted to have the token in the
> first place, but potentially there is some amount of non-overlap.
> The considerations from 7523 of course also apply, and sensitive
> information should not be sent over unencrypted channels, but isn't the
> above paragraph an aspect inherently new to token exchange?

I don't think it's unique to token exchange. RFC 7523, for example, defines
the use of a JWT as an authorization grant used to obtain an access token
from a authorization server. Unless encrypted as a JWE, the JWT in that
scenario has fields that are inspectable to the client. And an OAuth access
token is considered opaque to the client but whether or not information in
the token is actually accessible to a client is an implementation detail of
the authorization server. The latter is true for OAuth in general and not
just these more specialized exchanges.

The idea behind maybe incorporating some text similar to (but adapted to
the context) what's in the privacy considerations of RFC 7523
<> is that the considerations
are pretty much the same - use TLS in transit, minimize the amount of
information in the token, encrypt the token if disclosure of its
information to the client is a concern.

_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._