[OAUTH-WG] Re: RFC 9470 on OAuth 2.0 Step Up Authentication Challenge Protocol

"Giner Stéphane (PJ)" <stephane.giner@justice.ge.ch> Thu, 27 June 2024 07:50 UTC

Return-Path: <stephane.giner@justice.ge.ch>
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 4B9CBC14F696 for <oauth@ietfa.amsl.com>; Thu, 27 Jun 2024 00:50:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.005
X-Spam-Level:
X-Spam-Status: No, score=-7.005 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=justice.ge.ch
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 dMG4tAEsW9Ko for <oauth@ietfa.amsl.com>; Thu, 27 Jun 2024 00:50:25 -0700 (PDT)
Received: from gwsmtp.ge.ch (gwsmtp.ge.ch [160.53.250.30]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 8B26AC14F6BE for <oauth@ietf.org>; Thu, 27 Jun 2024 00:50:24 -0700 (PDT)
From: "Giner Stéphane (PJ)" <stephane.giner@justice.ge.ch>
To: "oauth@ietf.org" <oauth@ietf.org>
Thread-Index: AdrIZGXfuz7bkUSKTgm7HDxQzTkxmA==
Date: Thu, 27 Jun 2024 07:50:21 +0000
Message-ID: <5bf73e920e6943578f6089dece7b5dcc@justice.ge.ch>
Accept-Language: fr-CH, en-US
Content-Language: fr-FR
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
Content-Type: multipart/related; boundary="_004_5bf73e920e6943578f6089dece7b5dccjusticegech_"; type="multipart/alternative"
MIME-Version: 1.0
X-FE-Attachment-Name: image002.png
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=justice.ge.ch; s=GVA21; c=relaxed/relaxed; h=from:to:subject:date:message-id:content-type:mime-version; bh=EEOU2ySQmxE1XG69ljsy4YsCILYEiyTglDDusPryv1c=; b=PyAdr2DIYhNMobO27ow1qkjDZLHTRal7J8AMjTBSgueRx69V7TVJOylaRcienWxVSwDrtPTZSzBp ydgxbdffkCtkneDpUCC9ZKk2knaQgkb3lXA4/3BYq8oHLbbv4Eb91O2zjzP8QWxsxi6kD5nQ17G3 hN8v6J0eSVK/u0PDGtcrtWky3/CGYcUiMqzpCZOLrgxgcV24OG8qF8wWcm5FDMDcaa8i33dCqU5P QjdB/IqL0mcvBMbTbod5sRj86ODYhWt6jOgxAVGz8E+1aIaokVo2KoiFvR50g1Zq0uiiYO9AxloU pPVeOMd/+h4XYj05f75BUaBEb0KBUoahQoF6eQ==
X-MailFrom: stephane.giner@justice.ge.ch
X-Mailman-Rule-Hits: nonmember-moderation
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-oauth.ietf.org-0
Message-ID-Hash: JEM66KGIR52IY5BFE4HO7ZFDULGGHSYH
X-Message-ID-Hash: JEM66KGIR52IY5BFE4HO7ZFDULGGHSYH
X-Mailman-Approved-At: Thu, 27 Jun 2024 05:01:31 -0700
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [OAUTH-WG] Re: RFC 9470 on OAuth 2.0 Step Up Authentication Challenge Protocol
List-Id: OAUTH WG <oauth.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/liBXmV5SaZ1VdT4TFNWql232ko8>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Owner: <mailto:oauth-owner@ietf.org>
List-Post: <mailto:oauth@ietf.org>
List-Subscribe: <mailto:oauth-join@ietf.org>
List-Unsubscribe: <mailto:oauth-leave@ietf.org>

Hello

I read your document and I just want to say that I already manage ACR with multiple clientId to protect encapsulated domains.

For example for an ecommerce site I got a global clientId to allow user to connect to the site and specific clientId to protect user information like address or bank account.

[cid:image002.png@01DAC877.6C1F6070]

When the client want to access to the protected user information, it will be redirected to the specific clientId, and the authorization server will provide a new authentication with, if necessary, a second factor. Client can also, if it know that it must provide a specific token for this domain, request this specific token with a token exchange request.

Don't hesitate to tell me if I'm wrong and explain you point of view between multiple clientId (for multiple domains) and ACR

Regards

Stéphane GINER