Re: [OAUTH-WG] Call for Adoption - AS Issuer Identifier in Authorization Response

Warren Parad <> Tue, 08 December 2020 19:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 22BC43A10F9 for <>; Tue, 8 Dec 2020 11:15:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.087
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, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=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 Lmq-cpSYgEGS for <>; Tue, 8 Dec 2020 11:15:49 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::d29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 68CE93A10FE for <>; Tue, 8 Dec 2020 11:15:49 -0800 (PST)
Received: by with SMTP id r9so17987041ioo.7 for <>; Tue, 08 Dec 2020 11:15:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=G+H0HpDl9wiwG2/Hnut7r83Q0jTNKnlzfIc8lAS9p4M=; b=mwncC7uoXhard9vxAApTlfqCQbU65jfrKMWYr6nxyl5zF0kqNrWeumzo8BG5GQU3n3 fPyhLSpq+JeV6LH3ULAaDn6Qv4FwAHuw8HNwN2d2LEX0pAonJaYeCIC7gVeQK42gSghE J2GcOWKfRgfa4aAnfh+KBiuI7TON5zCqM4Bjo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=G+H0HpDl9wiwG2/Hnut7r83Q0jTNKnlzfIc8lAS9p4M=; b=NnJe0mvbjBprXoIum1rZRfTeCMY3l7Z0rMEJkbhxshk3HgTJf/YLF1IddKS8OIyVMc c1+n8jkMaV3xVHQj/ehCDZX1gfQQDR0jiY/Q25y7515qXmHQa6FKr5WdVrrWCCdbfToV L83U6raEZRao56IAFqFUW58M9H97DLjTqd37DVH8BA4DqBdSwFDHbHA22kQi4AjI8ZS2 XUudSn60QBmgJyUiKuKIJ++2oe3PKlFZghrL6ttBrIKt6SDOHd7j08aDSSGk8tSBnGEh /xA2jLz1H8KLxOk1nfI9vgyZsOP9q5TW1gehGjovVdS/QGdggDyChbRnAPMUWrQ7YUnv oQ7Q==
X-Gm-Message-State: AOAM531GItD/2+wg+goijkp92psaezNarCzalwwNEbr7SpckPCmFwgX2 MoGo9PASOqYz2JXAi0+MR+EZx8fPYdb50Jw/16L6
X-Google-Smtp-Source: ABdhPJyg6xeq/TlvEbuwTJr6pZXxYZ+wwVwtN7Ha80RanbIcw/lT4/1rd6PZyCOuPoUhDNvKXIpNN0uBpwG//6Aznf8=
X-Received: by 2002:a5e:db4b:: with SMTP id r11mr25320718iop.148.1607454948281; Tue, 08 Dec 2020 11:15:48 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Warren Parad <>
Date: Tue, 08 Dec 2020 20:15:37 +0100
Message-ID: <>
Cc: Rifaat Shekh-Yusef <>, oauth <>
Content-Type: multipart/alternative; boundary="0000000000002f68e005b5f8c50f"
Archived-At: <>
Subject: Re: [OAUTH-WG] Call for Adoption - AS Issuer Identifier in Authorization Response
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 08 Dec 2020 19:15:51 -0000

As an implementer on both sides of the issue I'm struggling to understand
how this problem would occur. I'm finding issues with the proposed problems:

   1. Honest AS is compromised, assuming this does happen details on why
   adding iss to the AS response would prevent attacks is necessary for me. In
   other words, how would an AS be compromised in a way that would be
   identifiable through the issuer value? (my ignorant assumption is that a
   compromised AS is compromised enough that an attacker would be able to send
   the correct ISS)
   2. Attacker AS is registered. I fully support the idea that this can and
   will happen, however from attempting to test-implement this proposal, I
   can't see how the authorization would be sent to the wrong token endpoint.
   Since there is no information in the AS auth code response, the client must
   already have the knowledge of where they are going to send the token, no
   mix-up can be executed. I would argue, if anything, adding the ISS
   parameter would open a new attack surface by providing clients an
   opportunity to blatantly trust the ISS parameter as the honest AS and thus
   actually sending the code there instead of sending it to one specified in
   the metadata document.

My confusion is the following:

   - Are multi AS services utilizing authorization codes in a way where
   there could be a mix up attack for #2.
   - Is there a #3 that I'm missing which even in light of #1 & #2 I
   brought up that would still make this change valuable?

Warren Parad

Founder, CTO
Secure your user data and complete your authorization architecture.
Implement Authress <>.

On Tue, Dec 8, 2020 at 8:01 PM Dick Hardt <> wrote:

> +1
> ᐧ
> On Tue, Dec 8, 2020 at 4:51 AM Rifaat Shekh-Yusef <>
> wrote:
>> All,
>> This is a call for adoption for the following AS Issuer Identifier in
>> Authorization Response as a WG document:
>> Please, provide your feedback on the mailing list by Dec 22nd.
>> Regards,
>>  Rifaat & Hannes
>> _______________________________________________
>> OAuth mailing list
> _______________________________________________
> OAuth mailing list