+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 | Skype: xmlgrrl | Twitter: @xmlgrrl

On Mon, Jan 2, 2017 at 5:46 AM, Justin Richer mailto:jricher@mit.edu> wrote:

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. o 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 tel:%28425%29%20345-6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org mailto:WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma http://kantarainitiative.org/mailman/listinfo/wg-uma

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org mailto:WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma http://kantarainitiative.org/mailman/listinfo/wg-uma

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

Hm.... should we not be distinguishing between access tokens & refresh tokens? As I understand it, access tokens are intended to be transient (hence should not be cached?) - whereas refresh tokens are intended to be persistent (and therefore could be cached, depending on the implementation specifics)? --&e On Wed, Jan 4, 2017 at 8:47 PM, Eve Maler wrote:

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 <(425)%20345-6756> | Skype: xmlgrrl | Twitter: @xmlgrrl

On Wed, Jan 4, 2017 at 9:24 AM, George Fletcher < george.fletcher@teamaol.com> 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 wrote:

...

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

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

-- Andrew Hindle Hindle Consulting Limited +44 7966 136543 -- ------------------------------ Hindle Consulting Limited is a company registered in England and Wales. Company number: 8888564. Registered office: Claremont House, Deans Court, Bicester, Oxfordshire OX26 6BW, UK.

Resource servers never see refresh tokens, they only go from the client to the AS. The AS doesn't need to "Cache" anything about the token as it's the canonical source of information about the refresh token anyway. The client doesn't need to "cache" anything about the refresh token (or access token for that matter) because it just uses the token until the token stops working. So we don't need to differentiate here because we're only talking about access tokens and none of this applies to refresh tokens. -- Justin On 1/6/2017 3:25 AM, Andrew Hindle wrote:

Hm.... should we not be distinguishing between access tokens & refresh tokens? As I understand it, access tokens are intended to be transient (hence should not be cached?) - whereas refresh tokens are intended to be persistent (and therefore could be cached, depending on the implementation specifics)?

--&e

On Wed, Jan 4, 2017 at 8:47 PM, Eve Maler mailto:eve@xmlgrrl.com> wrote:

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 tel:%28425%29%20345-6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

On Wed, Jan 4, 2017 at 9:24 AM, George Fletcher mailto:george.fletcher@teamaol.com> 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 tel:%28425%29%20345-6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

On Mon, Jan 2, 2017 at 5:46 AM, Justin Richer mailto:jricher@mit.edu> wrote:

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. o 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 tel:%28425%29%20345-6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org mailto:WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma http://kantarainitiative.org/mailman/listinfo/wg-uma

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org mailto:WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma http://kantarainitiative.org/mailman/listinfo/wg-uma

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org mailto:WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma http://kantarainitiative.org/mailman/listinfo/wg-uma

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org mailto:WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma http://kantarainitiative.org/mailman/listinfo/wg-uma

-- Andrew Hindle Hindle Consulting Limited +44 7966 136543 ------------------------------------------------------------------------ Hindle Consulting Limited is a company registered in England and Wales. Company number: 8888564. Registered office: Claremont House, Deans Court, Bicester, Oxfordshire OX26 6BW, UK.

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma