Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56DFDC14F5E2 for ; Wed, 4 Dec 2024 15:03:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=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=e43.eu header.b="QeCO5kIB"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="yDEZp+4a" 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 K7US6Z7g1_Gt for ; Wed, 4 Dec 2024 15:03:30 -0800 (PST) Received: from fout-b8-smtp.messagingengine.com (fout-b8-smtp.messagingengine.com [202.12.124.151]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABB80C1519A4 for ; Wed, 4 Dec 2024 15:03:30 -0800 (PST) Received: from phl-compute-09.internal (phl-compute-09.phl.internal [10.202.2.49]) by mailfout.stl.internal (Postfix) with ESMTP id 88A2311401C3; Wed, 4 Dec 2024 18:03:29 -0500 (EST) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-09.internal (MEProxy); Wed, 04 Dec 2024 18:03:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=e43.eu; h=cc:cc :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1733353409; x=1733439809; bh=NqdHOo+UAn rws+ybEM78Q9Lo5G867U6w6pG/aA4oa6o=; b=QeCO5kIBJcQOZ+4CAvmLndBp9x 12At3voEj/ltUuzXiaw59m2lvGcEZautpXQMlQjlucBijEMwwYb/XiGvFJ/52Zzn RMok8FDYnAttEnZliqiDm9CxSL4/eTOi0x6YyqHmusO5wUvibxQRtSTRnUb3K7h7 Rmzfbi0WFb5Qn0jZ4SQ5NsgqpOheGrINrEzofXNH7FyPnUSbxYsfXH3CQFHhlVxo Y6QD95nQg/sEaBBE4nN9qYotRXMXWxx/YgJlbHGeACG/N1YvinWYPvuiCQwi2TyY h+J/LGErqUrUOMq5dxu1xy6N2aJ+7d0cqlWnqqbeL9K/ePPF1sSsvrgjbUOA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1733353409; x=1733439809; bh=NqdHOo+UAnrws+ybEM78Q9Lo5G867U6w6pG /aA4oa6o=; b=yDEZp+4ajTLYplV7tns1Pj5C8Pg7/wdzrcuyBzsAGI4Vx5dRN1O ef2bLVYi9G4SMMLRMP/xDE10R0Thsa2YWhzIn/1FG3FTnyvoT1RoW8k7ptRBPmQL 9r60q8yMVOKI9xefqkrQS1IGtiCLcBgs3A3FbpMcQnsT8UD0WbNt8vIG3OpsKaJN LPQqJAdqLh8p1fuQGmrZfYlrSR3v0NU9nPLXst4UZ7nZb55bknIYfIII4gLUXWwg +Gxcc1Zc9Y1pEnnzWZik8lyIUjT8XeGf333ftHAYxqAmficbVVUDWnT5Ikb2lEZx QZ3gNO+X3Dgowl8D8lgVIOjg85k0IDu1i8A== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrieeigddtfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdpuffr tefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnth hsucdlqddutddtmdenucfjughrpefhkfgtggfuffgjvefvfhfosegrtdhmrehhtdejnecu hfhrohhmpefgrhhinhcuufhhvghphhgvrhguuceovghrihhnrdhshhgvphhhvghrugesvg egfedrvghuqeenucggtffrrghtthgvrhhnpeffleetleefvdffhfduudetuddvtefhieev ueffffegleelvdefjeeuffeuleehfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrh grmhepmhgrihhlfhhrohhmpegvrhhinhdrshhhvghphhgvrhgusegvgeefrdgvuhdpnhgs pghrtghpthhtohepvddpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepjhhrihgthh gvrhesmhhithdrvgguuhdprhgtphhtthhopehtgigruhhthhesihgvthhfrdhorhhg X-ME-Proxy: Feedback-ID: i313944f9:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 4 Dec 2024 18:03:28 -0500 (EST) From: Erin Shepherd Message-Id: <30378CFC-BE72-4F74-A4C7-B97A717BB7F3@e43.eu> Content-Type: multipart/alternative; boundary="Apple-Mail=_9707A562-475D-4B54-B28C-9D2D97EA58F2" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\)) Date: Thu, 5 Dec 2024 00:03:15 +0100 In-Reply-To: <29E364E8-5012-4F08-90A2-9E772886FDFE@mit.edu> To: Justin Richer References: <2FE68756-A13B-4CB4-9318-26A007F261D2@e43.eu> <690FE634-5657-4394-AFFB-8CB4A9C3CA5D@e43.eu> <29E364E8-5012-4F08-90A2-9E772886FDFE@mit.edu> X-Mailer: Apple Mail (2.3774.500.171.1.1) Message-ID-Hash: XNLBMUBSNPOH5SOCKRAD5A6LT3CCD7O7 X-Message-ID-Hash: XNLBMUBSNPOH5SOCKRAD5A6LT3CCD7O7 X-MailFrom: erin.shepherd@e43.eu X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: "txauth@ietf.org" X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BGNAP=5D_Re=3A_GNAP_RS-AS_interaction_questions?= List-Id: GNAP Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --Apple-Mail=_9707A562-475D-4B54-B28C-9D2D97EA58F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 4 Dec 2024, at 22:39, Justin Richer wrote: >=20 >=20 >=20 >> On Dec 4, 2024, at 10:18=E2=80=AFPM, Erin Shepherd = wrote: >>=20 >>=20 >> I understand the goal, but I=E2=80=99m a bit concerned about the = implications in heterogeneous environments. If a GNAP client asks for an = ID token, what sub/iss combo do I put in there? How does it even know = how to validate the ID token? >>=20 >> (I guess it actually doesn=E2=80=99t really need to validate it = because it was received over a secured channel, unlike front-channel ID = tokens in OIDC, but the thought remains) >>=20 >> One of the things I=E2=80=99m concerned about is - lets say we = consider an RS+RP that speaks GNAP, receives OIDC ID tokens from the AS, = and handles user provisioning/synchronization with SCIM - how do we = ensure consistent identity mapping across all of these? >>=20 >=20 > ID tokens are not access tokens - so the access token format listed in = the GNAP RS document doesn=E2=80=99t apply. They=E2=80=99re assertions = defined by OIDC core and would have the OIDC issuer claim in them. So a = GNAP client would get an ID token as part of the subject information and = validate it just like it would for core OIDC =E2=80=94 the 'iss' claim = would be different but that=E2=80=99s not really a problem here. One difference here is that for OIDC Core you have an established client = relationship with the OIDC issuer. For GNAP you have a relationship with = the GNAP issuer. Now, if the two are related (or colluding) that=E2=80=99s= effectively one and the same thing, but how can the application know = this? > An RS+RP would be an odd combination, since the RP maps to the client = in the OAuth/GNAP model. What=E2=80=99s the use case for this type of = application where it would have multiple different roles simultaneously? = And in such a case, wouldn=E2=80=99t it be important to distinguish = between an ID token assertion and an access token, anyway? You = wouldn=E2=80=99t want them to behave the same way or get confused with = each other. I actually think that an RS also being an RP is the most common case - = but primarily they do so for authenticating a user to themselves. = Consider a mail service - it=E2=80=99s an RS when someone wishes to = access it over JMAP/IMAP/etc, and an RP when it=E2=80=99s offering = webmail (or a configuration UI, or..) Anyway yes it=E2=80=99s very important to distinguish between an ID = token assertion and an access token assertion - but when you deal with = both of them you need to be able to correlate users across them. If = I=E2=80=99m an RS+RP client to an OIDC AS, I=E2=80=99m basically = guaranteed to get the same iss+sub combination in both the access tokens = I receive from other RPs when behaving as an RS, and in the ID tokens I = receive when behaving as an RP. (RFC 9068 doesn=E2=80=99t explicitly = state this, but it is the only logical option in most situations, and = cases where the AS has decided to do otherwise are probably intentional) I=E2=80=99m not quite clear on how I=E2=80=99d do that with GNAP. - Erin= --Apple-Mail=_9707A562-475D-4B54-B28C-9D2D97EA58F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 4 Dec 2024, at 22:39, Justin Richer = <jricher@mit.edu> wrote:



