Re: [OAUTH-WG] Murray Kucherawy's No Objection on draft-ietf-oauth-step-up-authn-challenge-14: (with COMMENT)

"Murray S. Kucherawy" <superuser@gmail.com> Thu, 13 April 2023 06:25 UTC

Return-Path: <superuser@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 54631C15AE03; Wed, 12 Apr 2023 23:25:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtjXb3KeC_A8; Wed, 12 Apr 2023 23:25:34 -0700 (PDT)
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1504C159495; Wed, 12 Apr 2023 23:25:34 -0700 (PDT)
Received: by mail-ej1-x631.google.com with SMTP id si1so4534071ejb.10; Wed, 12 Apr 2023 23:25:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681367133; x=1683959133; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=8B9FEP4SqxLYQSW9mRzp+8hSXWpsuPBr0juCHRMY/ik=; b=Y0Pm00bZQBCLdrP7J3x6TdqPxMzHzOYjndSjr2QODXKITSGtK8Px3ZUZR9Np8PDtUx /qsySn5H3qo9tloJ07J7EGB3ZLqNxajBUGllKotxJscTi78Uskak5v2I2HEk0OiEtXtO itRBmHi+h5Mmxz/oyHzx4ud+qN/g+5XrNa3PLWo6KAN2jYrnUWTa611ohqlIgS+QSLPj cHf57prQ9CQ4fnWqrOvr7Ro316DmxShVZM8mDFMLAQxWbcblhWk+5l5zDcI0HS4wgU5p oNdFMatHXruApAUDGXOkvbwb4Lzmlex/QKYgBdZTC1+rYjMGRwN71Zait3D8m+DcJcRN bRoQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681367133; x=1683959133; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=8B9FEP4SqxLYQSW9mRzp+8hSXWpsuPBr0juCHRMY/ik=; b=b2Ml2CSNCEKGM4NJYKq4Alwu0GX1v9MAzOU0tLiKZv4OJ8vU+ZWiWT7vfuyunJ3iUs SxJ8ZafpksKR77NunQvnnCQcsEtf/rOTXjkzvJwBpbc7NuOk8DdtjEm8KPaNjgkCRhWA ymblzVWsvQ0KhicTYae+bApwaMaqb25jxtnpuCqoFeGnCGioEp2+Rje8UNHI/JbLRdQS hn+DZ1BNrrPWfTORr7yZPhRK4rTn3POfaAr334YitP5EvDORLcGWsDmtbdVD0xhw8owZ L2NCMdQNpxCw/EcQNAy9XHydnwjZ5KDxweERENUx0PDS7dePVcibZd0o8QO4iFRGrKeW FwlQ==
X-Gm-Message-State: AAQBX9eap67U6gwJDsGeY5//5iDIDf2YZuRxRCf0RQwufsZYd5WnZtg0 h7EAQtvKyCqDknS3UG1PBcebHYjGjw3f8aV9X58=
X-Google-Smtp-Source: AKy350ZeGGJZQKUT4AH3FnaaVPC1Po1fgqdV7DvZAXCSmJ9Kx+OoPcNuhpsBTCseHO64N9C61PAp+Vi8d4poWY97nVY=
X-Received: by 2002:a17:906:d044:b0:94e:140f:e4b7 with SMTP id bo4-20020a170906d04400b0094e140fe4b7mr689112ejb.11.1681367132607; Wed, 12 Apr 2023 23:25:32 -0700 (PDT)
MIME-Version: 1.0
References: <168136196076.46946.14361049726064538738@ietfa.amsl.com> <CAEFJvao7pTNFdR3hAx1N2yFioWF9Zux4cNk0+uKd3NAuPVhoag@mail.gmail.com>
In-Reply-To: <CAEFJvao7pTNFdR3hAx1N2yFioWF9Zux4cNk0+uKd3NAuPVhoag@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
Date: Wed, 12 Apr 2023 23:25:20 -0700
Message-ID: <CAL0qLwYwJjN3ZFmomgxfwAt7GftzmHUsrogEPqz07WBAUs=P1w@mail.gmail.com>
To: Vittorio Bertocci <vittorio.bertocci@okta.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-oauth-step-up-authn-challenge@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org, rifaat.s.ietf@gmail.com
Content-Type: multipart/alternative; boundary="000000000000ad19f605f931ca8e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/8RRC2ZsxkVFmL7T2YRmO8GvbRjU>
Subject: Re: [OAUTH-WG] Murray Kucherawy's No Objection on draft-ietf-oauth-step-up-authn-challenge-14: (with COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.39
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, 13 Apr 2023 06:25:35 -0000

Hi Vittorio, thanks for the quick response.

On Wed, Apr 12, 2023 at 11:11 PM Vittorio Bertocci <
vittorio.bertocci@okta.com> wrote:

> On the SHOULD on top of S4. There are pretty common situations in which
> failing to get a response from an API is an acceptable outcome, and
> presenting an interactive prompt isn't. A classic example is a background
> update that the client can use to proactively fetch fresh data, that isn't
> critical for the application function and wasn't initiated by the user. As
> such, an interactive prompt could disrupt the user experience by requiring
> an action without clear context and not in pursuit of a goal the user
> expressed. A MUST would force a complying client to act on the challenge,
> making those scenarios hard to handle.
>
> On the SHOULD on top of S5. There we are just describing what the OIDC
> specification mandates for ID tokens, hence not providing any new normative
> guidance.We echo what OIDC mandates for ID tokens there because we want to
> apply the same logic for access tokens, as we later describe in the same
> section. In that description we don't introduce a more restrictive MUST
> because that would make it hard for the (many) existing authorization
> server+OIDC implementations to comply, limiting adoption and for a
> relatively small return.
>

I think it would be good to say something like what you just said for the
first one, and maybe make it clear that you're relaying normative guidance
from OIDC and not making a new assertion.  Or you could just say
implementers need to meet the constraints around ID tokens specified by
OIDC.

-MSK