Last Call Review of draft-ietf-oauth-token-exchange-14

Request Review of draft-ietf-oauth-token-exchange
Requested rev. no specific revision (document currently at 19)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2018-08-06
Requested 2018-07-23
Authors Michael Jones, Anthony Nadalin, Brian Campbell, John Bradley, Chuck Mortimore
Draft last updated 2018-08-09
Completed reviews Genart Last Call review of -14 by Jari Arkko (diff)
Opsdir Last Call review of -14 by Zitao Wang (diff)
Secdir Last Call review of -14 by Hilarie Orman (diff)
Assignment Reviewer Hilarie Orman 
State Completed
Review review-ietf-oauth-token-exchange-14-secdir-lc-orman-2018-08-09
Reviewed rev. 14 (document currently at 19)
Review result Has Issues
Review completed: 2018-08-09


Security review of draft-ietf-oauth-token-exchange-14
OAuth 2.0 Token Exchange

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments
just like any other last call comments.

The abstract states:
   This specification defines a protocol for an HTTP- and JSON- based
   Security Token Service (STS) by defining how to request and obtain
   security tokens from OAuth 2.0 authorization servers, including
   security tokens employing impersonation and delegation.

[This review is late because I mistook the due date, 
dd-mm-yyyy = 06-08-2018 
mm-dd-yyyy = 06-08-2018
and ignored the mm because obviously it is August and just focused on
the day.  Which goes to show that it is important to understand what
a message means.]

I'm not at all sure I understand what the various fields in the new
OAuth 2.0 tokens really mean.  For example, section 4.1 about Actor
Claims says that a web application might receive a token expressing
that subject "admin" is acting for subject "user".  The web
application could "exchange" that token for a new one showing itself
as the actor for "user".  As a "chain of delegation", this is
confusing.  It would seem that the original token could be used to
access resources, and the "exchange" of one token for another is not

The complications of delegation and "impersonation" and "may act for"
aside, section 7 (Privacy) seems to open a can of worms.  Tokens may
"reveal details of the target services" and thus may give away
information about what the subject is doing or intends to do.  But the
subject must send the token in order to access the resource.  What is
a rational privacy policy for Oauth tokens?  Will clients find it
expedient to include all their tokens in every request?  How does a
client know which tokens a server can be trusted with?  The document
suggests that the tokens should only be communicated according to the
privacy policies of the "respective organizations".  How do two
organizations communicate their privacy policies to one another?
This section needs some amplification.

The document is well-written, but the subject is complex.