Thanks for the update, there are still some unclear points
1. Is the metadata (introspection response) being returned from the authorization endpoint or from the token or a combination of both ? 2. "context" there may be no context other than the token, are you expecting the authorization endpoint to always keep a context of how/why the token was issued ? 3. The specification should clearly state which type of tokens are supported and what profiles/bindings are supported, like JWT Bearer, etc. 4. If I have an SAML Bearer assertion, and the SAML assertion is encrypted and have no way to know this, it can potentially fail if it can't be decrypted but as far as I can tell I'm not sending an encrypted token since this is just a SAML assertion, not sure how one really determines what is wrong 5. Should be spelled out what "active" is supposed to mean so folks get the same results on different endpoints From: Justin Richer [mailto:jric...@mit.edu] Sent: Sunday, November 30, 2014 6:57 PM To: Anthony Nadalin Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] draft-ietf-oauth-introspection 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 <tony...@microsoft.com<mailto:tony...@microsoft.com>> 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. Introspection Endpoint 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 OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
