XACML-style Obligations that the AS imposes on the RS

[xmlgrrl]

Andi's Enterprise-Cloud slide deck (http://kantarainitiative.org/confluence/download/attachments/17760302/0814-UMA-EnterpriseCloudUC-v2.pptx?api=v2) brings up this issue, and we also discussed it on UMA telecon 2014-08-06: http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2014-08-06

Nat points out the quite often, location-dependent obligations need to be imposed, e.g. at Boeing for highly sensitive data. Gil also points out document redaction scenarios. There are consumer and IoT scenarios as well.
Gil often advises people not to use Obligations in XACML because it's such a mess. It can be hard to apply obligations in the right order etc.; that is, interpretation of them is not obvious. Some have talked about an obligations-handling service. Yikes!
However, it can be useful for the AS to convey various kinds of information to the RS, e.g. in/associated with the RPT. Eve notes that this kind of feature is eminently profilable as part of either the existing "bearer" RPT token profile, or new profiles that are XACML-style.