Subject: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 02 Dec 2014 12:23:20 +0100

Hi Justin,

I have a few remarks regarding version -01 of the token introspection
document.

* Terminology

The token introspection protocol is a client-server protocol but the
term "client" already has a meaning in OAuth. Here the client of the
token introspection protocol is actually the resource server. I believe
it would make sense to clarify this issue in the terminology section or
in the introduction. Maybe add a figure (which you could copy from
Figure 4 of
http://www.ietf.org/id/draft-ietf-oauth-pop-architecture-00.txt.

Maybe you want to call these two parties, the introspection client and
the introspection server.

* Scope

I think the document needs to be very clear that is only applicable to
bearer tokens (and not to PoP tokens). This issue was raised at the last
IETF meeting as well.

* Meta-Information

You have replicated a lot of the claims defined in
https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-31
and I am wondering why you have decided to not just re-use the entire
registry from JWT?

If you want to create a separate registry (which I wouldn't recommend)
then you have to put text into the IANA consideration section.

When you write:

"
The endpoint MAY allow other parameters to provide further context to
the query.
"

You could instead write that the token introspection MUST ignore any
parameters from the request message it does not understand.

Of course, there is the question whether any of those would be security
critical and hence ignoring them would cause problems?!

* Security

The requirement for authenticating the party issuing the introspection
request to the token introspection endpoint is justified in the security
and the privacy consideration section. The security threat is that an
attacker could use the endpoint to testing for tokens. The privacy
threat is that a resource server learns about the content of the token,
which may contain personal data. I see the former as more dangerous than
the latter since a legitimate resource server is supposed to learn about
the authorization information in the token. An attacker who had gotten
hold of tokens will not only learn about the content of the token but he
will also be able to use it to get access to the protected resource itself.

In any case, to me this sounds like mutual authentication should be
mandatory to implement. This is currently not the case. On top of that
there is single technique mandatory-to-implement outlined either (in
case someone wants to use it). That's in general not very helpful from
an interoperability point of view. Yet another thing to agree on between
the AS and the RS.

* SHOULDs

This is my usual comment that any SHOULD statement should give the
reader enough information about the trade-off decision he has to make.
When should he implement something and when should he skip it?

* Minor items

You write:

"
These include using
   structured token formats such as JWT [JWT] or SAML [[ Editor's Note:
   Which SAML document should we reference here? ]] and proprietary
   inter-service communication mechanisms (such as shared databases and
   protected enterprise service buses) that convey token information.
"

Just reference the JWT since that's what we standardize.

* 'Active' claim

you write:
"
   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.
"

Wouldn't it make more sense to return an error rather than saying that
this token is not active.

* Capitalization

Reading through the text I see bearer token/Bearer Token, Client/client,
etc. issue.

* AS <-> RS relationship

You write:
"
   Since
   OAuth 2.0 [RFC6749] defines no direct relationship between the
   authorization server and the protected resource, only that they must
   have an agreement on the tokens themselves, there have been many
   different approaches to bridging this gap.
"

I am not sure what you mean by "defines no relationship" between the AS
and the RS. Of course, there is a relationship. The AS issues tokens for
access for a specific RS. The RS needs to understand the tokens or if it
does not understand them it needs to know which AS to interact with to
learn about the content.

In a nutshell, I am not sure what you want to say with this paragraph
particularly since you state that they have to have an agreement about
the tokens.

Ciao
Hannes

---

From: Sergey Beryozkin <[email-masked]>
Date: Tue, 02 Dec 2014 11:30:38 +0000

Hi Hannes
> bearer tokens (and not to PoP tokens). This issue was raised at the last
Interesting, I was reading the doc yesterday and thought it was good it 
was not talking about specific access token types :-)

I wonder why a pop token can not be introspected in the interoperable 
way as per the text for the resource server to tale the authorization 
decision ?

Thanks, Sergey

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 02 Dec 2014 13:02:51 +0100

Hi Sergey,

> way as per the text for the resource server to tale the authorization

The problem is that the AS needs to have the same context as the RS. In
the bearer token case, the RS really only needs to pass the the access
token along but in the PoP case one could imagine a couple of different
solutions.

A possible solution is that the AS sends the RS the necessary key so
that the RS is able to verify the MAC or digital signature covering the
request.

The story would again be different if the PoP solution involves TLS.

Yet another solution would be to also forward the entire request to the
AS (which I wouldn't do).

This is not specified in the current version of token introspection and,
from the responses Justin gave at the last IETF meeting, he does not
want to wait till the PoP work is finished to actually work out the
details.

Finally, from a security point of view it would be extremely important
that the AS only provides a key to the RS if the RS is (a) authenticated
and (b) the audience field from the token matches the RS since otherwise
the PoP security degrades to a bearer token.

Ciao
Hannes

---

From: Sergey Beryozkin <[email-masked]>
Date: Tue, 02 Dec 2014 12:39:16 +0000

Hi Hannes

Thanks for the clarifications, comments below...
> the PoP security degrades to a bearer token.

I see the draft specifying an optional resource_id hint (which I read 
being an actual request URI) which is the primary signing material in 
the pop case, the extra parameters like the nonce/timestamp can be 
forwarded along.

I agree it does not make sense to forward the actual body but that is 
probably going to be a very rare case where a body hash is also provided.

Explicitly disallowing the support for the pop tokens in the 
introspection text might the interoperability reach of either pop tokens 
or token introspections in cases where a given RS integrates with a 3rd 
party AS. May be it is a Security Considerations draft issue which would 
make it more open for pop tokens

Thanks, Sergey

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 02 Dec 2014 14:31:31 +0100

Hi Sergey,

comments below.

> the pop case, the extra parameters like the nonce/timestamp can be

Of course we haven't worked out the details for the HTTP signing yet.
Hence, it would be a bit premature to make that conclusion.

> probably going to be a very rare case where a body hash is also provided.

Maybe. I see a lot of value in protecting the body of the message as
well but I would do it with the help of TLS and then use a channel
binding mechanism.

> make it more open for pop tokens

Ultimately, we are really only talking about a document management issue
here. I assume that we want to have support for introspection with PoP
tokens as well and we might just end up dumping the text into the HTTP
signing draft (as an extension to the token introspection doc).

Ciao
Hannes

---

From: Justin Richer <[email-masked]>
Date: Tue, 02 Dec 2014 09:05:42 -0500

Hannes, thanks for the review. Comments inline.

> the introspection server.

I tried to avoid the word "client" for this very reason. The draft used 
to say "client or protected resource" throughout, but in a few years of 
deployment experience it's become clear that it's pretty much just 
protected resources that need to do introspection so I changed that text 
throughout. I don't think that "introspection client" will help here 
because the party already has a name from OAuth and we should inherit it.

> bearer tokens (and not to PoP tokens). This issue was raised at the last

I think the document should be clear that it *specifies* the mechanism 
for bearer tokens, since that's the only OAuth token type that's defined 
publicly right now, and that the details for PoP will have to be 
specified in another spec -- that's exactly what Appendix C is there 
for, and if that can be clearer, please suggest better text.

However, I think it's very clear how PoP tokens would work. You send the 
value returned as the "access_token" in the token endpoint response, 
which is effectively the public portion of the PoP token. Just like a 
bearer token, this value is passed as-is from the client to the RS and 
would be passed as-is from the RS to the AS during introspection. The AS 
can then use that to look up the key and return it in an 
as-yet-unspecified field so that the RS can validate the request. The RS 
wouldn't send the signature or signed portion of the request for the AS 
to validate -- that's a bad idea. But these are all details that we can 
work out in the PoP-flavored extension. As I noted in the other thread, 
we'll have to make a similar extension for Revocation, so I still don't 
think it makes sense to hold up this work and wait for PoP to be 
finished because it's useful now, as-is.

> then you have to put text into the IANA consideration section.

The idea was to inherit JWT's syntax and semantics, at least on the 
wire, and add additional fields. It probably makes sense to just inherit 
the JWT registry, so we can do that.

> parameters from the request message it does not understand.

Noted, will add.

> critical and hence ignoring them would cause problems?!

Anything security critical would be provider-specific, in which case it 
wouldn't ignore them.

> an interoperability point of view. Yet another thing to agree on between

I had similar thoughts when putting draft -01 together but didn't want 
to make a normative change like that without the WG input. I'm fine with 
strengthening this to a MUST, since as far as I'm aware that's how it 
works in all existing implementations (can anyone else comment on 
this?). I'm less comfortable with making one particular mechanism MTI, 
since I know of implementations that use either a special set of 
credentials passed just like client credentials to the token endpoint, 
or an OAuth token specifically for the introspection endpoint. If we do 
standardize on one MTI form, I'd suggest that we make it the OAuth 
bearer token.

> When should he implement something and when should he skip it?

Noted, thanks.

> Just reference the JWT since that's what we standardize.

I'm fine with that, didn't want to offend the SAML cabal but we can cut it.

> this token is not active.

It's not an error, really. It's a valid request and valid response 
saying that token isn't any good. It would be easy enough to change the 
returned error code on the {active:false} response, but to which code? 
The request isn't Forbidden, or Not Found (the token could have been 
found but it's been deactivated or just not available to the RS that's 
asking for it), or Unauthorized, or even a Bad Request. So my logic is 
that the response is "OK", but the content of the response tells you the 
metadata about the token, which is that it's not active.

> Reading through the text I see bearer token/Bearer Token, Client/client,

Thanks, still breaking old Bad Habits of capitalizing Terms In The 
Document. Tried to clean it up, will do more.

> particularly since you state that they have to have an agreement about

What I was trying to point out is that it doesn't define the nature of 
the relationship between the two components. Specifically, it says:

    The methods used by the resource
    server to validate the access token (as well as any error responses)
    are beyond the scope of this specification but generally involve an
    interaction or coordination between the resource server and the
    authorization server.

This spec provides one mechanism for this validation. So we could 
reference this directly if that's helpful.

   -- Justin

---

From: Sergey Beryozkin <[email-masked]>
Date: Tue, 02 Dec 2014 15:07:54 +0000

Hi Justin

Please see a comment below

On 02/12/14 14:05, Justin Richer wrote:
> work out in the PoP-flavored extension.
For me, as a non-security expert but as an implementer, the idea of 
spreading the token validation across multiple nodes (AS + RS), and with 
getting AS sending the secret key to RS, does not appear to be very 
sound either, it might be the right idea but the one which would likely 
more difficult to do right - with AS having to orchestrate a secure key 
delivery to RS while partially validating the token too.

And there will be yet another specification/extension.

I suggested it might limit the interoperability reach of this draft and 
of the pop token idea - I'm sorry - most likely I'm wrong but...

The signature, the RS request URI, these are all the public parameters 
that AS can act upon. Sending the key to RS should be supported by 
capable OAuth2 RS implementations but IMHO the RS delegating the 
signature validation to AS also works...

Just my 2c

Sergey

> As I noted in the other thread,

---

From: "Richer, Justin P." <[email-masked]>
Date: Tue, 2 Dec 2014 15:36:47 +0000

> For me, as a non-security expert but as an implementer, the idea of spreading the token validation across multiple nodes (AS + RS), and with getting AS sending the secret key to RS, does not appear to be very sound either, it might be the right idea but the one which would likely more difficult to do right - with AS having to orchestrate a secure key delivery to RS while partially validating the token too.
> 
> I suggested it might limit the interoperability reach of this draft and of the pop token idea - I'm sorry - most likely I'm wrong but...
> 
> The signature, the RS request URI, these are all the public parameters that AS can act upon. Sending the key to RS should be supported by capable OAuth2 RS implementations but IMHO the RS delegating the signature validation to AS also works...
> 
> Just my 2c

Secure key delivery is pretty straight forward -- you can just pass the key in a JWK over TLS in response to an authorized request. For asymmetric keys, this would even just be the public key used to validate the signature, so there's not really any security leakage. Symmetric keys are trickier, but that's a well known tradeoff.

I think that in practice you'd lose too much of the context of the request to the RS in order to make a meaningful decision at the AS. I would rather token introspection be limited to "what can you tell me about this token" and not the larger, stickier question of "what should I do with this request". But I think that you're right in that if we solve the former, we have a stepping stone for solving the latter. I don't, however, want us to get caught up in an ocean-boiling exercise when we've got one solidly useful puddle we can do something about.

As such, I punted all mention of PoP to the appendix and I personally think it should stay there as a note of some kind, saying that it's out of scope but not out of reach.

 -- Justin

On Dec 2, 2014, at 10:07 AM, Sergey Beryozkin <[email-masked]> wrote:

> For me, as a non-security expert but as an implementer, the idea of spreading the token validation across multiple nodes (AS + RS), and with getting AS sending the secret key to RS, does not appear to be very sound either, it might be the right idea but the one which would likely more difficult to do right - with AS having to orchestrate a secure key delivery to RS while partially validating the token too.
> 
> I suggested it might limit the interoperability reach of this draft and of the pop token idea - I'm sorry - most likely I'm wrong but...
> 
> The signature, the RS request URI, these are all the public parameters that AS can act upon. Sending the key to RS should be supported by capable OAuth2 RS implementations but IMHO the RS delegating the signature validation to AS also works...
> 
> Just my 2c
> 
> Sergey
> 
>

---

From: Sergey Beryozkin <[email-masked]>
Date: Tue, 02 Dec 2014 15:44:24 +0000

Hi Justin,
> I think that in practice you'd lose too much of the context of the request to the RS in order to make a meaningful decision at the AS. I would rather token introspection be limited to "what can you…
Your language is very rich :-)