On Dec 4, 2024, at 10:18=E2=80=AFPM, Erin = Shepherd <erin.shepherd@e43.eu> wrote:


I = understand the goal, but I=E2=80=99m a bit concerned about the = implications in heterogeneous environments. If a GNAP client asks for an = ID token, what sub/iss combo do I put in there? How does it even know = how to validate the ID token?

(I = guess it actually doesn=E2=80=99t really need to validate it because it = was received over a secured channel, unlike front-channel ID tokens in = OIDC, but the thought remains)

One of = the things I=E2=80=99m concerned about is - lets say we consider an = RS+RP that speaks GNAP, receives OIDC ID tokens from the AS, and handles = user provisioning/synchronization with SCIM - how do we ensure = consistent identity mapping across all of these?


ID tokens are not access tokens - so the access = token format listed in the GNAP RS document doesn=E2=80=99t apply. = They=E2=80=99re assertions defined by OIDC core and would have the OIDC = issuer claim in them. So a GNAP client would get an ID token as part of = the subject information and validate it just like it would for core OIDC = =E2=80=94 the 'iss' claim would be different but that=E2=80=99s not = really a problem here.

One = difference here is that for OIDC Core you have an established client = relationship with the OIDC issuer. For GNAP you have a relationship with = the GNAP issuer. Now, if the two are related (or colluding) that=E2=80=99s= effectively one and the same thing, but how can the application know = this?

An RS+RP would be an odd combination, since the = RP maps to the client in the OAuth/GNAP model. What=E2=80=99s the use = case for this type of application where it would have multiple different = roles simultaneously? And in such a case, wouldn=E2=80=99t it be = important to distinguish between an ID token assertion and an access = token, anyway? You wouldn=E2=80=99t want them to behave the same way or = get confused with each = other.

I actually think that = an RS also being an RP is the most common case - but primarily they do = so for authenticating a user to themselves. Consider a mail service - = it=E2=80=99s an RS when someone wishes to access it over JMAP/IMAP/etc, = and an RP when it=E2=80=99s offering webmail (or a configuration UI, = or..)

Anyway yes it=E2=80=99s very important to = distinguish between an ID token assertion and an access token assertion = - but when you deal with both of them you need to be able to correlate = users across them. If I=E2=80=99m an RS+RP client to an OIDC AS, I=E2=80=99= m basically guaranteed to get the same iss+sub combination in both the = access tokens I receive from other RPs when behaving as an RS, and in = the ID tokens I receive when behaving as an RP.  (RFC 9068 = doesn=E2=80=99t explicitly state this, but it is the only logical option = in most situations, and cases where the AS has decided to do otherwise = are probably intentional)

I=E2=80=99m not quite = clear on how I=E2=80=99d do that with GNAP.

- = Erin
= --Apple-Mail=_9707A562-475D-4B54-B28C-9D2D97EA58F2--