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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