> As such, I punted all mention of PoP to the appendix and I personally think it should stay there as a note of some kind, saying that it's out of scope but not out of reach.
+1, it is a good compromise.

Thanks for the clarifications,
Sergey

---

From: "Richer, Justin P." <[email-masked]>
Date: Tue, 2 Dec 2014 15:46:26 +0000

If you're not torturing the metaphors, you're not really trying. :)

And, in case it wasn't clear before, I am very open to better text in Appendix C if anyone wants to suggest something.

 -- Justin

---

From: "Donald Coffin" <[email-masked]>
Date: Tue, 2 Dec 2014 09:25:14 -0800

Hi Justin,

I believe you will find the answer to which HTTP Status code the AS should
return if the token is INACTIVE in Section 3.1 Error Codes of "The OAuth 2.0
Framework: Bearer Token Usage" [RFC6750] which states:

3.1.  Error Codes

When a request fails, the resource server responds using the appropriate
HTTP status code (typically, 400, 401, 403, or 405) and includes one of the
following error codes in the response:

invalid_request 

The request is missing a required parameter, includes an unsupported
parameter or parameter value, repeats the same parameter, uses more than one
method for including an access token, or is otherwise malformed. The
resource server SHOULD respond with the HTTP 400 (Bad Request) status code.

invalid_token 

