[OAUTH-WG] Alignment of JWT Claims and Token Introspection "Claims"

[Hannes Tschofenig <[e-mail]>]

Hi Justin, Hi all,

in OAuth we provide two ways for a resource server to make an
authorization decision.

1) The resource server receives a self-contained token that contains all
the necessary information to make a local authorization decision. With
the JWT we have created such a standardized information and data model.

2) With an access request from a client the resource server asks the
authorization server for "help". The authorization server provides
information that help make the authorization decision. This is the token
introspection approach.

I believe the two approaches need to be aligned with regard to the
information and the data model. Since both documents already use JSON as
a way to encode information (=data model) and almost have an identical
information model (the data that is being passed around).

What needs to be done?

 * Use the term 'claims' in both documents.
 * Use the same registry (i.e., the registry established with the JWT).
 * Register the newly defined claims from the token introspection
document in the claims registry.

Then, I have a few comments on the new claims that are proposed:

Here is the definition of the 'active' claim:

   active
      REQUIRED.  Boolean indicator of whether or not the presented token
      is currently active.  The authorization server determines whether
      and when a given token is in an active state.

This claim is not well-defined. You need to explain what "active" means.
It could, for example, mean that the token is not yet expired. Then,
there is of course the question why you are not returning the 'exp'
claim together with the 'nbf' claim.

client_id: What is the resource server going to do with the client_id?
What authorization decision could it make?

I have a couple of reactions when I read the 'user_id' claim:
  - I believe the inclusion of a user id field in the response could
lead to further confusion regarding OAuth access token usage for
authentication.

  - Since you define it as a human readable identifier I am wondering
whether you want to say something about the usage. Here it seems that it
might be used for displaying something on a webpage rather than making
an authorization decision but I might well be wrong.

  - I am missing a discussion about the privacy implications of it.
While there is a privacy consideration section I am wondering what
controls the release of this sensitive information from the
authorization server to the resource server. While in some cases the two
parties might belong to the same organization but in other cases that
may not necessarily be true.

  - In terms of the information exchanged about the user I am curious
about the usefulness of including other information as well, such as the
info that is included in an id token (see
http://openid.net/specs/openid-connect-core-1_0.html#IDToken). If this
has nothing to do with the ID token concept and the information carried
within it then I would add that remark.

Ciao
Hannes