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

Jan Brennenstuhl <jan.brennenstuhl@zalando.de> Thu, 23 February 2017 14:46 UTC

Return-Path: <jan.brennenstuhl@zalando.de>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1969312989B for <oauth@ietfa.amsl.com>; Thu, 23 Feb 2017 06:46:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=zalando-de.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVXU0nHwcwjj for <oauth@ietfa.amsl.com>; Thu, 23 Feb 2017 06:46:26 -0800 (PST)
Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (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 329EA1297CA for <oauth@ietf.org>; Thu, 23 Feb 2017 06:46:26 -0800 (PST)
Received: by mail-wm0-x230.google.com with SMTP id v186so173983914wmd.0 for <oauth@ietf.org>; Thu, 23 Feb 2017 06:46:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zalando-de.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:message-id:date:to; bh=17evyP5A5wlrYlGNv5sfbCUvspQ4O2zfe1g9rSry3HA=; b=xm8qtOVfPANiNq+Bk/3Xc2C3YKvmlz48+j7TbfXF5tVuhIiFQUerzBtI9xTrTtXG4y qZhOqnVZERCQM348siCUuh1XOBMBrRRnndjrsRBvffht/S1s0v7aalLdV7yvtwlxAYQ8 3isORwst7Dcmlu58gIX8N7r9Scz1wiU/Are8LpdGgTp4wipQX2h3YQ2pYLF/8vXji6Ko nt5tR8y7EMjy4zUJWS4HrtheTW6M/8xi8xhN0nmURgGWO5qCcqQFsMLgeAUDr0+hixKW ty+irCLCcACrV5fFc3pCSCYpIqzsjVwWpHz8w4KDSIDUQc5+DMS2UKjX7bhLD6PlR2hi 2uSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=17evyP5A5wlrYlGNv5sfbCUvspQ4O2zfe1g9rSry3HA=; b=NsILd8+sprDYgKnOQaFeC/wTih8ADK2v+2cw4UFgeXTz0RvY/l74kVaN0Z06Sfkbik V+Dq4E2BMTY15sbzFfi/bZu05410NUBb2lt6Z3LcJ0lLT+AINU2q7Uv9Fm+BTblYHwR7 LE/1XAJjzVCZx5fB1y9Htv7YiCTGgI2iRSD0nC+a8MzFm0pHVd7qfTAWi1kDPlosDT3D g/zIOrrNpFEALvlYtmeQV74afSkvaBPLLB/kkAD3S1eqxxQYtEmGPc9mFgn/cWDgAP03 vnkm6kI3ibd34CwSOIEBGJT2HZFwbgziY5p32dDTHF1Qkx8A6gLj0G84xUDb6LcckTc+ m2SA==
X-Gm-Message-State: AMke39kECHmvY9/7rAmtr5LO3K2v/v2r1mBI104hwCdPUuRGrQlI0Po5Se8Ru+yrSKW2g7F7
X-Received: by 10.28.126.12 with SMTP id z12mr3248793wmc.84.1487861184378; Thu, 23 Feb 2017 06:46:24 -0800 (PST)
Received: from zalando-09663.corp.ad.zalando.net ([185.85.220.194]) by smtp.gmail.com with ESMTPSA id 65sm6286716wri.53.2017.02.23.06.46.23 for <oauth@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Feb 2017 06:46:23 -0800 (PST)
From: Jan Brennenstuhl <jan.brennenstuhl@zalando.de>
Content-Type: multipart/alternative; boundary="Apple-Mail=_B7BB17F1-70FA-4FD8-8808-5A87EDF111AF"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Message-Id: <CB347881-02CF-4ECB-AF02-01F28B54233F@zalando.de>
Date: Thu, 23 Feb 2017 15:46:22 +0100
To: oauth@ietf.org
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/N9ovhMmcw4EwivnLXYfha_6Bef0>
Subject: [OAUTH-WG] [oauth-token-exchange] Composite Token Design
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
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: Thu, 23 Feb 2017 14:46:28 -0000

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