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

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 03 Mar 2015 11:56:25 +0100

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

---

From: Justin Richer <[email-masked]>
Date: Wed, 4 Mar 2015 16:45:58 -0500

Hi Hannes, thanks for the feedback. Responses inline.

> On Mar 3, 2015, at 5:56 AM, Hannes Tschofenig <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi Justin, Hi all,
> 

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?

> 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?

> 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. 

> lead to further confusion regarding OAuth access token usage for

This isn’t any different from having a userinfo-endpoint equivalent (like social graph or twitter API) and it’s got the same trouble. 

> 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.

> may not necessarily be true.

You’re correct, this is currently missing and I’ll add that in.

> http://openid.net/specs/openid-connect-core-1_0.html#IDToken <http://openid.net/specs/openid-connect-core-1_0.html#IDToken>). If this

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-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 4 Mar 2015 22:54:11 +0000

>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

According to the spec as written the Introspection endpoint does not have to be an Authorization Sever and thus each could have defined “active” in different ways

From: OAuth [mailto:[email-masked]] On Behalf Of Justin Richer
Sent: Wednesday, March 4, 2015 1:46 PM
To: Hannes Tschofenig
Cc: <[email-masked]>
Subject: Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection "Claims"

On Mar 3, 2015, at 5:56 AM, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:

Hi Justin, Hi all,

What needs to be done?

  active

active

 — Justin

Ciao
Hannes

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Mike Jones <[email-masked]>
Date: Wed, 4 Mar 2015 23:28:18 +0000

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-masked]] On Behalf Of Justin Richer
Sent: Wednesday, March 04, 2015 1:46 PM
To: Hannes Tschofenig
Cc: <[email-masked]>
Subject: Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection "Claims"

Hi Justin, Hi all,

What needs to be done?

  active

active

 — Justin

Ciao
Hannes

---

From: Justin Richer <[email-masked]>
Date: Wed, 04 Mar 2015 21:43:03 -0500

I'm actually fine with keeping the introspection-specific elements out 
of the registry (see my note on "active" and how it doesn't fit in JWT 
below), but I do not want to give up the short names. The short names 
are already in production, especially "active", which is well understood 
and used in practice today, and has been for years[1]. Changing this 
would fundamentally break all existing implementations for no good 
reason. I'm slightly more OK with changing "user_id" to "username", 
since that's not as widely deployed to my knowledge (other implementers, 
please pipe up if I'm mistaken), and I'm well familiar with 
"preffered_username" in OIDC because I'm the one that put it in there 
[2]. :) While I prefer to leave it be at this stage, I think this is a 
less destructive change than "active", "scope", or "client_id" would be.

For background to my stance regarding the registry: several revisions 
(and years) ago, the introspection draft re-defined several fields that 
overlapped with JWT and we were asked to correlate the two. Originally, 
we simply had a pointer to re-use the JWT claims as defined, and stacked 
our own claims on top. Later, we were asked to outright merge them, 
which is what we have right now. If the WG wants to back off that last 
change to the middle state -- where we re-use the JWT registry but don't 
write to it -- I'm very happy with that result and can work that (back) 
into the next draft.

Though it does point out something strange about the standards process 
that we're running into here: JWT needed a place to register bits of 
metadata about a token, so it created one. This became the "JWT 
registry", and now it's got hangings of being "JWT-specific". When 
introspection came along with a need to talk about much the same kind of 
information, it makes sense to re-use the existing items but also that 
there would be things that are introspection-specific.

  -- Justin

[1] https://tools.ietf.org/html/draft-richer-oauth-introspection-03
[2] https://bitbucket.org/openid/connect/issue/584/messages-username-claim

On 3/4/2015 6:28 PM, Mike Jones wrote:
>
> 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.
>
> “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-masked]] *On Behalf Of *Justin Richer
> *Sent:* Wednesday, March 04, 2015 1:46 PM
> *To:* Hannes Tschofenig
> *Cc:* <[email-masked]>
> *Subject:* Re: [OAUTH-WG] Alignment of JWT Claims and Token 
> Introspection "Claims"
>
>     On Mar 3, 2015, at 5:56 AM, Hannes Tschofenig
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi Justin, Hi all,
>
> 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?
>
>
>
> 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?
>
>
>
>
> 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.
>
>
>
> This isn’t any different from having a userinfo-endpoint equivalent 
> (like social graph or twitter API) and it’s got the same trouble.
>
>
>
>
> 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.
>
>
>
>
> 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
>

---

From: Mike Jones <[email-masked]>
Date: Thu, 5 Mar 2015 07:36:51 +0000

It sounds to me like you're making a good argument for this spec to have its own registry.  Registries are easy to establish and use.
________________________________
From: Justin Richer<mailto:[email-masked]>
Sent: ‎3/‎4/‎2015 6:43 PM
To: Mike Jones<mailto:[email-masked]>; Hannes Tschofenig<mailto:[email-masked]>
Cc: <[email-masked]><mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection "Claims"

I'm actually fine with keeping the introspection-specific elements out of the registry (see my note on "active" and how it doesn't fit in JWT below), but I do not want to give up the short names. The short names are already in production, especially "active", which is well understood and used in practice today, and has been for years[1]. Changing this would fundamentally break all existing implementations for no good reason. I'm slightly more OK with changing "user_id" to "username", since that's not as widely deployed to my knowledge (other implementers, please pipe up if I'm mistaken), and I'm well familiar with "preffered_username" in OIDC because I'm the one that put it in there [2]. :) While I prefer to leave it be at this stage, I think this is a less destructive change than "active", "scope", or "client_id" would be.

For background to my stance regarding the registry: several revisions (and years) ago, the introspection draft re-defined several fields that overlapped with JWT and we were asked to correlate the two. Originally, we simply had a pointer to re-use the JWT claims as defined, and stacked our own claims on top. Later, we were asked to outright merge them, which is what we have right now. If the WG wants to back off that last change to the middle state -- where we re-use the JWT registry but don't write to it -- I'm very happy with that result and can work that (back) into the next draft.

Though it does point out something strange about the standards process that we're running into here: JWT needed a place to register bits of metadata about a token, so it created one. This became the "JWT registry", and now it's got hangings of being "JWT-specific". When introspection came along with a need to talk about much the same kind of information, it makes sense to re-use the existing items but also that there would be things that are introspection-specific.

 -- Justin

                                                            Thank you,
                                                            -- Mike

From: OAuth [mailto:[email-masked]] On Behalf Of Justin Richer
Sent: Wednesday, March 04, 2015 1:46 PM
To: Hannes Tschofenig
Cc: <[email-masked]><mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection "Claims"

Hi Justin, Hi all,

What needs to be done?

  active

active

 — Justin

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 05 Mar 2015 09:39:42 +0100

Hi Mike, Hi Justin,

I guess you agree with me that fundamentally the JWT and the token
introspection solve the same problem, namely to provide the
authorization server with information that it can use to make an
authorization decision. The difference is only in the way how the
message flows.

Now, to the argument that developers have not yet complained about the
underspecified claims/attributes is not particularly good. We tend to
hear about complains years later when things go wrong and then we cannot
change them anymore.

Tell me for the active claim what type of checks the authorization
server is supposed to do.

If the authorization server and the resource server are provided by
different parties then it is important to be clear about what checks
each of the two parties are supposed to be doing. If the active claim
aims to outsource the authorization decision from the resource server to
the authorization server then that's a completely different story than
just doing some basic sanity check on some of the JWT claims.

Ciao
Hannes

On 03/05/2015 08:36 AM, Mike Jones wrote:
> It sounds to me like you're making a good argument for this spec to have
> its own registry.  Registries are easy to establish and use.
> ------------------------------------------------------------------------
> From: Justin Richer <mailto:[email-masked]>
> To: Mike Jones <mailto:[email-masked]>; Hannes Tschofenig
> <mailto:[email-masked]>
> Cc: <[email-masked]> <mailto:[email-masked]>

---

From: Justin Richer <[email-masked]>
Date: Thu, 05 Mar 2015 07:23:36 -0500

The "active" claim boils down to the AS saying "Do I think this token is 
any good or not?" and it's really up to the AS how it determines that. 
Our own implementation does a data store lookup on the token value. If 
it finds the token, then the token is active. If the token had been 
revoked, or expired, then it wouldn't have come out of the data store in 
the first place, and it's not active. I've seen others do the same thing.

Other stateless implementations are going to probably parse the token 
itself and do things like check claims and signatures to see if the 
token's any good. Or they might decrypt the token at the AS (assuming in 
this example that it was encrypted using the AS's key) and dig inside 
the protected structure that's not available to the RS. Once it's inside 
that structure the AS can figure out if the token's active or not, and 
tell the RS.

Or there might be a combination of the two where the AS parses the token 
and checks its signature and then uses some key field in the token to 
look up more information in a data store. If all that checks out then 
the token is active, probably.

And the AS might want to do other checks, like see if this particular RS 
is even allowed to ask about this particular token.

It is not, however, just a sanity check across other claims already 
embedded in the token -- you could very easily use an unstructured 
token. In fact, that's the world that this was first deployed in back 
4-5 years ago.

The important thing is that as far as the RS is concerned, the AS did 
*some* check on the token and came back with a thumbs up / thumbs down 
response. The thumbs up response can contain other information as well, 
such as scopes and client IDs and whatnot, which can help the RS make 
its authorization decision. But at its core, the "active" claim 
fundamentally says "is this token any good at all, according to the AS 
that I asked?" and the RS can make its primary authorization decision 
based on that. If the RS has made the decision to outsource the token 
validity check to the AS, then the RS either understands or doesn't care 
what checks the AS makes in its decision regardless of implementation or 
vendor. Either way, it will abide by them since that's the whole point 
of outsourcing that decision.

And I think you're too quick to dismiss the lack of confusion on the 
part of developers, considering that they are in fact the target 
audience of specifications like this. If we're not writing these 
documents for developers, who are we writing them for?

  -- Justin

---

From: Justin Richer <[email-masked]>
Date: Thu, 05 Mar 2015 07:25:33 -0500

I'm OK with a separate registry, my only question is whether or not 
there's a way to correlate and coordinate the values of the two 
registries. The concern with importing the JWT claims directly into 
introspection's response was that we'd potentially be stepping on an 
existing namespace. In practice, I don't think that's a concern, but I 
can see the argument. If we establish an introspection response 
registry, how do we continue to deconflict with the JWT registry?

  -- Justin

On 3/5/2015 2:36 AM, Mike Jones wrote:
> It sounds to me like you're making a good argument for this spec to 
> have its own registry.  Registries are easy to establish and use.
> are already in production, especially "active", which is well 
> understood and used in practice today, and has been for years[1]. 
> Changing this would fundamentally break all existing implementations 
> for no good reason. I'm slightly more OK with changing "user_id" to 
> "username", since that's not as widely deployed to my knowledge (other 
> implementers, please pipe up if I'm mistaken), and I'm well familiar 
> with "preffered_username" in OIDC because I'm the one that put it in 
> there [2]. :) While I prefer to leave it be at this stage, I think 
> this is a less destructive change than "active", "scope", or 
> "client_id" would be.
>
> (and years) ago, the introspection draft re-defined several fields 
> that overlapped with JWT and we were asked to correlate the two. 
> Originally, we simply had a pointer to re-use the JWT claims as 
> defined, and stacked our own claims on top. Later, we were asked to 
> outright merge them, which is what we have right now. If the WG wants 
> to back off that last change to the middle state -- where we re-use 
> the JWT registry but don't write to it -- I'm very happy with that 
> result and can work that (back) into the next draft.
>
> introspection came along with a need to talk about much the same kind 
> of information, it makes sense to re-use the existing items but also 
> that there would be things that are introspection-specific.
>
>  -- Justin
>
>> 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 
>> 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 
>> claims are registered. Can you specifically point to places where 
>> this needs to be improved upon?
>>
>>
>>
>> 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
>>
>>     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).
>>
>> 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?
>>
>>
>>
>>
>> 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
>>

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 05 Mar 2015 13:53:10 +0100

Hi Justin,

in a security specification we should be able to say exactly what the
semantic of a certain attribute is.

What I expect happening today is that many organizations provide both
resource server and authorization server and agree in an out-of-band
fashion what the meaning of that value is. This is why we don't hear
back from implementers at this point in time.

This is, however, not the purpose of standardization. We want to develop
a spec that allows two different vendors to plug their stuff together
and it works without having to agree (out of band) what the semantic if
the different fields is.

We have already seen in OAuth that vague text does not increase security.

If the purpose of the active claim is only to say that the AS did some
checks without further indicating what it actually did then we could as
well use the fact that there has been a response to the request (rather
than an error message) as well. That seems to be roughly the level of
semantic we are at with this at the moment.

I hope you understand that I have to push back on these hand-wavy ideas
since otherwise we need profiles in other organizations that explain
what the IETF OAuth documents really mean.

Ciao
Hannes

On 03/05/2015 01:23 PM, Justin Richer wrote:
>>> [2]
>>> https://bitbucket.org/openid/connect/issue/584/messages-username-claim
>>>
>>>> token

---

From: John Bradley <[email-masked]>
Date: Thu, 5 Mar 2015 13:48:57 +0100

A middle ground,  that perhaps no one will like is registering application specific claims in the JWT registry,  but pretending them with a app namespace. 

Eg
Int:active

That prevents people from stepping on each other with short names,  and gives a central place to look them up,  without requiring all all alls to understand all claims. 

John B. 

Sent from my iPhone

> On Mar 5, 2015, at 1:25 PM, Justin Richer <[email-masked]> wrote:
> 
> I'm OK with a separate registry, my only question is whether or not there's a way to correlate and coordinate the values of the two registries. The concern with importing the JWT claims directly into introspection's response was that we'd potentially be stepping on an existing namespace. In practice, I don't think that's a concern, but I can see the argument. If we establish an introspection response registry, how do we continue to deconflict with the JWT registry?
> 
>  -- Justin
> 
>> From: Justin Richer
>> To: Mike Jones; Hannes Tschofenig
>> Cc: <[email-masked]>
>>> On Mar 3, 2015, at 5:56 AM, Hannes Tschofenig <[email-masked]> wrote:
>>>  
>>> Hi Justin, Hi all,
>>> 
>>> [email-masked]
> [email-masked]

---

From: Justin Richer <[email-masked]>
Date: Thu, 05 Mar 2015 08:02:26 -0500

And you're right that I *really* don't like this because it breaks 
existing implementations somewhat arbitrarily. Mike had suggested 
something similar.

  -- Justin

