> 1. Is the metadata (introspection response) being returned from the > authorization endpoint or from the token or a combination of both ?
As I said below, ultimately it’s about the token and what it represents. If the token was issued through use of the authorization endpoint, then it’s likely that there’s some context from that authorization endpoint tied to the token that can be returned. > 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 ? If you’re asking if stateless tokens can be supported with this, then yes, that’s fine. If the token’s completely on its own (like a structured token generated as an assertion and used as an OAuth 2.0 access token) and a server’s able to unpack that for a client without access to other pieces of context, then that’s what it returns. But in that case, if you’re issuing stateless tokens, with self-contained metadata and expirations and no other context to be conveyed beyond what’s already inside the token, then you’d probably just tell your protected resources how to parse and handle them directly. > 3. The specification should clearly state which type of tokens are > supported and what profiles/bindings are supported, like JWT Bearer, etc. That’s opaque to the protected resource for purposes of this protocol, just like a token is opaque to a client for purposes of 6749/6750 OAuth. The introspection protocol supports whatever tokens are supported by the AS, so we don’t need to list token types, but maybe we can be clearer about the opaqueness of the token value in this process. Since these are OAuth tokens and not assertions, no bindings or profiles are needed beyond this. It’s a simple query-response and it’s up to the server to know how to fulfill this contract. > 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 If the AS can’t decrypt the token then it can’t introspect it. So it doesn’t in this case. And if you’re issuing encrypted OAuth tokens with no means to decrypt them back at the AS, then you probably wouldn’t offer an introspection service to begin with. This is covered in the security considerations section already. > 5. Should be spelled out what “active” is supposed to mean so folks get > the same results on different endpoints As I said below, it means to answer “is this token still good or not?” for a protected resource that can’t answer that on its own, and I believe the current definition reflects that. Please submit text if the existing definition is insufficient or unclear to you. — Justin > > > From: Justin Richer [mailto:[email protected]] > Sent: Sunday, November 30, 2014 6:57 PM > To: Anthony Nadalin > Cc: [email protected] > 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 <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/oauth >
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