The access token provided is expired, revoked, malformed, or invalid for
other reasons. The resource SHOULD respond with the HTTP 401 (Unauthorized)
status code. The client MAY request a new access token and retry the
protected resource request. 

insufficient_scope 

The request requires higher privileges than provided by the access token.
The resource server SHOULD respond with the HTTP 403 (Forbidden) status code
and MAY include the scope attribute with the scope necessary to access the
protected resource.

If the request lacks any authentication information (e.g., the client was
unaware that authentication is necessary or attempted using an unsupported
authentication method), the resource server SHOULD NOT include an error code
or other error information.

For example:

  HTTP/1.1 401 Unauthorized  WWW-Authenticate: Bearer realm="example"

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA  92688-3836

Phone:      (949) 636-8571

Email:       [email-masked]
<mailto:[email-masked]> 

From: Justin Richer [mailto:[email-masked]] 
Sent: Tuesday, December 2, 2014 6:06 AM
To: Hannes Tschofenig; [email-masked]
Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01

Hi Justin,

* Terminology

I tried to avoid the word "client" for this very reason. The draft used to
say "client or protected resource" throughout, but in a few years of
deployment experience it's become clear that it's pretty much just protected
resources that need to do introspection so I changed that text throughout. I
don't think that "introspection client" will help here because the party
already has a name from OAuth and we should inherit it.

* Scope

I think the document should be clear that it *specifies* the mechanism for
bearer tokens, since that's the only OAuth token type that's defined
publicly right now, and that the details for PoP will have to be specified
in another spec -- that's exactly what Appendix C is there for, and if that
can be clearer, please suggest better text.

However, I think it's very clear how PoP tokens would work. You send the
value returned as the "access_token" in the token endpoint response, which
is effectively the public portion of the PoP token. Just like a bearer
token, this value is passed as-is from the client to the RS and would be
passed as-is from the RS to the AS during introspection. The AS can then use
that to look up the key and return it in an as-yet-unspecified field so that
the RS can validate the request. The RS wouldn't send the signature or
signed portion of the request for the AS to validate -- that's a bad idea.
But these are all details that we can work out in the PoP-flavored
extension. As I noted in the other thread, we'll have to make a similar
extension for Revocation, so I still don't think it makes sense to hold up
this work and wait for PoP to be finished because it's useful now, as-is.

 
* Meta-Information