On 3/5/2015 7:48 AM, John Bradley wrote:
> A middle ground,  that perhaps no one will like is registering 
> application specific claims in the JWT registry,  but pretending them 
> with a app namespace.
>
> Eg
> Int:active
>
> That prevents people from stepping on each other with short names, 
>  and gives a central place to look them up,  without requiring all all 
> alls to understand all claims.
>
> John B.
>
> Sent from my iPhone
>
> On Mar 5, 2015, at 1:25 PM, Justin Richer <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> existing namespace. In practice, I don't think that's a concern, but 
>> I can see the argument. If we establish an introspection response 
>>> To: Mike Jones <mailto:[email-masked]>; Hannes 
>>> Tschofenig <mailto:[email-masked]>
>>> I'm actually fine with keeping the introspection-specific elements 
>>> out of the registry (see my note on "active" and how it doesn't fit 
>>> in JWT below), but I do not want to give up the short names. The 
>>> short names are already in production, especially "active", which is 
>>> well understood and used in practice today, and has been for 
>>> years[1]. Changing this would fundamentally break all existing 
>>> implementations for no good reason. I'm slightly more OK with 
>>> changing "user_id" to "username", since that's not as widely 
>>> deployed to my knowledge (other implementers, please pipe up if I'm 
>>> mistaken), and I'm well familiar with "preffered_username" in OIDC 
>>> because I'm the one that put it in there [2]. :) While I prefer to 
>>> leave it be at this stage, I think this is a less destructive change 
>>> than "active", "scope", or "client_id" would be.
>>>
>>> For background to my stance regarding the registry: several 
>>> revisions (and years) ago, the introspection draft re-defined 
>>> several fields that overlapped with JWT and we were asked to 
>>> correlate the two. Originally, we simply had a pointer to re-use the 
>>> JWT claims as defined, and stacked our own claims on top. Later, we 
>>> were asked to outright merge them, which is what we have right now. 
>>> If the WG wants to back off that last change to the middle state -- 
>>> where we re-use the JWT registry but don't write to it -- I'm very 
>>> happy with that result and can work that (back) into the next draft.
>>>
>>> Though it does point out something strange about the standards 
>>> process that we're running into here: JWT needed a place to register 
>>> bits of metadata about a token, so it created one. This became the 
>>> "JWT registry", and now it's got hangings of being "JWT-specific". 
>>> When introspection came along with a need to talk about much the 
>>> same kind of information, it makes sense to re-use the existing 
>>> items but also that there would be things that are 
>>> introspection-specific.
>>>
>>>  -- Justin
>>>
>>>> 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.
>>>>
>>>> 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.
>>>>
>>>> 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?
>>>>
>>>>
>>>>
>>>> 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
>>>>
>>>>     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).
>>>>
>>>> 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?
>>>>
>>>>
>>>>
>>>>
>>>> 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.
>>>>
>>>>
>>>>
>>>>
>>>> easier to just parse it yourself because it’s self-contained. The 
>>>> ID Token also extends JWT, so there’s nothing stopping you from

---

From: Justin Richer <[email-masked]>
Date: Thu, 05 Mar 2015 08:15:24 -0500

Hannes,

You're on the right track: the "active" claim *is* effectively a top 
level toggle, much like an error message would be. However, we're taking 
the same approach that token revocation uses and returning an HTTP OK 
response with the information inside instead of an HTTP error. This was 
decided (in both cases) because the HTTP request itself is not in error, 
nor is there any error state on the server, it's returning information 
about the object requested. It's actually up to the RS to determine what 
to do with that in its response back to the client.

Furthermore, in many cases, the RS *can't* know and *shouldn't* know how 
or why the AS makes that determination, just like the client *can't* and 
*shouldn't* know how the AS generates a token value itself. The client 
just knows that one was created, or not, in response to an authorization 
request. Likewise, the RS in this case just knows that the token was 
good, or not, in response to an introspection request. This type of 
black-box interoperability is exactly what standards are about and is 
not hand-wavy at all. In fact, it's telling you exactly what it says on 
the tin without needlessly disclosing details (leading to a potential 
oracle attack from an RS fishing for tokens). It's the simplest thing 
that could possibly work, and it's been shown to work and interoperate 
between vendors for years in production.

