[OAUTH-WG] AD Review: draft-ietf-oauth-token-exchange-09

Eric Rescorla <ekr@rtfm.com> Fri, 29 December 2017 16:41 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 2D06B129C51 for <oauth@ietfa.amsl.com>; Fri, 29 Dec 2017 08:41:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id UwdozcFWVzDV for <oauth@ietfa.amsl.com>; Fri, 29 Dec 2017 08:41:39 -0800 (PST)
Received: from mail-yb0-x234.google.com (mail-yb0-x234.google.com [IPv6:2607:f8b0:4002:c09::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 91186120725 for <oauth@ietf.org>; Fri, 29 Dec 2017 08:41:39 -0800 (PST)
Received: by mail-yb0-x234.google.com with SMTP id s10so1154486ybl.7 for <oauth@ietf.org>; Fri, 29 Dec 2017 08:41:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=KB0xao1HYPTPEbzduHwxitC210tPtFiM84/uONbGej4=; b=xhhuAH4ROH9nqq9id2fopFgFzQWeGOZIATMSTEuCMU5k30hdQ+28ctv+/rvVmhaqB6 Xm2vmWUVCaktUxsiI/r7+GpzOB66KYDlwoOG6FmHndaBNK+9CMQ9GoSxKonwXONItWm6 pF65cZbOwVmr3y6neFofyXl3F1UIyUZ9/02V/jZi23NkNDLitjm9jQ2G5qMv+3gBpY7g bkrVYWqtsu8MnDoKGs3xztdrw5x5MEiRL51u8HBh/3mkah0KNsudj4JVviO1gpJPg72V 1lWARjBH5OF4zIclIaBxSLvZUc84BjOmKfWB/rqVb404aNxG+QkiBidYOOJrPFrDvmG1 CWnw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=KB0xao1HYPTPEbzduHwxitC210tPtFiM84/uONbGej4=; b=Ur2ZVbLPSRh+bOmXRAjjhP5nhqqVjivzCtjjniLavze2NvNXEIOZ9I0xRMiFscDrUn dahMqQoA6pi22yOnOQAEwtL+vltfdO0eZrFLCfNegiVTN3D/pz4doiDLpqhnJtTfLVDe htvMTOJt+8fPEeF5LeWn1rxLnQtTzMtzeXASiRswOj4e7em5NUvshKxivOjj7r7ACdI/ Zx5fJVBRHvzxbCn25ODZtaU5i+kYZos0lNGpDZ7XEjioB4407xJC1o1pUpTtihsiib5O rFj88/EBvV5p0neRQKMEuffZllzS6gtMHyu9hJzLd50at1fG2GZ6qXoTwlOsteO87cWI 4+GA==
X-Gm-Message-State: AKGB3mJdldEEvVrMXh1v2Gc2vV3LxQNyq5IzLiRAEu3glkOkMDvEvhRJ e9ObPDH6ZgVSUb2Mp+gpzBsrNXiI8A4nFqz14o+BurzQyK0=
X-Google-Smtp-Source: ACJfBovyrj+aDyFgTDeA6e0n/L/DvG8CeZ0jPKyfrVbAtYBf6PwckPKj0pbSsm4pcchOovPcTSKbMI4K01adLQxkghA=
X-Received: by with SMTP id n2mr3869138ybm.293.1514565698395; Fri, 29 Dec 2017 08:41:38 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Fri, 29 Dec 2017 08:40:57 -0800 (PST)
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 29 Dec 2017 08:40:57 -0800
Message-ID: <CABcZeBMWAKb1D_e3wRBSmYOiE64XbzLq6hzPO1GSEYOZ1dP6tw@mail.gmail.com>
To: oauth@ietf.org, draft-ietf-oauth-token-exchange@tools.ietf.org
Content-Type: multipart/alternative; boundary="089e08264eb071354f05617d4e37"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/pNa3j5Ku42R99rb0bw-zvoiznqs>
Subject: [OAUTH-WG] AD Review: draft-ietf-oauth-token-exchange-09
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 29 Dec 2017 16:41:42 -0000

Full-featured review at:

As noted in inline comments, some additional words about the security model
in which this document is embedded seem like they are needed. In
particular, it's pretty unclear to me what checks the STS is supposed to do
on a given request to determine whether to fulfill it. Where is that

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D4278#inline-1580>
securing access to HTTP and RESTful resources but do not provide
everything necessary to facilitate token exchange interactions.

Can you say a bit more about what is missing here?

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D4278#inline-1581>
REQUIRED. The value "urn:ietf:params:oauth:grant-type:token-
exchange" indicates that a token exchange is being performed.

I note that S 4.5. says that the grant_type is "defined by the
authorization server" but that's not the case here, right?

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D4278#inline-1582>
OPTIONAL. Indicates the physical location of the target service
or resource where the client intends to use the requested security

Do you actually mean "physical" here? Presumably if it's a URI it's most
likely a network address. I would take "physical" to mean "geographic"

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D4278#inline-1583>
target services with a mix of logical names and physical

But it seems you can only specify one of each, right?

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D4278#inline-1584>
security token in the context of the service or resource where the
token will be used.

It's not clear to me where these values would come from. Can you expand on

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D4278#inline-1585>
REQUIRED when the "actor_token" parameter is present in the
request but MUST NOT be included otherwise.

It's not entirely clear to me from this text how these tokens authenticate
the request. It's clear if they are bearer tokens, but if they are some
sort of token over a public key, then how does that work.

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D4278#inline-1586>
2.0 [OASIS.saml-core-2.0-os] assertion, respectively. Other URIs to
indicate other token types MAY be used.

This feels like it would be better as some kind of list (maybe bulleted)?

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D4278#inline-1587>
it as the current actor and that can be used at

Where can I find the definitions of "iss" and "sub"?

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D4278#inline-1588>
response, "act" has the same semantics and format as the claim of the
same name.

It's not entirely clear to me how I'm supposed to evaluate these from an
access control perspective.

Is the assumption here that the entity producing the JWT has ensured the
correct chain of issuers and subs?

Is it the RP's job to evaluate whether each entity in the chain could have
performed the action?

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D4278#inline-1589>
claims such as "exp", "nbf", and "aud" are not meaningful when used
within a "may_act" claim, and therefore should not be used.

I'm having a hard time understanding this claim. Can you provide an example
to me (in email is fine, it doesn't need to be in the draft) of how it
would be used?

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D4278#inline-1590>
produced under the chairmanship of Hannes Tschofenig and Derek Atkins
with Kathleen Moriarty and Stephen Farrell serving as Security Area
Directors. The following individuals contributed ideas, feedback,

You may want to update this

rIETFREVIEW ietf-review



*To: *ekr-moz, ekr
*Cc: *ekr