The idea was to inherit JWT's syntax and semantics, at least on the wire,
and add additional fields. It probably makes sense to just inherit the JWT
registry, so we can do that.

When you write:
 
"

Noted, will add.

* Security

I had similar thoughts when putting draft -01 together but didn't want to
make a normative change like that without the WG input. I'm fine with
strengthening this to a MUST, since as far as I'm aware that's how it works
in all existing implementations (can anyone else comment on this?). I'm less
comfortable with making one particular mechanism MTI, since I know of
implementations that use either a special set of credentials passed just
like client credentials to the token endpoint, or an OAuth token
specifically for the introspection endpoint. If we do standardize on one MTI
form, I'd suggest that we make it the OAuth bearer token.

* SHOULDs

Noted, thanks. 

* Minor items
 
You write:
 
"
These include using

* 'Active' claim
 
you write:
"

It's not an error, really. It's a valid request and valid response saying
that token isn't any good. It would be easy enough to change the returned
error code on the {active:false} response, but to which code? The request
isn't Forbidden, or Not Found (the token could have been found but it's been
deactivated or just not available to the RS that's asking for it), or
Unauthorized, or even a Bad Request. So my logic is that the response is
"OK", but the content of the response tells you the metadata about the
token, which is that it's not active. 

* Capitalization

Thanks, still breaking old Bad Habits of capitalizing Terms In The Document.
Tried to clean it up, will do more.

* AS <-> RS relationship
 
You write:
"
   Since

What I was trying to point out is that it doesn't define the nature of the
relationship between the two components. Specifically, it says:

This spec provides one mechanism for this validation. So we could reference
this directly if that's helpful. 

  -- Justin

Ciao
Hannes

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

---

From: Thomas Broyer <[email-masked]>
Date: Tue, 02 Dec 2014 17:33:51 +0000

So what?

The request is OK (no missing parameter, etc.) so a 400 is not appropriate
(it could still be used, but you couldn't tell what went wrong without
*also* having some well-defined error response document format; and an
"invalid_token" error code wouldn't work if you're also using token
authentication passed in the form-encoded body ⇒ too much confusion, not
worth it).

401 or 403 are obviously not appropriate either.

I'm +1000 on keeping the 200 OK response with {"active":false} JSON
response.

On Tue Dec 02 2014 at 18:27:03 Donald Coffin <[email-masked]>
wrote:

> return if the token is INACTIVE in Section 3.1 Error Codes of “The OAuth
> 2.0 Framework: Bearer Token Usage” [RFC6750] which states:
>
>
>
> 3.1.  Error Codes
>
> *invalid_request*
> parameter or parameter value, repeats the same parameter, uses more than
> one method for including an access token, or is otherwise malformed. The
> *invalid_token*
> *insufficient_scope*
> The resource server SHOULD respond with the HTTP 403 (Forbidden) status
> code and MAY include the scope attribute with the scope necessary to access
> the protected resource.
>
>
>
> authentication method), the resource server SHOULD NOT include an error
> code or other error information.
>
>
>
> For example:
>
> *From:* Justin Richer [mailto:[email-masked]]
> *Sent:* Tuesday, December 2, 2014 6:06 AM
> *To:* Hannes Tschofenig; [email-masked]
> *Subject:* Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01
>
>
>
> passed as-is from the RS to the AS during introspection. The AS can then
> use that to look up the key and return it in an as-yet-unspecified field so
> that the RS can validate the request. The RS wouldn't send the signature or
> in all existing implementations (can anyone else comment on this?). I'm
> less comfortable with making one particular mechanism MTI, since I know of
> specifically for the introspection endpoint. If we do standardize on one
> MTI form, I'd suggest that we make it the OAuth bearer token.
>
>
> * SHOULDs
>
>
>
> isn't Forbidden, or Not Found (the token could have been found but it's
> been deactivated or just not available to the RS that's asking for it), or

---

From: "Richer, Justin P." <[email-masked]>
Date: Tue, 2 Dec 2014 18:19:17 +0000

No, this isn't an appropriate mapping in this case, especially if the introspection endpoint is itself OAuth protected. You need to be able to differentiate between the token being asked about and the token authorizing the question. These error codes apply to the latter and should not be conflated with the former.

 -- Justin

On Dec 2, 2014, at 12:25 PM, Donald Coffin <[email-masked]<mailto:[email-masked]>> wrote:

Hi Justin,

I believe you will find the answer to which HTTP Status code the AS should return if the token is INACTIVE in Section 3.1 Error Codes of “The OAuth 2.0 Framework: Bearer Token Usage” [RFC6750] which states:

3.1.  Error Codes
When a request fails, the resource server responds using the appropriate HTTP status code (typically, 400, 401, 403, or 405) and includes one of the following error codes in the response:

invalid_request
The request is missing a required parameter, includes an unsupported parameter or parameter value, repeats the same parameter, uses more than one method for including an access token, or is otherwise malformed. The resource server SHOULD respond with the HTTP 400 (Bad Request) status code.

invalid_token
The access token provided is expired, revoked, malformed, or invalid for other reasons. The resource SHOULD respond with the HTTP 401 (Unauthorized) status code. The client MAY request a new access token and retry the protected resource request.

insufficient_scope
The request requires higher privileges than provided by the access token. The resource server SHOULD respond with the HTTP 403 (Forbidden) status code and MAY include the scope attribute with the scope necessary to access the protected resource.

If the request lacks any authentication information (e.g., the client was unaware that authentication is necessary or attempted using an unsupported authentication method), the resource server SHOULD NOT include an error code or other error information.

For example:

Best regards,
Don
Donald F. Coffin
Founder/CTO

REMI Networks

Phone:      (949) 636-8571
Email:       [email-masked]<mailto:[email-masked]>

From: Justin Richer [mailto:[email-masked]]
Sent: Tuesday, December 2, 2014 6:06 AM
To: Hannes Tschofenig; [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01

Hi Justin,

document.

* Terminology

Figure 4 of

I tried to avoid the word "client" for this very reason. The draft used to say "client or protected resource" throughout, but in a few years of deployment experience it's become clear that it's pretty much just protected resources that need to do introspection so I changed that text throughout. I don't think that "introspection client" will help here because the party already has a name from OAuth and we should inherit it.

* Scope

IETF meeting as well.

I think the document should be clear that it *specifies* the mechanism for bearer tokens, since that's the only OAuth token type that's defined publicly right now, and that the details for PoP will have to be specified in another spec -- that's exactly what Appendix C is there for, and if that can be clearer, please suggest better text.

However, I think it's very clear how PoP tokens would work. You send the value returned as the "access_token" in the token endpoint response, which is effectively the public portion of the PoP token. Just like a bearer token, this value is passed as-is from the client to the RS and would be passed as-is from the RS to the AS during introspection. The AS can then use that to look up the key and return it in an as-yet-unspecified field so that the RS can validate the request. The RS wouldn't send the signature or signed portion of the request for the AS to validate -- that's a bad idea. But these are all details that we can work out in the PoP-flavored extension. As I noted in the other thread, we'll have to make a similar extension for Revocation, so I still don't think it makes sense to hold up this work and wait for PoP to be finished because it's useful now, as-is.

* Meta-Information

registry from JWT?

The idea was to inherit JWT's syntax and semantics, at least on the wire, and add additional fields. It probably makes sense to just inherit the JWT registry, so we can do that.

When you write:

"

the query.

"

Noted, will add.

Anything security critical would be provider-specific, in which case it wouldn't ignore them.

* Security

the AS and the RS.

I had similar thoughts when putting draft -01 together but didn't want to make a normative change like that without the WG input. I'm fine with strengthening this to a MUST, since as far as I'm aware that's how it works in all existing implementations (can anyone else comment on this?). I'm less comfortable with making one particular mechanism MTI, since I know of implementations that use either a special set of credentials passed just like client credentials to the token endpoint, or an OAuth token specifically for the introspection endpoint. If we do standardize on one MTI form, I'd suggest that we make it the OAuth bearer token.

* SHOULDs

Noted, thanks.

* Minor items

You write:

"

These include using

"

* 'Active' claim

you write:

"

"

It's not an error, really. It's a valid request and valid response saying that token isn't any good. It would be easy enough to change the returned error code on the {active:false} response, but to which code? The request isn't Forbidden, or Not Found (the token could have been found but it's been deactivated or just not available to the RS that's asking for it), or Unauthorized, or even a Bad Request. So my logic is that the response is "OK", but the content of the response tells you the metadata about the token, which is that it's not active.

* Capitalization

etc. issue.

Thanks, still breaking old Bad Habits of capitalizing Terms In The Document. Tried to clean it up, will do more.

* AS <-> RS relationship

You write:

"

   Since

"

learn about the content.

the tokens.

What I was trying to point out is that it doesn't define the nature of the relationship between the two components. Specifically, it says:

   authorization server.
This spec provides one mechanism for this validation. So we could reference this directly if that's helpful.

  -- Justin

Ciao

Hannes

OAuth mailing list

[email-masked]<mailto:[email-masked]>

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

---

From: Bill Mills <[email-masked]>
Date: Tue, 2 Dec 2014 18:40:16 +0000 (UTC)

"However, I think it's very clear how PoP tokens would work. ..." 
I don't know if that's true.  POP tokens (as yet to be fully defined) would then also have a TLS or transport security requirement unless there is token introspection client auth in play I think.  Otherwise I can as an attacker take that toklen and get info about it that might be useful, and I don't think that's what we want.
-bill

     On Tuesday, December 2, 2014 6:06 AM, Justin Richer <[email-masked]> wrote:

  
 Hi Justin,

* Terminology

 

 * Scope

 

 * Meta-Information

 

 When you write:

"

 Noted, will add.

 * Security

 

 * SHOULDs

 Noted, thanks. 

 * Minor items

You write:

"
These include using

 * 'Active' claim

you write:
"

 * Capitalization

 * AS <-> RS relationship

You write:
"
   Since

 
 
   authorization server. This spec provides one mechanism for this validation. So we could reference this directly if that's helpful. 
 
   -- Justin

 Ciao
Hannes

---

From: "Donald Coffin" <[email-masked]>
Date: Tue, 2 Dec 2014 10:49:02 -0800

Justin,

Thanks for the clarification.

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

Phone:      (949) 636-8571

From: Richer, Justin P. [mailto:[email-masked]] 
Sent: Tuesday, December 2, 2014 10:19 AM
To: Donald Coffin
Cc: Justin Richer; Hannes Tschofenig; [email-masked]
Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01

No, this isn't an appropriate mapping in this case, especially if the
introspection endpoint is itself OAuth protected. You need to be able to
differentiate between the token being asked about and the token authorizing
the question. These error codes apply to the latter and should not be
conflated with the former. 

 -- Justin

On Dec 2, 2014, at 12:25 PM, Donald Coffin <[email-masked]
<mailto:[email-masked]> > wrote:

Hi Justin,

3.1.  Error Codes

invalid_request 

invalid_token 

insufficient_scope 

For example:

 

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

Phone:      (949) 636-8571

From: Justin Richer [mailto:[email-masked]] 
Sent: Tuesday, December 2, 2014 6:06 AM
To: Hannes Tschofenig; [email-masked] <mailto:[email-masked]> 
Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01

Hi Justin,

* Terminology

* Scope

 
 
* Meta-Information

When you write:
 
"

Noted, will add.

* Security

* SHOULDs

Noted, thanks. 

* Minor items
 
You write:
 
"
These include using

* 'Active' claim
 
you write:
"

* Capitalization

* AS <-> RS relationship
 
You write:
"
   Since

  -- Justin

Ciao
Hannes

---

From: "Richer, Justin P." <[email-masked]>
Date: Tue, 2 Dec 2014 19:05:02 +0000

The call to introspection has a TLS requirement, but the call to the RS wouldn't necessarily have that requirement. The signature and the token identifier are two different things. The identifier doesn't do an attacker any good on its own without the verifiable signature that's associated with it and the request. What I'm saying is that you introspect the identifier and get back something that lets you, the RS, check the signature.

 -- Justin

On Dec 2, 2014, at 1:40 PM, Bill Mills <[email-masked]<mailto:[email-masked]>> wrote:

-bill

On Tuesday, December 2, 2014 6:06 AM, Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:

Hi Justin,

* Terminology

* Scope

* Meta-Information

When you write:

"

Noted, will add.

* Security

* SHOULDs

Noted, thanks.

* Minor items

You write:

"
These include using

* 'Active' claim

you write:
"

* Capitalization

* AS <-> RS relationship

You write:
"
   Since

  -- Justin

Ciao
Hannes

---

From: Bill Mills <[email-masked]>
Date: Tue, 2 Dec 2014 19:09:13 +0000 (UTC)

Fetching the public key for a token might be fine, but what if the introspection endpoint returns the symmetric key?  Data about the user?  Where does this blur the line between this and "act on behalf of"? 

     On Tuesday, December 2, 2014 11:05 AM, "Richer, Justin P." <[email-masked]> wrote:

 The call to introspection has a TLS requirement, but the call to the RS wouldn't necessarily have that requirement. The signature and the token identifier are two different things. The identifier doesn't do an attacker any good on its own without the verifiable signature that's associated with it and the request. What I'm saying is that you introspect the identifier and get back something that lets you, the RS, check the signature.
 -- Justin
On Dec 2, 2014, at 1:40 PM, Bill Mills <[email-masked]> wrote:

---

From: "Richer, Justin P." <[email-masked]>
Date: Tue, 2 Dec 2014 19:13:16 +0000

That's all fine -- it's all going over TLS anyway (RS->AS) just like the original token fetch by the client (C->AS). Doesn't mean you need TLS *into* the RS (C->RS) with a good PoP token.

Can you explain how this is related to "act on behalf of"? I don't see any connection.

 -- Justin

On Dec 2, 2014, at 2:09 PM, Bill Mills <[email-masked]<mailto:[email-masked]>> wrote:

On Tuesday, December 2, 2014 11:05 AM, "Richer, Justin P." <[email-masked]<mailto:[email-masked]>> wrote:

 -- Justin

-bill

---

From: Bill Mills <[email-masked]>
Date: Tue, 2 Dec 2014 19:25:02 +0000 (UTC)

If introspection returns any other user data beyond what is strictly required to validate the token based solely on possession of the public part it would be a mistake. 

     On Tuesday, December 2, 2014 11:13 AM, "Richer, Justin P." <[email-masked]> wrote:

 That's all fine -- it's all going over TLS anyway (RS->AS) just like the original token fetch by the client (C->AS). Doesn't mean you need TLS *into* the RS (C->RS) with a good PoP token. 
Can you explain how this is related to "act on behalf of"? I don't see any connection.
 -- Justin
On Dec 2, 2014, at 2:09 PM, Bill Mills <[email-masked]> wrote:

---

From: John Bradley <[email-masked]>
Date: Tue, 2 Dec 2014 16:25:17 -0300

+1
> On Dec 2, 2014, at 3:19 PM, Richer, Justin P. <[email-masked]> wrote:
> 
> On Dec 2, 2014, at 12:25 PM, Donald Coffin <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> Hi Justin,
>>  
>> Email:       [email-masked] <mailto:[email-masked]>
>>  
>> From: Justin Richer [mailto:[email-masked] <mailto:[email-masked]>] 
>> http://www.ietf.org/id/draft-ietf-oauth-pop-architecture-00.txt <http://www.ietf.org/id/draft-ietf-oauth-pop-architecture-00.txt>.
>>  
>> https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-31 <https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-31>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>  
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

---

From: "Richer, Justin P." <[email-masked]>
Date: Tue, 2 Dec 2014 19:56:35 +0000

Agreed, which is why we've got space for the "sub" and "user_id" fields but not anything else about the user, and we've got a privacy considerations section for dealing with that. If you can help make the wording on that section stronger, I'd appreciate it.

 -- Justin

On Dec 2, 2014, at 2:25 PM, Bill Mills <[email-masked]<mailto:[email-masked]>> wrote:

On Tuesday, December 2, 2014 11:13 AM, "Richer, Justin P." <[email-masked]<mailto:[email-masked]>> wrote:

 -- Justin

 -- Justin

-bill

---

From: John Bradley <[email-masked]>
Date: Tue, 2 Dec 2014 17:14:54 -0300

Many of the proprietary introspection protocols in use return scope, role or other meta data for the RS to make its access policy decision on.
One of the reasons for using opaque tokens rather than JWT is to prevent leakage of that info.

Making authentication to the introspection endpoint a MUST if additional attributes are present is OK,  I might even be inclined to say that authentication of some sort is always required, but that might be going a bit far for some use cases.

We have a lot of proprietary ways to do this from IBM, Layer 7, Ping etc.  It would be nice if we could standardize it.   Precluding other attributes would not be helpful for adoption.

One issue that we haven’t addressed in this spec is what happens if there are multiple AS for the RS and how it would decide what introspection endpoint to use.
Perhaps that needs to be a extension, leaving this for the simple case.

However having more than on e AS per RS is not as unusual as it once was in larger environments.

John B.

> On Dec 2, 2014, at 4:56 PM, Richer, Justin P. <[email-masked]> wrote:
> 
> On Dec 2, 2014, at 2:25 PM, Bill Mills <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> On Tuesday, December 2, 2014 11:13 AM, "Richer, Justin P." <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> On Dec 2, 2014, at 2:09 PM, Bill Mills <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>> On Tuesday, December 2, 2014 11:05 AM, "Richer, Justin P." <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> 
>>> On Dec 2, 2014, at 1:40 PM, Bill Mills <[email-masked] <mailto:[email-masked]>> wrote:
>>>

---

From: Bill Mills <[email-masked]>
Date: Tue, 2 Dec 2014 20:35:51 +0000 (UTC)

+1 for "Making authentication to the introspection endpoint a MUST if additional attributes are present is OK" 

     On Tuesday, December 2, 2014 12:15 PM, John Bradley <[email-masked]> wrote:

 Many of the proprietary introspection protocols in use return scope, role or other meta data for the RS to make its access policy decision on.One of the reasons for using opaque tokens rather than JWT is to prevent leakage of that info.
Making authentication to the introspection endpoint a MUST if additional attributes are present is OK,  I might even be inclined to say that authentication of some sort is always required, but that might be going a bit far for some use cases.
We have a lot of proprietary ways to do this from IBM, Layer 7, Ping etc.  It would be nice if we could standardize it.   Precluding other attributes would not be helpful for adoption.

One issue that we haven’t addressed in this spec is what happens if there are multiple AS for the RS and how it would decide what introspection endpoint to use.Perhaps that needs to be a extension, leaving this for the simple case.
However having more than on e AS per RS is not as unusual as it once was in larger environments.
John B.

Agreed, which is why we've got space for the "sub" and "user_id" fields but not anything else about the user, and we've got a privacy considerations section for dealing with that. If you can help make the wording on that section stronger, I'd appreciate it.
 -- Justin
On Dec 2, 2014, at 2:25 PM, Bill Mills <[email-masked]> wrote:

---

From: "Richer, Justin P." <[email-masked]>
Date: Tue, 2 Dec 2014 20:44:50 +0000

OK, I'm taking a note to make it a MUST in general in the next draft, and we can dial back from there if there are honest, specific use cases where it doesn't make sense.

Thanks.

 -- Justin

On Dec 2, 2014, at 3:35 PM, Bill Mills <[email-masked]<mailto:[email-masked]>> wrote:

On Tuesday, December 2, 2014 12:15 PM, John Bradley <[email-masked]<mailto:[email-masked]>> wrote:

John B.

On Dec 2, 2014, at 4:56 PM, Richer, Justin P. <[email-masked]<mailto:[email-masked]>> wrote:

 -- Justin

 -- Justin

 -- Justin

-bill

---

From: Eve Maler <[email-masked]>
Date: Tue, 2 Dec 2014 14:02:50 -0800

FWIW, UMA goes ahead and standardizes a good deal about the trust establishment between the RS and the AS, and (of course) profiles and wraps the token introspection spec as part of the resulting “authorization API” that the AS presents to the RS. A big part of the motivation for this is to support an n:n relationship between AS and RS entities.

	EVe

> On 2 Dec 2014, at 12:14 PM, John Bradley <[email-masked]> wrote:
> 
>> On Dec 2, 2014, at 4:56 PM, Richer, Justin P. <[email-masked] <mailto:[email-masked]>> wrote:
>> 

Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl

---

From: John Bradley <[email-masked]>
Date: Tue, 2 Dec 2014 22:13:49 +0000

Yes,  but unless there is something new the introspection endpoint in UMA is tied to the resource.   

In some cases having the token indicate the introspection endpoint may be useful. 

John B. 

Sent from my iPhone

> On Dec 2, 2014, at 10:02 PM, Eve Maler <[email-masked]> wrote:
>

---

From: "Richer, Justin P." <[email-masked]>
Date: Tue, 2 Dec 2014 22:26:57 +0000

I agree that there's some use in this (and in fact I've deployed a version that uses a signed JWT to indicate its authorization server), but it should remain outside the scope of this spec. It's a service discovery problem, it's orthogonal.

 -- Justin

On Dec 2, 2014, at 5:13 PM, John Bradley <[email-masked]<mailto:[email-masked]>> wrote:

John B.

Sent from my iPhone

On Dec 2, 2014, at 10:02 PM, Eve Maler <[email-masked]<mailto:[email-masked]>> wrote:

EVe

On 2 Dec 2014, at 12:14 PM, John Bradley <[email-masked]<mailto:[email-masked]>> wrote:

John B.

 -- Justin

 -- Justin

 -- Justin

-bill

---

From: Phil Hunt <[email-masked]>
Date: Tue, 2 Dec 2014 15:38:50 -0800

I am confused. Why would you call the introspection endpoint if you were not expecting new information to be disclosed?

Phil

> On Dec 2, 2014, at 14:26, Richer, Justin P. <[email-masked]> wrote:
> 
>> On Dec 2, 2014, at 5:13 PM, John Bradley <[email-masked]> wrote:
>>

---

From: Justin Richer <[email-masked]>
Date: Tue, 02 Dec 2014 20:04:44 -0500

Nothing says you need to pack the same information inside the JWT that 
you return from introspection. In our specific case, we don't put scopes 
or client IDs inside the JWT, just basic signature/identifier type 
stuff, so you need to call introspection to get back this other 
information. But the information inside the JWT includes an "iss" claim 
which the client can use to figure out *which* introspection endpoint to 
call.

This is just one of many different ways you could handle multiple AS at 
a single resource, and so it's definitely orthogonal to the basic 
introspection concept.

  -- Justin

On 12/2/2014 6:38 PM, Phil Hunt wrote:
> I am confused. Why would you call the introspection endpoint if you 
> were not expecting new information to be disclosed?
>
> Phil
>
> On Dec 2, 2014, at 14:26, Richer, Justin P. <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> I agree that there's some use in this (and in fact I've deployed a 
>> version that uses a signed JWT to indicate its authorization server), 
>> but it should remain outside the scope of this spec. It's a service 
>> discovery problem, it's orthogonal.
>>
>>  -- Justin
>>
>>
>>>> FWIW, UMA goes ahead and standardizes a good deal about the trust 
>>>> establishment between the RS and the AS, and (of course) profiles 
>>>> and wraps the token introspection spec as part of the resulting 
>>>> "authorization API" that the AS presents to the RS. A big part of 
>>>> the motivation for this is to support an n:n relationship between 
>>>> AS and RS entities.
>>>>
>>>> EVe
>>>>
>>>>> Many of the proprietary introspection protocols in use return 
>>>>> scope, role or other meta data for the RS to make its access 
>>>>> policy decision on.
>>>>> Making authentication to the introspection endpoint a MUST if 
>>>>> additional attributes are present is OK,  I might even be inclined 
>>>>> to say that authentication of some sort is always required, but 
>>>>> that might be going a bit far for some use cases.
>>>>>
>>>>> We have a lot of proprietary ways to do this from IBM, Layer 7, 
>>>>> Ping etc.  It would be nice if we could standardize it.   
>>>>> Precluding other attributes would not be helpful for adoption.
>>>>>
>>>>>
>>>>> One issue that we haven't addressed in this spec is what happens 
>>>>> if there are multiple AS for the RS and how it would decide what 
>>>>> introspection endpoint to use.
>>>>>> Agreed, which is why we've got space for the "sub" and "user_id" 
>>>>>> fields but not anything else about the user, and we've got a 
>>>>>> privacy considerations section for dealing with that. If you can 
>>>>>> help make the wording on that section stronger, I'd appreciate it.
>>>>>>
>>>>>>  -- Justin
>>>>>>
>>>>>>> If introspection returns any other user data beyond what is 
>>>>>>> strictly required to validate the token based solely on 
>>>>>>> possession of the public part it would be a mistake.
>>>>>>>
>>>>>>>
>>>>>>> On Tuesday, December 2, 2014 11:13 AM, "Richer, Justin P." 
>>>>>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>>>
>>>>>>>
>>>>>>> That's all fine -- it's all going over TLS anyway (RS->AS) just 
>>>>>>> like the original token fetch by the client (C->AS). Doesn't 
>>>>>>> mean you need TLS *into* the RS (C->RS) with a good PoP token.
>>>>>>>
>>>>>>>> Fetching the public key for a token might be fine, but what if 
>>>>>>>> the introspection endpoint returns the symmetric key?  Data 
>>>>>>>> about the user?  Where does this blur the line between this and 
>>>>>>>> "act on behalf of"?
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tuesday, December 2, 2014 11:05 AM, "Richer, Justin P." 
>>>>>>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> The call to introspection has a TLS requirement, but the call 
>>>>>>>> to the RS wouldn't necessarily have that requirement. The 
>>>>>>>> signature and the token identifier are two different things. 
>>>>>>>> The identifier doesn't do an attacker any good on its own 
>>>>>>>> without the verifiable signature that's associated with it and 
>>>>>>>> the request. What I'm saying is that you introspect the 
>>>>>>>> identifier and get back something that lets you, the RS, check 
>>>>>>>> the signature.
>>>>>>>>
>>>>>>>>  -- Justin
>>>>>>>>
>>>>>>>>> I don't know if that's true.  POP tokens (as yet to be fully 
>>>>>>>>> defined) would then also have a TLS or transport security 
>>>>>>>>> requirement unless there is token introspection client auth in 
>>>>>>>>> play I think.  Otherwise I can as an attacker take that toklen 
>>>>>>>>> and get info about it that might be useful, and I don't think 
>>>>>>>>> that's what we want.
>>>>>>>>>
>>>>>>>>> -bill
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>

---

From: Phil Hunt <[email-masked]>
Date: Tue, 2 Dec 2014 17:25:58 -0800

I was asking in the context of the thread where the comment was made that you only need to authenticate if more information is provided.

This didn’t make sense to me. Because you would never make the call to re-confirm (pointless). Even a caller re-confirming is actually checking for more information - to see if the assertion has been revoked.

Phil

@independentid
www.independentid.com
[email-masked]

> On Dec 2, 2014, at 5:04 PM, Justin Richer <[email-masked]> wrote:
> 
> Nothing says you need to pack the same information inside the JWT that you return from introspection. In our specific case, we don't put scopes or client IDs inside the JWT, just basic signature/identifier type stuff, so you need to call introspection to get back this other information. But the information inside the JWT includes an "iss" claim which the client can use to figure out *which* introspection endpoint to call.
> 
> This is just one of many different ways you could handle multiple AS at a single resource, and so it's definitely orthogonal to the basic introspection concept.
> 
>  -- Justin
> 
>> On Dec 2, 2014, at 14:26, Richer, Justin P. <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>> On Dec 2, 2014, at 5:13 PM, John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>>> On Dec 2, 2014, at 10:02 PM, Eve Maler <[email-masked] <mailto:[email-masked]>> wrote:
>>>> 
>>>>>> On 2 Dec 2014, at 12:14 PM, John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>> 
>>>>> Eve Maler                                  http://www.xmlgrrl.com/blog <http://www.xmlgrrl.com/blog>
>>>>> +1 425 345 6756                         http://www.twitter.com/xmlgrrl <http://www.twitter.com/xmlgrrl>
>>>