In our 2016-11-10 telecon http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-11-10?s..., we said: *"Sec 3.4: The RS has the option of using cached RPT status results, so include this in the options (has swimlane implications?). This is also an AS TTL strategy thing (including revocation and disconnected RS scenarios, e.g. IoT scenarios), which we should comment on if we haven't already.* - *Add companion security considerations around TTL for RPTs and permissions, since you need to measure risk and risk appetite based on the RS, the resource itself, and even the nature of the policy conditions etc. Without active revocation infrastructure, the risks are higher."* So I poked around the OAuth spec to see if there's similar wording I could align with, and discovered this in Sec 5.1 https://tools.ietf.org/html/rfc6749#section-5.1: *"The authorization server MUST include the HTTP "Cache-Control" response header field [RFC2616] with a value of "no-store" in any response containing tokens, credentials, or other sensitive information, as well as the "Pragma" response header field [RFC2616] with a value of "no-cache"."* So...I believe this means the client isn't allowed to cache tokens given to it by the AS, and maybe the RS isn't allowed to cache token introspection responses given to it if the token introspection spec follows along in this pattern. But the RS is allowed to cache tokens that the client brings to it because this isn't an AS response, but rather a client request. And if it has locally validated those tokens, it can hang onto the results as long as it wants as well. I looked a little further, at the OAuth Threat Model spec, and there's potentially some broadly suggestive text in Sec 4.6.6 https://tools.ietf.org/html/rfc6819#section-4.6.6 about both clients and RS's using Cache-Control: private to protect against leakage through HTTP proxies, but nothing more directly relevant. Some specific questions for people to react to: - Is my interpretation above about the RS's abilities correct? With an analysis of who can cache what completed, would anyone agree it might be helpful to put the result into the spec as a "Note" observation so others don't have to repeat the exercise and possibly get it wrong? - Our spec says it "mainly relies on OAuth" for security considerations. Does this mean we must pick up on the prohibition against the AS letting the recipient cache things? I don't think so because it's in the main body of the spec. - Do we therefore want to *add* similar wording for the same security reasons OAuth itself has that wording? - What exactly should our security consideration about TTL of permissions and RPTs say? I think it should cover the circumstances of both local validation and caching. I could use wording similar to what our telecon notes say, but the trick is that the RS doesn't have access to the policy conditions. However, it does have "Adrian clause" rights it may want to apply, so we could mention that. - In fact, I'm starting to think that a more extended discussion in the Federated Authorization section about this concept -- the fact that the RS retains "edge (local?) authorization" rights -- would be useful to point to from more than one other location in the spec, including this new Security Considerations section. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl