Re: [OAUTH-WG] How could an IdP create an id token for one audience RP without knowing for which RP ?
"Hammann Sven" <firstname.lastname@example.org> Tue, 08 August 2017 08:15 UTC
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1261320CC for <email@example.com>; Tue, 8 Aug 2017 01:15:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([22.214.171.124]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ve6AjDXN1Mv for <firstname.lastname@example.org>; Tue, 8 Aug 2017 01:15:16 -0700 (PDT)
Received: from edge10.ethz.ch (edge10.ethz.ch [126.96.36.199]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5699A1320BE for <email@example.com>; Tue, 8 Aug 2017 01:15:14 -0700 (PDT)
Received: from CAS10.d.ethz.ch (172.31.38.210) by edge10.ethz.ch (188.8.131.52) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 8 Aug 2017 10:15:09 +0200
Received: from MBX116.d.ethz.ch ([fe80::7118:3565:54c4:260e]) by CAS10.d.ethz.ch ([fe80::cce:fc66:7b56:a06a%10]) with mapi id 14.03.0361.001; Tue, 8 Aug 2017 10:15:11 +0200
From: "Hammann Sven" <firstname.lastname@example.org>
To: Torsten Lodderstedt <email@example.com>, John Bradley <firstname.lastname@example.org>
CC: oauth <email@example.com>
Thread-Topic: [OAUTH-WG] How could an IdP create an id token for one audience RP without knowing for which RP ?
Date: Tue, 8 Aug 2017 08:15:10 +0000
References: <firstname.lastname@example.org> <46E8AB48-2DD1-4C1C-B8FA-0FBADAB7596F@ve7jtb.com>, <1321FC7E-EA45-4181-BC8F-90086FCA7180@lodderstedt.net>
Accept-Language: en-US, de-CH
Content-Type: multipart/alternative; boundary="_000_29A97C2C05BF2C448F6970FFCAEA85C0022E199BMBX116dethzch_"
Subject: Re: [OAUTH-WG] How could an IdP create an id token for one audience RP without knowing for which RP ?
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:email@example.com?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:firstname.lastname@example.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Aug 2017 08:15:18 -0000
Dear all, I would like to clarify and agree with John Bradley that there is a confusion here. In the setting that I was discussing in my presentation, I was looking at OpenID Connect, where we have: An end-user with his user agent (browser) that wishes to log in at an RP service (and this is what is called client here), using an IdP (or also called OpenID Provider / OP). My concern was about the privacy of the end-user towards the IdP. In the current standard, the client_id identifying the RP is sent to the IdP (and put into the "aud" field of the id_token), so the IdP learns at which RP the end-user wishes to log in with the id_token. --- Denis is describing an OAuth setting with an RP (client) that obtains an access token from an AS (Authorization Server), and wishes to use this at one of several resource servers (RS). His concern is about the privacy of the RP (client) towards the AS, since with an "aud" field in the access token, the AS learns at which RS the RP (client) wishes to use the access token. ==> These are two different scenarios, and separate privacy concerns. I understand from John Bradley's comments and Torsten's +1 that you are doubtful if the second scenario raised by Denis is an actual privacy concern. Thus, I would like to keep these two scenarios separate. There are outstanding issues with my solution to the first scenario, two of which are: - If we cannot have pairwise subject identifiers when masking the client_id (RP identifier), we would have a privacy trade-off here - Requesting different scopes (attributes) could potentially allow the IdP to identify the RP based on these requests If there is still interest in solving the first scenario (IdP does not learn RP's identity in OIDC), I may be able to come up with some ideas to solve these outstanding problems. Kind Regards, Sven ________________________________ From: OAuth [email@example.com] on behalf of Torsten Lodderstedt [firstname.lastname@example.org] Sent: Thursday, August 03, 2017 1:51 PM To: John Bradley Cc: oauth Subject: Re: [OAUTH-WG] How could an IdP create an id token for one audience RP without knowing for which RP ? +1 Am 31.07.2017 um 16:01 schrieb John Bradley <email@example.com<mailto:firstname.lastname@example.org>>: For access tokens I would like to see a use case for a completely = decoupled and anonymous RS that is not just a misuse of OAuth for = Authentication, before trying to add a feature like this.
- [OAUTH-WG] How could an IdP create an id token ... Denis
- Re: [OAUTH-WG] How could an IdP create an id to... John Bradley
- Re: [OAUTH-WG] How could an IdP create an id to... Torsten Lodderstedt
- Re: [OAUTH-WG] How could an IdP create an id to... Hammann Sven