IETF Logo Mail Archive

Re: [OAUTH-WG] SUB and AUD configuration for web identity authentication

Ash Narayanan <ashvinnarayanan@gmail.com> Wed, 20 October 2021 22:52 UTC

Return-Path: <ashvinnarayanan@gmail.com>
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 2ED8A3A0AAA for <oauth@ietfa.amsl.com>; Wed, 20 Oct 2021 15:52:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 venGtQa04pUf for <oauth@ietfa.amsl.com>; Wed, 20 Oct 2021 15:52:39 -0700 (PDT)
Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) (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 B0AA63A0AB0 for <oauth@ietf.org>; Wed, 20 Oct 2021 15:52:39 -0700 (PDT)
Received: by mail-pj1-x102c.google.com with SMTP id gn3so3560111pjb.0 for <oauth@ietf.org>; Wed, 20 Oct 2021 15:52:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=V6OddtrtNkOKNHEOBPvxWpCQ+7uugRWDapLtoUd60UY=; b=MdsPngxbTyPdz95Im5J0wSSUnphlOl45KY8YK4JC/eC3NWCXuRWzfNE467LZRMtEAF j1PsFp8AvbJoSkL1S2Cga5cutQQKW6gDIcD+0uD3AZYzD8lgj+7vgHt0JIT5dNTNoj73 vjoJ+tQTSvZrlnrX/LHPHmHSKjUuLO00F+qjhMYYQKaIwlucSxjc4Mazk5p1im2L7xbx mo/C5BHXi0XdN7FuvpOo2cHdc/EMrN+3e8PZh4vUXkMsliQa8vvWlOPDcF3dDgBOxjqk sw/3f/sopKRSdMU3BsHxmGOWLF3Lcjo87UpGDFcTcdRIRGubCFRdYhYQgSOaSvZt8+SA kUrA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=V6OddtrtNkOKNHEOBPvxWpCQ+7uugRWDapLtoUd60UY=; b=U75O/s8K6PqnSzMf4ZGUugFiUMgi8ef+w6zKIgIcqjawSEHPbTzH1rDpfTahz2Eeaj PYT2JAJ3HZgpKVTUveldVIlO7GM0kfvrPTJ7ub/y2XVXapiQDNLwVHPDhiZVoXZ/HGOe d+32cRHO43AbdJ1hzQGQBg99yUXP/fqR2Oyc3xItxeia12kIy20VTr2X8NBLUkjoISLm PDavA5TyupQxLcd3WbMl1PIoU9xiSC8wPrbKbwfO3HLySkdorsjbOAEEGJ1673BLSu2I I33e8EsqXg2k2Kl/MQPJYn0Lchqug/s4xGwiRgjN63bLnwCKpxtL2UHe4/+4Qu27JIO6 opyQ==
X-Gm-Message-State: AOAM530Dm1IMmk9UXBw1oB1QMGvWOKsrRdNu/8x/XZyrtIxrBgkzn01F 6ZMuDoEi5mGMBfGHDtNNbzFeVAbofsk=
X-Google-Smtp-Source: ABdhPJz9hY+hXOZ0t1U6P0Py1+RvdLD0caxsW9Hicx1R+pLzHeyWBPECBJ5DoXL3d5/G8dT6oirzdA==
X-Received: by 2002:a17:90a:b117:: with SMTP id z23mr2171435pjq.74.1634770354873; Wed, 20 Oct 2021 15:52:34 -0700 (PDT)
Received: from smtpclient.apple (110-174-155-247.static.tpgi.com.au. [110.174.155.247]) by smtp.gmail.com with ESMTPSA id il17sm3659219pjb.52.2021.10.20.15.52.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 20 Oct 2021 15:52:34 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-CF6F45CF-5AEC-4A26-826B-39BD426587BB"
Content-Transfer-Encoding: 7bit
From: Ash Narayanan <ashvinnarayanan@gmail.com>
Mime-Version: 1.0 (1.0)
Date: Thu, 21 Oct 2021 09:52:30 +1100
Message-Id: <CFF4DC22-F09A-4666-9843-17CF247424B6@gmail.com>
References: <CAJot-L1y=8YUHe7hqwVRunQL0A2z2S=3sTd66uYTYwucSLmNqg@mail.gmail.com>
Cc: oauth@ietf.org
In-Reply-To: <CAJot-L1y=8YUHe7hqwVRunQL0A2z2S=3sTd66uYTYwucSLmNqg@mail.gmail.com>
To: Warren Parad <wparad=40rhosys.ch@dmarc.ietf.org>
X-Mailer: iPhone Mail (18H17)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/7eGGZSi0zehc_bM8Wlph8XGxJZ0>
Subject: Re: [OAUTH-WG] SUB and AUD configuration for web identity authentication
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 20 Oct 2021 22:52:44 -0000

Hm, interesting Warren.
AWS feels like both the AS and RS in this scenario; I don’t see any reason why these have to be separate entities.

> 
> On 20 Oct 2021, at 7:48 pm, Warren Parad <wparad=40rhosys.ch@dmarc.ietf.org> wrote:
> 
> 
> There is a pattern, where a user configures one credentialed entity for access to a RS, but controls neither the credentialed entity nor the RS. I might say technically the user is acting as the AS, but it isn't clear to me.
> 
> Concretely, CI/CD services such as GitHub and GitLab support runners that come with a JWT, whom this JWT should be issued to is not exactly clear. These tokens are intended to be used with third party RS such as AWS IAM to authenticate and access resources in AWS. (AWS reference)
> 
> Currently, GitLab is prototyping support for this access and wants to know what's a good meaningful value for the AUD to be. (GitLab context)
> 
> Personally, while I'm able to specify who is the client, RS, and AS, it doesn't feel exactly like it's something directly supported by any RFC, but it does seem like it should be. (AWS = RS, gitlab job = user, gitlab server = AS)
> 
> Due to the nature of what's available for configuration on both sides, it's likely they want to go with altering the AUD to point itself at the git repository url where the token comes from rather than the RS which would like be the AWS account. The closing thought I have is if we suspend for one moment expectations about who is authorization by whom, it's possible to also see that AWS is the AS, and the gitlab runner is a client using the jwt-bearer credentials grant.
> 
> Is there anyone that wants to weigh in on this, it's a potentially great opportunity to drive the right practice at the right time.
> 
> (I'm happy to relay any outcome back to the thread or feel free to post directly on the Gitlab issue.
> 
> - Warren
> 
> 
> Warren Parad
> Founder, CTO
> Secure your user data with IAM authorization as a service. Implement Authress.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

v2.23.0 | Report a Bug | By Email