I have severe concerns with this approach. It’s not appropriate to
register arbitrary JSON object member names as JWT claim names –
especially when the JSON object member names are not even being
used as JWT claim names. *Please do not do this*, as it would
needlessly pollute the JWT claim name namespace with registered
names that are application specific.
Secondarily, I have concerns about these names and suggestions for
how to address them.
“active” – This claim is not presently adequately defined. And its
definition will of necessity be specific to the introspection
application. Therefore, it should not be registered as a general
JWT claim name. A name I would be comfortable with for this
concept would be urn:ietf:params:oauth:introspection:active, since
it makes it clear what application the name is used with.
“user_id” – The concept you’re describing is almost universally
called “username”. User ID is typically the numeric account
identifier (carried in the “sub” claim in a JWT), and so is not the
right name for this. Compare it to the preferred_username claim in
OpenID Connect. Please change this either to “username” or
urn:ietf:params:oauth:introspection:username.
“token_type” – While this is well-defined, the usage is fairly
specific to this application. Again, adding the
urn:ietf:params:oauth:introspection: name prefix would address this
issue.
If you give up registering these names in the JWT Claims registry,
I’m OK with you using short names. But if you want them to live
alongside other JWT claim names, please include the
urn:ietf:params:oauth:introspection: in lieu of registration.
Thank you,
-- Mike
*From:*OAuth [mailto:[email protected]] *On Behalf Of *Justin
Richer
*Sent:* Wednesday, March 04, 2015 1:46 PM
*To:* Hannes Tschofenig
*Cc:* <[email protected]>
*Subject:* Re: [OAUTH-WG] Alignment of JWT Claims and Token
Introspection "Claims"
Hi Hannes, thanks for the feedback. Responses inline.
On Mar 3, 2015, at 5:56 AM, Hannes Tschofenig
<[email protected] <mailto:[email protected]>>
wrote:
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.
We’ve already done this in the latest draft. Or at least, that’s
the intent of the current text — the registry is referenced and the
new claims are registered. Can you specifically point to places
where this needs to be improved upon?
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.
The definition of “active” is really up to the authorization
server, and I’ve yet to hear from an actual implementor who’s
confused by this definition. When you’re the one issuing the
tokens, you know what an “active” token means to you. Still,
perhaps we can be even more explicit, such as:
active
REQUIRED. Boolean indicator of whether or not the presented
token is currently active. The specifics of a token’s active
state will vary depending on the implementation of the
authorization server, but generally this will indicate that a
given token has been issued by this authorization server, has
not been revoked by the resource owner, and is within its given
time window of validity (e.g. not expired).
Also, this is one of the places where the overlap between JWT and
introspection claims don’t make sense. It doesn’t make any sense
for a JWT to carry an “active” claim at all. Why would you have a
JWT claim to be anything but active? We should register it with the
JWT registry to avoid name collisions, but there’s nothing in the
JWT registry that says “don’t use this inside of a JWT”. Do you
have any advice on how to address this?
client_id: What is the resource server going to do with the client_id?
What authorization decision could it make?
Whatever it wants to. If an RS can figure out something from the
client_id, why not let it? The client_id is a piece of information
about the context of the issuance of the token, and a common enough
OAuth value for decision making.
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.
This isn’t any different from having a userinfo-endpoint equivalent
(like social graph or twitter API) and it’s got the same trouble.
- 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.
We added in “user_id” to our implementation due to developer demand
— they wanted a username associated with the return value, but to
leave the “sub” value the same as that defined by OpenID Connect.
Note that this is in an environment where the username is a known
quantity, and they’re not trying to do cross-domain authentication.
They just want to know whose token this was so they can figure out
whose data to return. It’s not used for display, but I tried to
make the definition in contrast to the machine-facing “sub” value.
- 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.
You’re correct, this is currently missing and I’ll add that in.
- 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.
You could introspect an ID token if you wanted to, but it’s usually
easier to just parse it yourself because it’s self-contained. The
ID Token also extends JWT, so there’s nothing stopping you from
returning those claims as well. However, note that the audience of
the ID token is the OAuth *client* whereas the targeted user of the
introspection endpoint is the *protected resource*. The PR isn’t
going to see the ID Token most of the time, and the client’s not
going to need to (or be able to) introspect its tokens most of the
time, so in practice there’s not really any overlap.
— Justin
Ciao
Hannes
_______________________________________________
OAuth mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
