Looking at the 7662 Sec 4 wording, I think it does a nice comprehensive job
in all respects, including George's point:
"Consequently, an acceptable cache validity duration needs to be carefully
considered *given the concerns and sensitivities of the protected resource
being accessed* and the likelihood of a token being revoked or invalidated
in the interim period. *Highly sensitive environments can opt to disable
caching entirely* on the protected resource to eliminate the risk of stale
cached information entirely, again at the cost of increased network traffic
and server load."
Regarding inheriting, I think we can literally xref normatively to this
entire section (probably from our two relevant sections, token
introspection and security considerations just to be sure?) and be done
with it.
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
On Wed, Jan 4, 2017 at 9:24 AM, George Fletcher wrote: +1 for using 7662 Sec 4 In reality, the caching semantics need to be at the API/transaction level
and not just the RS. For example, using cached data for a read operation
may be fine, while using cached data to complete a $10K transaction may
not:) Thanks,
George On 1/3/17 11:10 PM, Eve Maler wrote: Regarding "taking the reading of the cache control semantics too far":
Yeeahh, I was kinda wondering about that. :-) Basing what we say on 7662
Sec 4 https://tools.ietf.org/html/rfc7662#section-4 sounds like a good
idea. *Eve Maler *Cell +1 425.345.6756 <(425)%20345-6756> | Skype: xmlgrrl |
Twitter: @xmlgrrl On Mon, Jan 2, 2017 at 5:46 AM, Justin Richer You're taking the reading of the cache control semantics too far. First off, the token introspection response is not covered by the cache semantics specified in 6749. In fact, 7662 specifically states: The response MAY be cached by the protected resource to improve
performance and reduce load on the introspection endpoint, but at the
cost of liveness of the information used by the protected resource to
make authorization decisions. And there's a big discussion of the tradeoffs of cacheing in section 4.
And the RS doesn't ever cache the token itself, but it could cache the
introspection results. As for the text from 6749 you referenced: The client is of course allowed
to store the tokens given to it by the AS. If it didn't, OAuth would be
kinda pointless, wouldn't it? What the cache control is all about is
preventing the HTTP response from the token endpoint from being cached. The
token response includes the token, but it is not the token as an entity. I think we should inherit the discussion and tradeoffs in 7662 section 4
for our token lifetime management (from the RS's perspective) in UMA. Some
APIs will want to cache tokens for performance, some will want to check
every single time. We should allow both and let API developers keep their
eyes open as for the differences.
-- Justin On 12/31/2016 2:29 PM, Eve Maler wrote: 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 <%28425%29%20345-6756> | Skype: xmlgrrl
| Twitter: @xmlgrrl _______________________________________________
WG-UMA mailing listWG-UMA@kantarainitiative.orghttp://kantarainitiative.org/mailman/listinfo/wg-uma _______________________________________________ WG-UMA mailing list
WG-UMA@kantarainitiative.org http://kantarainitiative.org/m
ailman/listinfo/wg-uma _______________________________________________
WG-UMA mailing listWG-UMA@kantarainitiative.orghttp://kantarainitiative.org/mailman/listinfo/wg-uma