Subject: [OAUTH-WG] draft-ietf-oauth-introspection

From: Anthony Nadalin <[email-masked]>
Date: Sun, 30 Nov 2014 18:01:24 +0000

Comments

Intro
"about the authentication conext", not sure what this is since there is no authentication context in Oauth
Use of Oauth2, mixed with use of Oauth, pick one
"allows holder of a token to query" so anything/anyone that has a token can use this endpoint?

Introspection Endpoint
Use of Oauth2, mixed with use of Oauth, pick one

Introspection Request
The endpoint SHOULD also require some form of authentication", what about some form of authorization ? Why do we have to have another endpoint that we have to manage and then have a management API draft?]

Token - is this any type of token ? how does the endpoint know that it can deal with this token type? So endpoint has to try to lookup token  to determine if it can maybe find out something about the token? Can the one use the authorization code or does one have to get a token first?

Can I send a encrypted token and expect a proper response ? What about a Proof of Possession Token?

Introspection Response
What is "active" mean ? Is this up to the server to determine ?
"scope OPTIONAL", is this the scope in the token or is this the scope that the introspection endpoint sources may have ? It's unclear if all these return values are from the token or from the introspection endpoint sources ?
What error codes/conditions are there? Just the 400  (bad request)?
Can the endpoint return a encrypted response ?
What about PII such as user_id, aud ?

---

From: Justin Richer <[email-masked]>
Date: Sun, 30 Nov 2014 21:57:26 -0500

Tony, thanks for the comments. Your timing is great, as I was just today sitting down to polish the introspection draft into a proper WG document ready for the last-call tomorrow. I’ve just posted the updated draft, and I think that you’ll find it addresses your concerns. More direct answers inline:

On Nov 30, 2014, at 1:01 PM, Anthony Nadalin <[email-masked]> wrote:

> Comments
>  
> Intro
> “about the authentication conext”, not sure what this is since there is no authentication context in Oauth

There are several authentication contexts in OAuth: the resource owner at the authorization endpoint, the client at the token endpoint, etc. Regardless, this is meant to be the context of the authorization decision, text now reads: "context in which the token was issued"

> Use of Oauth2, mixed with use of Oauth, pick one

All usage changed to “OAuth 2.0” throughout the document, let me know if I missed any.

> “allows holder of a token to query” so anything/anyone that has a token can use this endpoint?

Now reads authorized holder of the token and has stronger language and recommendations about requiring authorization on the endpoint to prevent public token fishing. This was already addressed in the security considerations section, but that has been propagated throughout the specification now. 

> Use of Oauth2, mixed with use of Oauth, pick one

See above.

> Introspection Request
> The endpoint SHOULD also require some form of authentication”, what about some form of authorization ? Why do we have to have another endpoint that we have to manage and then have a management API draft?]

This is now clearer that it needs to be an authorized protected resource. This authorization may be carried through a credential mechanism as defined in OAuth 2.0, through an access token, or through some other mechanism. 

>  
> Token – is this any type of token ? how does the endpoint know that it can deal with this token type?

Clarified that it’s either the access_token from the token endpoint or the refresh_token from the token endpoint. You can use this with other token types, but that’s not defined in this spec which concerns itself with RFC6749/RFC6750. 

> So endpoint has to try to lookup token  to determine if it can maybe find out something about the token?

That’s the idea, the protected resource is asking an authoritative source (the authorization server) about a given token. I had always thought it was obvious that the authorization server would have to be able to know something about the token in order to provide an introspection service, but since that seems to have been unclear to some I’ve made it explicit in the security considerations section. 

> Can the one use the authorization code or does one have to get a token first?

No, this is for tokens only. I don’t see the point of introspecting an authorization code — those aren’t sent to protected resources, they’re sent to clients, which would in turn just hand it to the token endpoint to get a token. There’s nothing else to find out about it.

>  Can I send a encrypted token and expect a proper response ?

If the server can decrypt or otherwise understand the token, yes. I’ve pointed out this requirement in the security considerations section. 

> What about a Proof of Possession Token?

Yes, I think this fits great with PoP tokens, but those aren’t defined well enough yet to say anything concrete. As the PoP work progresses, we can have an extension document to determine what needs to be done there. Note that we’ll have to do the same thing with the Revocation RFC.

>  Introspection Response
> What is “active” mean ? Is this up to the server to determine ?

It means the token is live, hasn’t been revoked, was actually issued by this server, isn’t expired, and the protected resource that’s asking has the right to know all that information. This is all up to the server to determine. If the server can’t determine that information for its own tokens, it probably shouldn’t be offering this service.

> “scope OPTIONAL”, is this the scope in the token or is this the scope that the introspection endpoint sources may have ? It’s unclear if all these return values are from the token or from the introspection endpoint sources ?

These are the scopes of the token. All return values are, as stated, metadata about the token itself that is being queried against.

> What error codes/conditions are there? Just the 400  (bad request)?

The errors are more clearly spelled out. Most of it involves bad client authentication (when client credentials are used), bad authorization (when access tokens are used to access the introspection endpoint itself), or the like. If the token being introspected isn’t good, that’s still a 200 response — the request is fine, but the token being introspected isn’t active, which is what’s returned. This isn’t an error, it’s a valid answer to the question of “what is this token?” that’s being asked every time introspection is called.

> Can the endpoint return a encrypted response ?

That’s outside the scope of this document. It returns JSON like the rest of OAuth.

> What about PII such as user_id, aud ?

This is now covered in the Privacy Considerations section, which wasn’t A Thing when this draft was first written.

 — Justin

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