RSR user_access_policy_uri: security considerations?

[xmlgrrl]

We have already noted that the AS should take precautions with URIs supplied by the RS intended for policy-setting interfaces. We actually have one provision in RSR where the URIs go the other way: the user_access_policy_uri property that's optionally on every response to a resource registration request. Shouldn't we mention the same cautions to the RS as to the AS, possibly stressing more forcefully in this case that the host and scheme should really match the known AS?

https://docs.kantarainitiative.org/uma/rec-oauth-resource-reg.html#rfc.section.2.3

[xmlgrrl]

While we're at it, we may want to take up #86, which considers what risk is entailed by the AS receiving legitimate information from the RS but then maliciously conveying it wrong/changing it in the policy-setting UX for the RO.

[xmlgrrl]

In UMA ad hoc telecon 2015-09-08 (which had quorum), this was the discussion and conclusion:

"Should the RS be suspicious of the AS with respect to the user_access_policy_uri? Domenico is thinking that the RS had better trust the AS! If it can’t trust that URI, then it can’t trust the RPTs etc. either, and we’re in real trouble. :-) We’ve already required TLS. But what if the AS has gone rogue in this case?

Maybe we can say something very brief about the fact that the RS must trust the AS for a lot, including this URI. What is the realistic risk? The RS, trying to do something convenient for the RO, could redirect the RO to a page that has malware in it. If the RS were to check that the URI is fully qualified and matches the known AS host and scheme, that would do a ton to mitigate the risk. At least it would be sending the RO to the same AS that it’s been dealing with all this time."

Eve will write up a brief statement to add.

[xmlgrrl]

We reviewed the new wording in UMA telecon 2015-09-10 and concluded it suffices.