I would like to clarify and agree with John Bradley that there is a confusion
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
- 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
From: OAuth [oauth-boun...@ietf.org] on behalf of Torsten Lodderstedt
Sent: Thursday, August 03, 2017 1:51 PM
To: John Bradley
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.
OAuth mailing list