If you're building an RS and you're outsourcing AS functionality 
entirely, then you need to trust that the AS is going to give you the 
right answer when you ask the question "is this token any good?", which 
is what's going on here. You as the developer might or might not care 
how the AS came to that conclusion, but, importantly, it doesn't matter 
for the protocol how that decision was reached. We can provide guidance 
for AS developers as in the text that I suggested earlier in this 
thread, but prescribing behavior beyond that isn't helpful.

If you think the definition itself can be more clearly articulated, 
please propose updated text for us to include.

  -- Justin

---

From: John Bradley <[email-masked]>
Date: Thu, 5 Mar 2015 15:04:00 +0100

Others will hate the idea as well for other reasons I expect. 

If we leave introspection aside it might be a way to deal with other specs going forward. 

Sent from my iPhone

> On Mar 5, 2015, at 2:02 PM, Justin Richer <[email-masked]> wrote:
> 
> And you're right that I *really* don't like this because it breaks existing implementations somewhat arbitrarily. Mike had suggested something similar.
> 
>  -- Justin
>

---

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 06 Mar 2015 17:22:14 +0000

Hi All,

We might have a requirement to support a case where AS returns an access 
token directly to a human user, with the user subsequently configuring a 
confidential client with this token. The actual client is not capable of 
supporting a (more dynamic) code flow at this stage.

So it is nearly like an implicit code flow except that the user is asked 
upfront which clients can get the tokens allocated and the token is 
returned in the HTML response without redirecting and placing the token 
in a fragment.

Apparently a number of big providers do just that, let users allocate 
tokens for some clients with the users expected to copy the tokens into 
the confidential clients afterwards.

I'd like to ask, it is a reasonable approach, to have tokens transferred 
manually into the confidential client ?

Would it be more appropriate for a user to request a code and then copy 
it to the confidential client and expect it to get the tokens itself. I 
guess the problem here may be a code is short lived, but so is a typical 
access token - but the latter can be supported by a refresh one.

Another question: does it even qualify as an OAuth2 grant for token 
exchange, the process of a user pre-authorizing a client and getting not 
a code but tokens back ? I guess it does, so how a grant like this one 
would typically be called ? We'd have no problems with assigning some 
custom name to such a grant but curious how others approach it...

Thanks, Sergey

---

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 06 Mar 2015 17:59:53 +0000

Hi All,

The example at [1] suggests that clients working with a refresh grant 
authenticate as usual when they need to use a grant.

The section 3.3 in the threat model document [2] says that

    "as long as the confidentiality of the particular token can be
    ensured by the client, a refresh token can also be used as an
    alternative means to authenticate the client instance itself"

How this can be processed by the access token service that expects a 
client to authenticate ?
Example, typically,
Authorization: Basic encodedInfo

If a refresh token is used to authenticate, how to express it ?

client_id=refreshToken in the form payload or URI query ?

Thanks, Sergey

[1] https://tools.ietf.org/html/rfc6749#section-6
[2] https://tools.ietf.org/html/rfc6819#section-3.3

---

From: Dick Hardt <[email-masked]>
Date: Fri, 6 Mar 2015 10:07:31 -0800

If you are interested in how others have done a similar flow, you could
look at how smart TVs supporting Netflix and Amazon are authorized.

On Fri, Mar 6, 2015 at 9:22 AM, Sergey Beryozkin <[email-masked]>
wrote:

> returned in the HTML response without redirecting and placing the token in
> a fragment.
>
> tokens for some clients with the users expected to copy the tokens into the
> confidential clients afterwards.
>
> Would it be more appropriate for a user to request a code and then copy it
> to the confidential client and expect it to get the tokens itself. I guess
> the problem here may be a code is short lived, but so is a typical access
> token - but the latter can be supported by a refresh one.
>
> exchange, the process of a user pre-authorizing a client and getting not a
> code but tokens back ? I guess it does, so how a grant like this one would
> typically be called ? We'd have no problems with assigning some custom name
> to such a grant but curious how others approach it...
>
> Thanks, Sergey
>
>
>
>

---

From: Justin Richer <[email-masked]>
Date: Fri, 6 Mar 2015 13:28:52 -0500

All you’re really doing here is having a more manual and less automated portion for part of the process. You’d want to do this using a registered redirect URI that hosts the HTML page, and then you’d need a control in the app itself where the user could interact.

I would personally recommend using this approach to move an authorization code manually instead of moving an access token. Assuming your client can access the auth server directly (using the backchannel, no browser), you should be able to POST to the token endpoint and get the token directly without the user having to handle it. The reason being that auth codes are client-limited and much more time-limited, and their leakage doesn’t immediately lead to leakage of API access.

We had a similar approach with a limited client back in the OAuth 1.0 days, where we had an HTML page that would print the oauth_verify code on the screen that the user would type into the application. These days, on most platforms, it’s much easier to register a custom URL handler or use another system service to get the code directly that this hack has all but disappeared, at least in my view.

 — Justin

> On Mar 6, 2015, at 12:22 PM, Sergey Beryozkin <[email-masked]> wrote:
> 
> Hi All,
> 
> We might have a requirement to support a case where AS returns an access token directly to a human user, with the user subsequently configuring a confidential client with this token. The actual client is not capable of supporting a (more dynamic) code flow at this stage.
> 
> So it is nearly like an implicit code flow except that the user is asked upfront which clients can get the tokens allocated and the token is returned in the HTML response without redirecting and placing the token in a fragment.
> 
> Apparently a number of big providers do just that, let users allocate tokens for some clients with the users expected to copy the tokens into the confidential clients afterwards.
> 
> I'd like to ask, it is a reasonable approach, to have tokens transferred manually into the confidential client ?
> 
> Would it be more appropriate for a user to request a code and then copy it to the confidential client and expect it to get the tokens itself. I guess the problem here may be a code is short lived, but so is a typical access token - but the latter can be supported by a refresh one.
> 
> Another question: does it even qualify as an OAuth2 grant for token exchange, the process of a user pre-authorizing a client and getting not a code but tokens back ? I guess it does, so how a grant like this one would typically be called ? We'd have no problems with assigning some custom name to such a grant but curious how others approach it...
> 
> Thanks, Sergey
> 
> 
> 
>

---

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 06 Mar 2015 22:20:25 +0000

Thanks for a reference to such applications...

Sergey
On 06/03/15 18:07, Dick Hardt wrote:
> On Fri, Mar 6, 2015 at 9:22 AM, Sergey Beryozkin <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi All,
>
>     We might have a requirement to support a case where AS returns an
>     access token directly to a human user, with the user subsequently
>     configuring a confidential client with this token. The actual client
>     is not capable of supporting a (more dynamic) code flow at this stage.
>
>     So it is nearly like an implicit code flow except that the user is
>     asked upfront which clients can get the tokens allocated and the
>     token is returned in the HTML response without redirecting and
>     placing the token in a fragment.
>
>     Apparently a number of big providers do just that, let users
>     allocate tokens for some clients with the users expected to copy the
>     tokens into the confidential clients afterwards.
>
>     I'd like to ask, it is a reasonable approach, to have tokens
>     transferred manually into the confidential client ?
>
>     Would it be more appropriate for a user to request a code and then
>     copy it to the confidential client and expect it to get the tokens
>     itself. I guess the problem here may be a code is short lived, but
>     so is a typical access token - but the latter can be supported by a
>     refresh one.
>
>     exchange, the process of a user pre-authorizing a client and getting
>     not a code but tokens back ? I guess it does, so how a grant like
>     this one would typically be called ? We'd have no problems with
>     assigning some custom name to such a grant but curious how others
>     approach it...
>
>     Thanks, Sergey
>
>
>
>
>     _________________________________________________
>     OAuth mailing list
>     https://www.ietf.org/mailman/__listinfo/oauth
>     <https://www.ietf.org/mailman/listinfo/oauth>
>
>

