Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse and OAuth 2.1
Aaron Parecki <aaron@parecki.com> Wed, 13 October 2021 21:35 UTC
Return-Path: <aaron@parecki.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 97F123A0D5A for <oauth@ietfa.amsl.com>; Wed, 13 Oct 2021 14:35:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki.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 ONa1-3wMz_zH for <oauth@ietfa.amsl.com>; Wed, 13 Oct 2021 14:35:49 -0700 (PDT)
Received: from mail-oo1-xc2c.google.com (mail-oo1-xc2c.google.com [IPv6:2607:f8b0:4864:20::c2c]) (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 D17B33A0D49 for <oauth@ietf.org>; Wed, 13 Oct 2021 14:35:48 -0700 (PDT)
Received: by mail-oo1-xc2c.google.com with SMTP id k11-20020a4aa5cb000000b002b73749f3cdso588155oom.4 for <oauth@ietf.org>; Wed, 13 Oct 2021 14:35:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JjSe0W8lFC8kUB90DTPYt8IWW2lAUR7olCc+YrSlfpU=; b=Xf6liZ5Zys6PV384bbswECYgJ6CgPl9sojX5l7GlT2wOdkgW6DZ9z44J1VzQK4WkzI 2vIFh3JBLzLqBAb/KQ2Hw8gPAHbHOukD8A9C/hk0/0JEcqUSoXfTvpT2/CIRfD8mU3uU QQFOT4UQI8xq4eziosMCH9BvBHMv6KYL2G9z6KT0nFPhJ86bFiq9WicUWuQrVNru02Er JuiARBydGpsji2MPhlAV6GExQD+YcNVPUeEe0mbHjfjNkjSTQEbsx8gG/iYELmLxy4sr KBiT6DnqP5fPCiszy+Yn1Vl53SVmITaxp10KpkpncVHB6vrDBJkj5uWMRvgm0mF7AUBj mivg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JjSe0W8lFC8kUB90DTPYt8IWW2lAUR7olCc+YrSlfpU=; b=GWWLrhtT2W8lk4eq2g/qwd2RerJqC1bH3vQsAMTnGWdGxPP87unVRWhvygZ5c+rmvC vxu3WPthvzBvTub9SETtFuMTs1V0ZnXko+SWZ7V6j0Zn2a5ROPmm7kAgYAbGN2toFHwS T+TUCjqAzqKQXg8Z+Gw4AJEiP3JwTV/eMadjo748j453xLzC+oWxhz/Veb+n/JW4HNTp wQOwEkOZ9yTaNTREOF4+hG29XVttaV3Dmk2wJPYJEa7EzAjlf/yXFaWDF/knAk0o0eet i8mQsyHeLLUbLfz35c8bILZ6L2EEtoXJvDE5J5+wQJu2a8m2yQYAIlijpesgCm6W/e54 XlMA==
X-Gm-Message-State: AOAM530ZdEor9jChiyO6V9aLYFwZaE6g3tD+v9ut61gccl4Cgq0jjbo8 2Ihh9+kj/qDxciMjimJ2BNMEJSiej1jN6A==
X-Google-Smtp-Source: ABdhPJxFIPAfc68mee4b4yrVLAozF1M53UlBTLFeJNAzXlj1lkPTTma2tajYWH6rfaLTngXKnPogig==
X-Received: by 2002:a4a:5549:: with SMTP id e70mr1172289oob.81.1634160947233; Wed, 13 Oct 2021 14:35:47 -0700 (PDT)
Received: from mail-ot1-f49.google.com (mail-ot1-f49.google.com. [209.85.210.49]) by smtp.gmail.com with ESMTPSA id c21sm182619oiy.18.2021.10.13.14.35.46 for <oauth@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 13 Oct 2021 14:35:46 -0700 (PDT)
Received: by mail-ot1-f49.google.com with SMTP id v2-20020a05683018c200b0054e3acddd91so5522292ote.8 for <oauth@ietf.org>; Wed, 13 Oct 2021 14:35:46 -0700 (PDT)
X-Received: by 2002:a9d:86e:: with SMTP id 101mr1397692oty.177.1634160946418; Wed, 13 Oct 2021 14:35:46 -0700 (PDT)
MIME-Version: 1.0
References: <SA2PR00MB100244DAAD267EBD2FF51678F5B79@SA2PR00MB1002.namprd00.prod.outlook.com> <CAJot-L1HNvud7-ehODK7Bouv5-KotMy8EtEgLCyCzOXoSZCVCg@mail.gmail.com> <CAGBSGjpJrM4uUTdVvsEzh5sT0H9ZpEJ0D3yfo-p_1S9w_tdF8g@mail.gmail.com> <AM7PR83MB0452A256F01A7DE8BE65C98C91B79@AM7PR83MB0452.EURPRD83.prod.outlook.com> <CAGBSGjoNoHybJNZaxdFs2Z9D+rUi+zORzt9v_f0cdhYZaj=KcA@mail.gmail.com> <CAJot-L30=scUs0yon4fx_Ti6Sq8gW4xy758j2qGLR_Cg2R-82Q@mail.gmail.com> <CAGBSGjoGhoz203+sXOGtDLr14DJLsRhjEd1uA==7SNLNRZdzpQ@mail.gmail.com> <CAP=vD9tOAxCAKumBcNkK077jMiWC+r7xBgu46oCFPgJPsu2EnQ@mail.gmail.com> <CAGBSGjpg63Rq2eEh3v3vAS=cuN3eNXAycbAOokaDg6v74saRHQ@mail.gmail.com> <CAP=vD9tKaSt2p_8_Ltcc7Ad5v5Yq6ST-tmf-VM6iKbXgZyP48A@mail.gmail.com> <AM7PR83MB04525DD2AE371CC6DE966CCB91B79@AM7PR83MB0452.EURPRD83.prod.outlook.com>
In-Reply-To: <AM7PR83MB04525DD2AE371CC6DE966CCB91B79@AM7PR83MB0452.EURPRD83.prod.outlook.com>
From: Aaron Parecki <aaron@parecki.com>
Date: Wed, 13 Oct 2021 14:35:34 -0700
X-Gmail-Original-Message-ID: <CAGBSGjoEOvB0FPXLhqnq5WzOmRd_JTDyj2E06kuqv=b9c7W=dA@mail.gmail.com>
Message-ID: <CAGBSGjoEOvB0FPXLhqnq5WzOmRd_JTDyj2E06kuqv=b9c7W=dA@mail.gmail.com>
To: Pieter Kasselman <pieter.kasselman@microsoft.com>
Cc: Sascha Preibisch <saschapreibisch@gmail.com>, IETF oauth WG <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b7981705ce42bed7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/17Hb01G1JKE3vT9OD0Kj6j2__E8>
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse and OAuth 2.1
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, 13 Oct 2021 21:35:56 -0000
Yes, as I said before, authorization servers are free to enforce one-time use of the authorization code even if there isn't a requirement to. The proposal is just to remove the *requirement* of authorization servers enforcing it. I am okay with Mike's suggestion of changing the language to "SHOULD" to continue to point out the possibility of enforcing one-time authorization codes if desired. On Wed, Oct 13, 2021 at 2:15 PM Pieter Kasselman < pieter.kasselman@microsoft.com> wrote: > Log files can exist in lots of place (clients, servers, data lakes). The > question is whether it is a valid assumption that an attacker cannot obtain > an Authorization Code and a Code Verifier and present it a second time > round. Limiting the validity period is one layer of defence, PKCE is > another layer, one time use enforcement is another. Assuming breach and > designing from a defence in depth perspective is a good practice, so why > not give implementors options (and guidance) to add additional layers of > defence to match their risk profiles? > > > > > > *From:* OAuth <oauth-bounces@ietf.org> *On Behalf Of *Sascha Preibisch > *Sent:* Wednesday 13 October 2021 22:06 > *To:* Aaron Parecki <aaron@parecki.com> > *Cc:* IETF oauth WG <oauth@ietf.org> > *Subject:* Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse and > OAuth 2.1 > > > > Ok, if the goal is to avoid unnecessary requirements I am suggesting to > point out why MUST was changed to SHOULD. Otherwise developers will start > to mix and match OAuth 2.0 and OAuth 2.1 requirements as they see them fit > their needs. > > In regards to encrypted values in PKCE, Aaron, I can also not confirm that > as the general implementation. > > > > On Wed, 13 Oct 2021 at 13:56, Aaron Parecki <aaron@parecki.com> wrote: > > The PKCE spec actually says "Typically, the "code_challenge" and > "code_challenge_method" values are stored in encrypted form in the "code" > itself" which I feel like might be a stretch to say that's typical, but > this scenario was clearly thought of ahead of time. Doing that would enable > an AS to avoid storing server-side state. > > > > On Wed, Oct 13, 2021 at 1:50 PM Sascha Preibisch < > saschapreibisch@gmail.com> wrote: > > If the challenge is based on distributed authorization server > configurations, how would they handle PKCE? I imagine that managing the > state for PKCE is not less challenging than managing authorization codes on > the server side, preventing reuse of them. > > With that in mind I am not sure if I follow the given argument. I would > prefer to keep MUST as it is today. > > > > > > On Wed, 13 Oct 2021 at 13:37, Aaron Parecki <aaron@parecki.com> wrote: > > HTTPS, because if that's broken then the rest of OAuth falls apart too. > > > > On Wed, Oct 13, 2021 at 1:36 PM Warren Parad <wparad@rhosys.ch> wrote: > > I feel like I'm missing something, what stops just plain old network > sniffing and replying the whole encrypted payload to the AS and getting > back a valid token? > > > *Warren Parad* > > Founder, CTO > > Secure your user data with IAM authorization as a service. Implement > Authress > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthress.io%2F&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C93c20c9c80354c77c10708d98e8d6776%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637697560293904430%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=vwcfj%2FVB8a84yDoAmqkXraWyqjOfWGrV08XdtZLWMXw%3D&reserved=0> > . > > > > > > On Wed, Oct 13, 2021 at 10:33 PM Aaron Parecki <aaron@parecki.com> wrote: > > Aside from the "plain" method, the PKCE code verifier never leaves the > client until it's sent along with the authorization code in the POST > request to the token endpoint. The only place it can leak at that point is > if the authorization server itself leaks it. If you have things leaking > from the authorization server log, you likely have much bigger problems > than authorization code replays. > > > > Keep in mind that even with the proposed change to drop the requirement of > authorization codes being one time use, authorization servers are free to > enforce this still if they want. Authorization code lifetimes are still > expected to be short lived as well. > > > > Aaron > > > > > > On Wed, Oct 13, 2021 at 1:25 PM Pieter Kasselman < > pieter.kasselman@microsoft.com> wrote: > > Aaron, I was curious what prevents an attacker from presenting an > Authorization Code and a PKCE Code Verifier for a second time if the one > time use requirement is removed. Is there another countermeasure in PKCE > that would prevent it? For example, an attacker may obtain the > Authorization Code and the Code Verifier from a log and replay it. > > > > Cheers > > > > Pieter > > > > *From:* OAuth <oauth-bounces@ietf.org> *On Behalf Of *Aaron Parecki > *Sent:* Wednesday 13 October 2021 18:40 > *To:* Warren Parad <wparad=40rhosys.ch@dmarc.ietf.org> > *Cc:* Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>; > oauth@ietf.org > *Subject:* [EXTERNAL] Re: [OAUTH-WG] Authorization code reuse and OAuth > 2.1 > > > > Warren, I didn't see you on the interim call, so you might be missing some > context. > > > > The issue that was discussed is that using PKCE already provides all the > security benefit that is gained by enforcing single-use authorization > codes. Therefore, requiring that they are single-use isn't necessary as it > doesn't provide any additional benefit. > > > > If anyone can think of a possible attack by allowing authorization codes > to be reused *even with a valid PKCE code verifier* then that would warrant > keeping this requirement. > > > > --- > > Aaron Parecki > > > > > > On Wed, Oct 13, 2021 at 10:27 AM Warren Parad <wparad= > 40rhosys.ch@dmarc.ietf.org> wrote: > > Isn't it better for it to be worded as we want it to be, with the > implication being that of course it might be difficult to do that, but that > AS devs will think long and hard about sometimes not denying the request? > Even with MUST, some AS will still allow reuse of auth codes. Isn't that > better than flat out saying: *sure, there's a valid reason* > > > > In other words, how do we think about RFCs? Do they exist to be followed > to the letter or not at all? Or do they exist to stipulate this is the way, > but acknowledge that not everyone will build a solution that holds them as > law. > > > > Let's look at *SHOULD* > > This word, or the adjective "RECOMMENDED", mean that there may exist valid > reasons in particular circumstances to ignore a particular item, but the > full implications must be understood and carefully weighed before choosing > a different course. > > > > I think *recommended* here is not sufficient nor are there valid reasons. > "It's too hard" isn't really a valid reason. Isn't it better in this case > for an AS to not be compliant with the RFC, than it is to relax this to > SHOULD and have lots of AS thinking reusing auth codes is a viable > solution, "because they are a special snowflake where SHOULD should apply". > > > > Are we setting the standard or instead attempting to sustain a number of > "AS that are in compliance with the RFC"? > > > > *Warren Parad* > > Founder, CTO > > Secure your user data with IAM authorization as a service. Implement > Authress > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthress.io%2F&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C93c20c9c80354c77c10708d98e8d6776%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637697560293914390%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9LtSUyb7WjZQqY%2FBnFy47HxchMNGZG6Qx82hj%2Bd9X04%3D&reserved=0> > . > > > > > > On Wed, Oct 13, 2021 at 7:17 PM Mike Jones <Michael.Jones= > 40microsoft.com@dmarc.ietf.org> wrote: > > During today’s call, it was asked whether we should drop the OAuth 2.0 > language that: > > The client MUST NOT use the authorization code > > more than once. If an authorization code is used more than > > once, the authorization server MUST deny the request and SHOULD > > revoke (when possible) all tokens previously issued based on > > that authorization code.” > > > > The rationale given was that enforcing one-time use is impractical in > distributed authorization server deployments. > > > > Thinking about this some more, at most, we should relax this to: > > The client MUST NOT use the authorization code > > more than once. If an authorization code is used more than > > once, the authorization server SHOULD deny the request and SHOULD > > revoke (when possible) all tokens previously issued based on > > that authorization code.” > > > > In short, it should remain illegal for the client to try to reuse the > authorization code. We can relax the MUST to SHOULD in the server > requirements in recognition of the difficulty of enforcing the MUST. > > > > Code reuse is part of some attack scenarios. We must not sanction it. > > > > -- Mike > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C93c20c9c80354c77c10708d98e8d6776%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637697560293914390%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gWX04yAEt3IP7lWFDS0zBzyJN8nvNfEf6Eq7i6qU7fM%3D&reserved=0> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C93c20c9c80354c77c10708d98e8d6776%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637697560293924344%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=yk%2FjfwfllrczSKVwzH4Bt7GTr9TV8fSda2oZhV0ejyA%3D&reserved=0> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C93c20c9c80354c77c10708d98e8d6776%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637697560293924344%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=yk%2FjfwfllrczSKVwzH4Bt7GTr9TV8fSda2oZhV0ejyA%3D&reserved=0> > >
- [OAUTH-WG] Authorization code reuse and OAuth 2.1 Mike Jones
- Re: [OAUTH-WG] Authorization code reuse and OAuth… Warren Parad
- Re: [OAUTH-WG] Authorization code reuse and OAuth… Aaron Parecki
- Re: [OAUTH-WG] Authorization code reuse and OAuth… Neil Madden
- Re: [OAUTH-WG] Authorization code reuse and OAuth… Warren Parad
- Re: [OAUTH-WG] Authorization code reuse and OAuth… Aaron Parecki
- Re: [OAUTH-WG] Authorization code reuse and OAuth… Jeff Craig
- Re: [OAUTH-WG] Authorization code reuse and OAuth… Warren Parad
- Re: [OAUTH-WG] Authorization code reuse and OAuth… David Waite
- Re: [OAUTH-WG] Authorization code reuse and OAuth… Richard Backman, Annabelle
- Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code … Pieter Kasselman
- Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code … Aaron Parecki
- Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code … Warren Parad
- Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code … Aaron Parecki
- Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code … Sascha Preibisch
- Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code … Warren Parad
- Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code … Aaron Parecki
- Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code … Sascha Preibisch
- Re: [OAUTH-WG] Authorization code reuse and OAuth… Richard Backman, Annabelle
- Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code … Pieter Kasselman
- Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code … Aaron Parecki
- Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code … Ash Narayanan
- Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code … Pieter Kasselman
- Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code … Warren Parad
- Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code … Pieter Kasselman
- Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code … Daniel Fett
- Re: [OAUTH-WG] Authorization code reuse and OAuth… Mike Jones
- Re: [OAUTH-WG] Authorization code reuse and OAuth… Richard Backman, Annabelle
- Re: [OAUTH-WG] Authorization code reuse and OAuth… Vittorio Bertocci
- Re: [OAUTH-WG] Authorization code reuse and OAuth… Mike Jones
- Re: [OAUTH-WG] Authorization code reuse and OAuth… Ash Narayanan
- Re: [OAUTH-WG] Authorization code reuse and OAuth… Vittorio Bertocci
- Re: [OAUTH-WG] Authorization code reuse and OAuth… David Waite
- Re: [OAUTH-WG] Authorization code reuse and OAuth… Neil Madden
- Re: [OAUTH-WG] Authorization code reuse and OAuth… Warren Parad
- Re: [OAUTH-WG] Authorization code reuse and OAuth… Filip Skokan
- Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code … Takahiko Kawasaki
- Re: [OAUTH-WG] Authorization code reuse and OAuth… Daniel Fett
- Re: [OAUTH-WG] Authorization code reuse and OAuth… Daniel Fett
- Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code … Warren Parad
- [OAUTH-WG] SUB and AUD configuration for web iden… Warren Parad
- Re: [OAUTH-WG] SUB and AUD configuration for web … Ash Narayanan