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 On Dec 2, 2014, at 10:44 AM, Sergey Beryozkin <[email protected]> wrote: > Hi Justin, > On 02/12/14 15:36, Richer, Justin P. wrote: >>>> 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. >>> 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 >> >> 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. >> > 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 >> -- Justin >> >> >> >> >> On Dec 2, 2014, at 10:07 AM, Sergey Beryozkin <[email protected]> wrote: >> >>> Hi Justin >>> >>> Please see a comment below >>> >>> On 02/12/14 14:05, Justin Richer wrote: >>>> 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. >>>>> >>>>> 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. >>> 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, >>>> 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 >>>>> 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 >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
