+1 > On Dec 2, 2014, at 3:19 PM, Richer, Justin P. <jric...@mitre.org> wrote: > > 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 <donald.cof...@reminetworks.com > <mailto:donald.cof...@reminetworks.com>> 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: >> 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: donald.cof...@reminetworks.com >> <mailto:donald.cof...@reminetworks.com> >> >> From: Justin Richer [mailto:jric...@mit.edu <mailto:jric...@mit.edu>] >> Sent: Tuesday, December 2, 2014 6:06 AM >> To: Hannes Tschofenig; oauth@ietf.org <mailto:oauth@ietf.org> >> Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 >> >> Hannes, thanks for the review. Comments inline. >> >> On 12/2/2014 6:23 AM, Hannes Tschofenig wrote: >> 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 >> <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. >> >> 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 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. >> >> 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 >> >> You have replicated a lot of the claims defined in >> https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-31 >> <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. >> >> 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 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. >> >> Noted, will add. >> >> >> Of course, there is the question whether any of those would be security >> critical and hence ignoring them would cause problems?! >> >> Anything security critical would be provider-specific, in which case it >> wouldn't ignore them. >> >> >> * 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. >> >> 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 >> >> 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? >> >> Noted, thanks. >> >> >> * 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. >> >> I'm fine with that, didn't want to offend the SAML cabal but we can cut it. >> >> >> * '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. >> >> 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 >> >> Reading through the text I see bearer token/Bearer Token, Client/client, >> 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 >> 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. >> >> 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 >> >> >> >> >> >> Ciao >> Hannes >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
