Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt

Brian Campbell <> Wed, 18 April 2018 22:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 615151241F3 for <>; Wed, 18 Apr 2018 15:12:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id k4c7T-MGNZfP for <>; Wed, 18 Apr 2018 15:12:32 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B4C41120047 for <>; Wed, 18 Apr 2018 15:12:32 -0700 (PDT)
Received: by with SMTP id d6-v6so4324259iog.1 for <>; Wed, 18 Apr 2018 15:12:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=c4kRafq3CF6nyVmwEiILBLdvJdqdYmHmdAi2aw9WL6I=; b=NVPUeGKr/ZrJiGjZOu+nT5uyQHLA1Mo6E2YcE14CjsBHCwdtQUtrTyZce2tCUgxEDg ib7ZbCogWKTphEDfyoHKXqOlrvmvzJ24sBIfcZLbCWKtynI9VUqIsXDhlpqKSh1WEa3d tn6ENu47CssHiqVPJU66VdVYnkgPdDa1XhYJU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=c4kRafq3CF6nyVmwEiILBLdvJdqdYmHmdAi2aw9WL6I=; b=BLh3WqPtS8Xovx2m7OPSWzxnBLYTkUVS4nxTpxsvc1lfU6AgMdpVvZkvI3tqQ1WPmW Ud1cRygUnMGpr2EFyfrYwbQOmvX+/kHe5zMavclPyJd3q8tqXuTZjc0Wu4hJ+SZwv2K/ GQAP/KutCUhzW6xB2cHdiwx8xeA3RjbFThfbuOAUkwJHIZfCseC/gBGTpJXr4LEerOQR BWr0RtjfBmIeRpymEDBQ6qbsIcAE+FWLsfIP5VBKUjdCDwwOzQp/WYM+2CVHbO7Vjqdf MIM29eqz05ZJn5jVMvpY2Au8vrgqKABTwzNj44XfeU1t7siDNNWJ9boUQok+LrrSY17F YULQ==
X-Gm-Message-State: ALQs6tA8NC2j6EtbLFFNBhU8g/B24cX/aX3wMQTQhR5FMZZgcsaMZc9s vvXIP49fOisI7STUvDS2+P2mxemUZxXHOwjwcpIE5as/EwTuVFOGW2fyH50/F7ohj7ogSqDaavG VYiBp0y/oeChFyg==
X-Google-Smtp-Source: AIpwx49e8D8ZdXOx5fEOBD7c61CKYHtqg/oSL8VbvrunnWrFfqN5C9PwwdFRNwMkbBtN14RxGWeOYW8fS73Rp6HxkyA=
X-Received: by 2002:a6b:591:: with SMTP id 139-v6mr1298370iof.282.1524089551618; Wed, 18 Apr 2018 15:12:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a02:144a:0:0:0:0:0 with HTTP; Wed, 18 Apr 2018 15:12:01 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Brian Campbell <>
Date: Wed, 18 Apr 2018 16:12:01 -0600
Message-ID: <>
To: Eric Rescorla <>
Cc: oauth <>
Content-Type: multipart/alternative; boundary="000000000000549fe4056a26c09c"
Archived-At: <>
Subject: Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt
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: Wed, 18 Apr 2018 22:12:35 -0000

Eric, I realize you weren't particularly impressed by my prior statements
about the actor claim but, for lack of knowing what else to say, I'm going
to kind of repeat what I said about it over in the Phabricator tool
<> and add a
little color.

The actor claim is intended as a way to express that delegation has
happened and identify the entities involved. Access control or other
decisions based on it are at the discretion of the consumer of the token
based on whatever policy might be in place.

There are JWT claims that have concise processing rules with respect to
whether or not the JWT can be accepted as valid. Some examples are "aud"
(Audience), "exp" (Expiration Time), and "nbf" (Not Before) from RFC 7519.
E.g. if the token is expired or was intended for someone or something else,
reject it.

And there are JWT claims that appropriately don't specify such processing
rules and are solely statements of fact or circumstance. Also from RFC
7519, the "sub" (Subject) and "iat" (Issued At) claims are good examples of
such. There might be application or policy specific rules applied to the
content of those kinds of claims (e.g. only subjects from a particular
organization are able to access tenant specific data or, less realistic but
still possible, disallow access for tokens issued outside of regular
business hours) but that's all outside the scope of a specification's
definition of the claim.

The actor claim falls into the latter category. It's a way for the issuer
of the token to tell the consumer of the token what is going on. But any
action to take (or not) based on that information is at the discretion of
the token consumer. I honestly don't know it could be anything more. And
don't think it should be.

There are two main expected uses of the actor claim (that I'm aware of
anyway) that describing here might help. Maybe. One is a human to human
delegation case like a customer service rep doing something on behalf of an
end user. The subject would be that user and the actor would be the
customer service rep. And there wouldn't be any chaining or nesting of the
actor. The other case is so called service chaining where a system might
exchange a token it receives for a new token that it can use to call a
downstream service. And that service in turn might do another exchange to
get a new token suitable to call yet another downstream service. And again
and so on and turtles all the way. I'm not necessarily endorsing that level
of granularity in chaining but it's bound to happen somewhere/sometime. The
nested actor claim is able to express that all that has happened with the
top level or outermost one being the system currently using the token and
prior systems being nested. What actually gets done with that information
is up to the respective systems involved. There might be policy about what
system is allowed to call what other system that is enforced. Or maybe the
info is just written to an audit log somewhere. Or something else. I don't
know. But whatever it is application/deployment/policy dependent and not
specifiable by a spec.

On Fri, Apr 13, 2018 at 6:38 PM, Eric Rescorla <> wrote:

> Hi folks,
> I've gone over draft-ietf-oauth-token-exchange-12 and things seem
> generally OK. I do still have one remaining concern, which is about
> the actor claim. Specifically, what is the RP supposed to do when they
> encounter it? This seems kind of underspecified.
> In particular:
> 1. What facts am I supposed to know here? Merely that everyone in
>    the chain signed off on the next person in the chain acting as them?
> 2. Am I just supposed to pretend that the person presenting the token
>    is the identity at the top of the chain? Say I have the
>    delegation A -> B -> C, and there is some resource which
>    B can access but A and C cannot, should I give access?
> I think the first question definitely needs an answer. The second
> question I guess we could make not answer, but it's pretty hard
> to know how to make a system with this left open..
> -Ekr
> _______________________________________________
> OAuth mailing list

_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._