Re: [OAUTH-WG] How could an IdP create an id token for one audience RP without knowing for which RP ?

"Hammann Sven" <> Tue, 08 August 2017 08:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4D1261320CC for <>; Tue, 8 Aug 2017 01:15:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.198
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3ve6AjDXN1Mv for <>; Tue, 8 Aug 2017 01:15:16 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5699A1320BE for <>; Tue, 8 Aug 2017 01:15:14 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 8 Aug 2017 10:15:09 +0200
Received: from ([fe80::7118:3565:54c4:260e]) by ([fe80::cce:fc66:7b56:a06a%10]) with mapi id 14.03.0361.001; Tue, 8 Aug 2017 10:15:11 +0200
From: Hammann Sven <>
To: Torsten Lodderstedt <>, John Bradley <>
CC: oauth <>
Thread-Topic: [OAUTH-WG] How could an IdP create an id token for one audience RP without knowing for which RP ?
Thread-Index: AQHTCc6UbmrJK1IDo0eFm7woIaTdJ6Jt1cKAgASSvYCAB8CHAw==
Date: Tue, 08 Aug 2017 08:15:10 +0000
Message-ID: <>
References: <> <>, <>
In-Reply-To: <>
Accept-Language: en-US, de-CH
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_29A97C2C05BF2C448F6970FFCAEA85C0022E199BMBX116dethzch_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [OAUTH-WG] How could an IdP create an id token for one audience RP without knowing for which RP ?
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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,


From: OAuth [] on behalf of Torsten Lodderstedt []
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 ?

Am 31.07.2017 um 16:01 schrieb John Bradley <<>>:

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.