---

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 06 Mar 2015 22:31:51 +0000

Hi
> I would personally recommend using this approach to move an authorization code manually instead of moving an access token. Assuming your client can access the auth server directly (using the backch…
Right now this is what I'm considering, whether to restrict it to the 
client getting the tokens itself, with the inserted code, or indirectly, 
after the user does it. We already support the former for public 
clients, I guess in the latter case a token will also be linked to a 
client because a user will enter a client id when requesting a token.

Just not sure yet if a 3rd party client will be 'prepared' as you say to 
interact directly with AS, I guess it will be given that it is expected 
it should be able to refresh...

> We had a similar approach with a limited client back in the OAuth 1.0 days, where we had an HTML page that would print the oauth_verify code on the screen that the user would type into the applicat…

Can you give me a favor and clarify a bit what you mean when referring 
to a registered URL handler ? A user signs in, requests a code or a 
token for a specific client, AS returns it to the user directly. I guess 
it can redirect the user to some other web application which is where 
the user will interact and get the code or token. What a registered URL 
handler can change in this process, make it more automated ? (I 
understand working with the code is better in general...)

Thanks, Sergey

---

From: Justin Richer <[email-masked]>
Date: Fri, 6 Mar 2015 17:47:17 -0500

> On Mar 6, 2015, at 5:31 PM, Sergey Beryozkin <[email-masked]> wrote:
> 
> Hi
> Right now this is what I'm considering, whether to restrict it to the client getting the tokens itself, with the inserted code, or indirectly, after the user does it. We already support the former for public clients, I guess in the latter case a token will also be linked to a client because a user will enter a client id when requesting a token.
> 
> Just not sure yet if a 3rd party client will be 'prepared' as you say to interact directly with AS, I guess it will be given that it is expected it should be able to refresh…

> Can you give me a favor and clarify a bit what you mean when referring to a registered URL handler ? A user signs in, requests a code or a token for a specific client, AS returns it to the user directly. I guess it can redirect the user to some other web application which is where the user will interact and get the code or token. What a registered URL handler can change in this process, make it more automated ? (I understand working with the code is better in general…)

I mean not doing anything special with the OAuth grants: use the redirects that are already there, just do something special with the page you’re redirected to that will display the code/token to the user and instruct them to paste it into the client appropriately. It can even be a pretty static page, with a bit of javascript to pull off the return values.

So you could build it like this: the user starts off at some webpage that says “Authorize AppX” and clicks that. This redirects them to the authorization endpoint, just like normal. Note that this redirect will include the client ID and scopes and all that, just like normal. Then the user logs in, authorizes, and is redirected back to AppX’s redirect_uri, just like normal. This redirect URI will be on the same service that hosts the “start off” page, if you want, so you can even check the “state” value against a stored cookie or session for extra protection. That page pops off the code or token parameter and displays it to the user, telling them how to get it into the client. Once the code or token is in the client, it goes on its way.

This all works without changing OAuth at all, and the auth server and resource server can be completely off-the-shelf. You’re effectively splitting the client in half: there’s a web-based half that deals with the authorization redirect, and a native half that deals with the code/token swap and the protected API calls. You use a person to glue them together.

I’ve built this kind of thing before, and it works well until people fall apart moving the displayed code between the web page and the rest of the application. That’s why a lot of apps, where possible, have just gone to popping up a browser. Dick’s recommendation to look at settop boxes and other apps that *can’t* pop up a browser is a good recommendation.

 — Justin

---

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 06 Mar 2015 23:01:24 +0000

Hi Justin,

Thanks for typing it all, appreciated... I guess the idea here is 
basically introduce a little web app 'intermediary' that will act as if 
it were a client except that it will show whatever it receives back from 
AS to the user.
So we still have a common processing path at AS, as if it were a regular 
authorization code flow. I think I got it...

Thanks for the advice - enjoy the weekends
Sergey