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

Mike Jones <> Fri, 29 December 2017 17:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 83EC6126CE8 for <>; Fri, 29 Dec 2017 09:48:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.01
X-Spam-Status: No, score=-3.01 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, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 viEzBcAr4hxw for <>; Fri, 29 Dec 2017 09:48:11 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EC20A12426E for <>; Fri, 29 Dec 2017 09:48:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=u0g6IAGS25u+jpOWgxieACaVeBIiviG/IP0J48ayMeg=; b=FzQXi2OtKPAZtkbUuuGTSHDpM/alA9CUiLCjXy83bsyv0v6amXpnQHJ6hNgUagnDiZTnQyin9Lwg1bI6VmjeLOlZkheW1DtGfvYPM3/SK2k/9q48Zn3LfCvEE5Z4QlIjCLisouSDswAqQOSTsYHLgkr4tVpKS2K5hMSLxRBY08o=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.345.2; Fri, 29 Dec 2017 17:48:06 +0000
Received: from ([]) by ([]) with mapi id 15.20.0407.000; Fri, 29 Dec 2017 17:48:06 +0000
From: Mike Jones <>
To: Eric Rescorla <>, "" <>, "" <>
Thread-Topic: [OAUTH-WG] AD Review: draft-ietf-oauth-token-exchange-09
Thread-Index: AQHTgMPugLlckbvpIE2JNpgrfT8UNaNamK8Q
Date: Fri, 29 Dec 2017 17:48:06 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR21MB0744; 7:KycoF0nBje0+P7OEO8Fxw/2JHA6p0WEisabdy7MndF/T0AeQhZWqSLZyArbVXdBJAduTy38ZhA2sXDIBdGNRn9tnmInEYnUJYNS0a/c8yX25sufMfWnQnrzHaztX2u+WVcmPfEVAqG1+NTnm5k8LmsBAmorV3xJn9ZO+ho+EK0dWWkS9hFpxQGcXKp6f5Zq+WHnj/np64lnfgwVqShU02QoIcFAwYq1X6mDjDMZPwdpAdV08GY4Ls3MQArCiKK+O
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 3f4f388b-34a5-41d8-7dbe-08d54ee4516f
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020020)(48565401081)(4534040)(4602075)(4627136)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307); SRVR:CY4PR21MB0744;
x-ms-traffictypediagnostic: CY4PR21MB0744:
authentication-results: spf=none (sender IP is );
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040470)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(3231023)(944501075)(6055026)(61426038)(61427038)(6041268)(20161123564045)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:CY4PR21MB0744; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:CY4PR21MB0744;
x-forefront-prvs: 0536638EAC
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(39860400002)(366004)(39380400002)(396003)(51914003)(189003)(199004)(66066001)(22452003)(8936002)(790700001)(6116002)(33656002)(55016002)(6306002)(6506007)(236005)(2501003)(86362001)(316002)(6246003)(76176011)(478600001)(2906002)(77096006)(10290500003)(25786009)(3846002)(10090500001)(99286004)(3660700001)(105586002)(229853002)(2900100001)(6436002)(53936002)(966005)(81166006)(2950100002)(54896002)(68736007)(2201001)(3280700002)(7696005)(110136005)(53546011)(8676002)(9686003)(230783001)(14454004)(72206003)(97736004)(7736002)(5660300001)(74316002)(81156014)(19609705001)(86612001)(102836004)(106356001)(8990500004)(606006)(59450400001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0744;; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
x-microsoft-antispam-message-info: oYIuvdlgxa1umnLYHcLK1vyD+C5iDnMyJOR0AwLVbITfn9ejLNQygSGj2OGzDrF282a2/6pGT1fQ3B744VFs2w==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY4PR21MB05046590C8F5889AB1AAA3C7F5050CY4PR21MB0504namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 3f4f388b-34a5-41d8-7dbe-08d54ee4516f
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Dec 2017 17:48:06.7243 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0744
Archived-At: <>
Subject: Re: [OAUTH-WG] AD Review: draft-ietf-oauth-token-exchange-09
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 29 Dec 2017 17:48:14 -0000

Thanks for the useful review, Eric.  I’ll work with Brian and the crew to incorporate this feedback.

                                                       -- Mike

From: OAuth [] On Behalf Of Eric Rescorla
Sent: Friday, December 29, 2017 8:41 AM
Subject: [OAUTH-WG] AD Review: draft-ietf-oauth-token-exchange-09

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 documented?

View Inline<>draft-ietf-oauth-token-exchange.txt:129
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<>draft-ietf-oauth-token-exchange.txt:265
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<>draft-ietf-oauth-token-exchange.txt:268
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<>draft-ietf-oauth-token-exchange.txt:304
target services with a mix of logical names and physical

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

View Inline<>draft-ietf-oauth-token-exchange.txt:310
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 this?

View Inline<>draft-ietf-oauth-token-exchange.txt:341
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<>draft-ietf-oauth-token-exchange.txt:587
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<>draft-ietf-oauth-token-exchange.txt:666
it as the current actor and that can be used at

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

View Inline<>draft-ietf-oauth-token-exchange.txt:689
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<>draft-ietf-oauth-token-exchange.txt:755
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<>draft-ietf-oauth-token-exchange.txt:1273
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