Re: [OAUTH-WG] [oauth-token-exchange] Composite Token Design

Brian Campbell <> Tue, 28 February 2017 22:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ED2DF128AC9 for <>; Tue, 28 Feb 2017 14:23:40 -0800 (PST)
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 BsFi3_4UnZl5 for <>; Tue, 28 Feb 2017 14:23:39 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4C7DD1293E0 for <>; Tue, 28 Feb 2017 14:23:39 -0800 (PST)
Received: by with SMTP id v200so19131569ywc.3 for <>; Tue, 28 Feb 2017 14:23:39 -0800 (PST)
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=jZdjscVWi0yV5TkfaQBEUDtoJXdaKmLMYOhKnh8Zpdk=; b=OF2/mvSZDpBLkhQlOgKkDYPdPZgVw7k82Sq/BClsNOzSTqD6CWwcsRdTCrgFiJALS5 0HopeaNvrSrvJ3hBGGFn4Fa9gTOZ+j5KjLKaJ7ZrCQGFmoDvs2W0eW4of9ADkW9lZQ/G ij5fmOOheDTPHXzOh6MCTZrBYbQwd+bVDtdXA=
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=jZdjscVWi0yV5TkfaQBEUDtoJXdaKmLMYOhKnh8Zpdk=; b=eK/CnkoxXFIDDwil3rNRymzGSOfWDjT6Q9zMVjte0wKszoFhy3gj3wvrhUYg5+98CF m9R6HbtlrQPrGIg6OD/lc59LPKCWRpvDrAE5VODTt+XxbKdlyytQ7PevAq84pC/avisM 3h1J08J9ZGXJlQJA7hS+8TGXbkLappJjhoglqGoab9rI3LenPwC8fR7FeX2YX4a4Ew+D 2c/PDLaVU34zljW01vEiYIZZdJxtNRfo2GdDjbz1KK252yfsraPtdSk075n7V5xX6SLj 6qzPTSMb5BOe1s7tJCgEod3+f+Py3lbOkBM0G1yY2bWv6Nmx21BQDOOTbc0gmpTOSboy tJ9Q==
X-Gm-Message-State: AMke39kkG0I5e+8XnY6sBWuH1Df4RdT0jdBMHW7rcwlmZ4yD8yyaox5Z5hm7DZjK+W9//XS12FuQl5WbUdaxctlL
X-Received: by with SMTP id d35mr1570653ybi.32.1488320618366; Tue, 28 Feb 2017 14:23:38 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 28 Feb 2017 14:23:07 -0800 (PST)
In-Reply-To: <>
References: <>
From: Brian Campbell <>
Date: Tue, 28 Feb 2017 15:23:07 -0700
Message-ID: <>
To: Jan Brennenstuhl <>
Content-Type: multipart/alternative; boundary="94eb2c19a52cc573fa05499ea533"
Archived-At: <>
Cc: oauth <>
Subject: Re: [OAUTH-WG] [oauth-token-exchange] Composite Token Design
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 28 Feb 2017 22:23:41 -0000

Hi Jan,

I don't think you're missing anything. However, the use of the 'act' claim
to identify the delegate and convey that delegation is happening was an
intentional decision. While delegation is a security sensitive thing, it
often occurs as impersonation with no explicit indication about delegation.
Layering on the delegate info in a claim like this allows for those kinds
of cases to continue working while augmenting the token with data
about the delegate
that can be used for audit or access control (but doesn't have to be).
Which, I guess, is to say that your worries were indeed a design goal of
the document. That may not alleviate those worries but hopefully does
provide some insight into the reasoning behind the current composite token

On Thu, Feb 23, 2017 at 7:46 AM, Jan Brennenstuhl <> wrote:

> Hey everyone,
> Let me shortly introduce myself - My name is Jan, I do IAM at Zalando SE.
> I am writing, because I like to get a better understanding of the
> reasoning behind a fundamental conceptual decision that was made in the
> oauth-token-exchange draft.
> The draft describes one possible design of a composite token: an 'act'
> claim in a representee token, meaning that a regular principal token gives
> the information about a possible delegate/ agent a piggyback.
> In my eyes, this is not quite intuitive nor the most secure solution as:
>    - the current approach cloaks the true nature of the delegation as the
>    actual actor is not represented by/ in the primary token,
>    - the current approach would be entirely transparent for old/ legacy
>    systems which do not know about a possible act claim. Those applications,
>    would support delegation simply because they do not know any better. For
>    them, the intended delegation would look like a true impersonation.
> As delegation usually is a highly security sensitive thing to do, I
> personally would prefer the probably more secure approach of defining a
> primary agent token with a nested representee token/ information. This
> would lead to systems not just silently supporting delegation (without
> knowing about it). They would need to explicitly support the spec if they
> want to support delegation.
> My questions now are:
>    - am I missing something here,
>    - do you share my worries,
>    - what are the actual reasons for the current composite token design?
> Would be great if you could provide some background info on why you chose
> to follow the current approach.
> Thanks, Jan
> _______________________________________________
> OAuth mailing list