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

[Denis <[e-mail]>]

This is a follow-up of the OAuth workshop held in Zurich on July 13 th.

At the end of the first day, Sven Hammann made a presentation on the 
following topic:
"A private mode for OpenID Connect"

Slide 14 indicated the motivation of the presentation :

The IdP learns at which Relying Parties (RPs) the user logs in

This does not respect the user's privacy

User's activities over multiple RPs can be tracked

User might not want anyone to know which service they are using

Especially if using the RP might provide sensitive information

I Alcoholics Anonymous

I Medical Forums

Slide 22 indicated:

Privacy and Security Goals

Privacy towards IdP: IdP cannot distinguish between logins to different RPs.

Slides 33 indicated the problem to be solved (hence the title of this 
email):

How can the IdP create an id token for one audience RP without knowing 
for which RP?


In the previous presentation from John Bradley and Torsten Lodderstedt 
(Access token phishing),
made on the same day, the same problem was considered with the final 
slide asking: " What do you think ? "

I believe that it is the time to agree on a solution for this problem.

As I already said on the WG list, the audience parameter does not allow 
to respect privacy.
However, there are cases where both an access token MUST be targeted and 
privacy MUST be supported.

Draft "JSON Web Token Best Current Practices" recently became 
draft-ietf-oauth-jwt-bcp-00.
One major problem (with respect to privacy) is that it mandates the use 
of the audience parameter:

3.8.Use and Validate Audience

If the same issuer can issue JWTs that are intended for use by more than 
one relying party or application,
the JWT MUST contain an "aud"(audience) claim that can be used to 
determine whether the JWT is being
used by an intended party or was substituted by an attacker at an 
unintended party.

With such a wording, as soon as the "aud" claim will be used, privacy 
will be violated since the AS will be able
to act as Big Brother.

Similarly, in a token request the use of the OPTIONAL resource parameter 
is also violating privacy : it indicates
the physical location of the target service or resource where the client 
intends to use the requested security token.
The value of the "resource" parameter MUST be an absolute URI, as 
specified by Section 4.3 of [RFC3986],

During the workshop, it has been proposed to use some signature on some 
data placed /outside/ the access token.

I propose a different approach where both a new parameter placed 
*inside* the access token will be used and
a new structure placed *outside* the access token will be used. This means :

-the addition of a tid (target identifier) parameter *inside* the access 
token, and

-the definition of a new data structure placed *outside* the access 
token (which does not require the computation
  of a digital signature and does not require the demonstration of a 
proof of possession of a key).

Once the basic principles have been explained, let us now explain how 
the mechanism would work.

The client chooses the URI of the target service. For every access token 
request (and for every target service, see later on
the case of multiple targets), it generates a random number (rdn). It 
then computes tid = OWHF (rdn, URI) where the rdn
comes first and where the URI comes after. OWHF is a One Way Hash Function.

The client communicates to the Authorisation Server a method which 
includes two parameters: the OID of the OWHF to be used
(e.g. SHA 256) and the value of tid that it has computed. The AS blindly 
copies and pastes this information into the access token.

The client communicates to the Target Server (outside the access token): 
the method, the OID of the OWHF, the value of the rdn
and the value for the URI.

The Target Server first verifies that the data structure placed 
*outside* the access token matches with the data placed *inside*
the access token: same method and same OID for the OWHF. Then after, it 
verifies that the URI (placed *outside* the access token)
matches with one of the expected values and then using the method, the 
designated OID of the OWHF, the received rdn and
the received URI computes OWHF (rdn, URI). It finally verifies that the 
result of this computation is identical to the tid parameter
contained in the access token. If the verification is successful, the 
access token is accepted by the Target Server, otherwise it is rejected.

Note that an access token MAY include several target identifiers. This 
should be used with care since such an access token might be usable
by one designated Target Server towards another designated Target 
Server. However, there are circumstances where this is a desirable feature.
As indicated earlier, each target identifier (tid) is computed using a 
different rdn.

Comments ?

Denis