Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

[Denis <[e-mail]>]

I have three concerns, two of them being related to privacy.

1) Privacy has not really been a concern in the WG since originally the 
AT and the RS were co-located. However, this draft now recognizes
that there may exist cases where "the authorization server and resource 
server are not co-located, are not ran by the same entity,
or are otherwise separated by some boundary".

*In such cases*, it is important to be able to make sure that an 
authorization server will NOT be able to know where the authorizations
tokens that it issues will be used. Using another wording, an AS SHALL 
NOT be able to know where an AT requested by a given client will be used:
*Authorization servers SHALL not have the **capability to act as "Big 
Brother"* and thus SHALL not be able to know which resources are going
to be accessed by clients.

This means that, in such cases, an authorization server SHALL not be 
able to know for which resource server an AT has been targeted.

It is a fact that most solutions currently deployed support a built-in 
*"Spy by desig**n"* architecture instead of a *"Privacy by design"* 
architecture.

However, for security reasons an AT still needs to be targeted.

The problem to be solved is the following:

  * for security reasons, the AT must be targeted.
  * for privacy reasons, the AS must be kept ignorant of the name of the
    target.

One way to solve the problem is to consider that the AT is composed of a 
sequence of two structures: a signed structure and an unsigned structure.

The signed structure contains a "salted aud claim".
The unsigned structure contains a "aud salt claim".

In practice, the "salted aud claim" will be composed of both a one way 
hash function algorithm identifier and a hash value.

Before requesting an AT to an AS, the client chooses a resource server 
and select a resource indicator value corresponding to the identifier 
the resource server.
It then chooses a random value which it uses as a "aud salt claim" and 
then computes a hash value by using a one-way hash function which combines
one of the resource indicators of the RS with the "aud salt claim". Both 
the one way hash function algorithm identifier and the computed  hash value
are then included into the "salted aud claim".

The AT request then contains a "salted aud claim" instead of an"aud 
claim". The AT blindly copies this value into the AT which is then 
identified as
a "salted aud claim" instead of an "aud claim".

When the AT is received by the client, it adds to the AT the unsigned 
part to the AT which contains the "aud salt claim" and sends both the 
signed
and the unsigned part of the AT to the RS.

When the RS receives the AT, using the one way hash function algorithm 
identifier contained in the "salted aud claim", it combines each of its 
resource indicators
with the "aud salt claim" contained in the unsigned part of the AT and 
verifies whether it matches with the hash value contained in the "salted 
aud claim".
If none of these resource indicators is providing a match, then the RS 
SHALL rejected the AT.

The implication is to allow an AT to contain both a signed part and an 
unsigned part.

In addition, the "aud claim" should be multi-valued where, as a 
consequence, both the "salted aud claim" with the "aud salt claim" would 
also be multi-valued.


2) Within clause 6, "Privacy Considerations", the text states:

As JWT access tokens carry information by value, it now becomes
possible for requestors and receivers to directly peek inside the
token claims collection.The client MUST NOT inspect the content of
the access token: the authorization server and the resource server
might decide to change token format at any time (...).

On the contrary, a client SHALL be able to inspect the content of the 
access token to make sure that the AS has not included in the AT some 
private information
that should not be present, before forwarding the AT to the RS. It is 
possible for an AS to change the format of the AT, but the RS will not 
necessarily be in synch
with the RS.

Since there are now cases where "the authorization server and resource 
server are not co-located, are not ran by the same entity, or are 
otherwise separated
by some boundary", a key point is that an AS and a RS DO NOT necessarily 
need to know each other. The RS only needs to trust the AS. (full stop)

This means that an identifier of the profile of the AT should be able to 
be included into the AT. This allows for future extensions.

In any case, the "MUST NOT" in the quoted sentence should be removed or 
changed or the whole sentence should be removed..


3) Within clause 2.2.2 (second paragraph):

This profile does not introduce any mechanism for a client to
directly request the presence of specific claims in JWT access
tokens, as the authorization server can determine what additional
claims are required by a particular resource server by taking in
consideration the client_id of the client, the scope and the resource
parameters included in the request.

Allowing a client to only specify a scope and a resource is very 
restrictive.

What would be the title of an RFC that would allow the client to request 
the presence of specific claims in JWT access ?

If such a restriction is kept, would the current title of this RFC still 
be inappropriate
"JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens" ?

Denis

DP Security Consulting