[WG-UMA] Minimum Viable Consent Receipt draft spec

Lionel Klee Lionel.Klee at dia.govt.nz
Thu Aug 21 21:33:55 CDT 2014

In New Zealand, we're also looking at consent as the lynch pin for personal information sharing. We are working towards a design that will have a Consent Service as an independent component that stores consent records and issues consent tokens. This approach divides the functions that I understand are performed by the UMA Authorisation Manager in use cases such as SMART HEARs sharing into two distinct components - consent/permissions service and request mediation/brokering service. 

We currently have one brokering service for both the RPs and the attribute providers/RSs, but we are investigating the potential to split this into two co-operating brokering services - one for the RPs and one for the attribute providers. This means that the RP can ask for an attribute set - let's say residential address, without needing to know which particular RS can supply that information on behalf of the specific user. It also means that the RS doesn't necessarily need to use the same messaging technology as the RP. Currently our RP messaging for assertions/claims is SAML AuthnRequest rather than OAuth and OpenID.

This approach requires two different types of consent. The first user consent is to associate a particular RS with the brokering service. This is a one-time and typically enduring consent which informs the brokering service about which RSs can be used to potentially satisfy the RP's request. If there is no consent for an attribute type at an attribute provider, then the RS will not be queried. The second user consent is the one that is provided when the user chooses to release certain requested attributes to the RP for a particular transaction.
Compared to the challenging environment that Open Notice MVCP addresses, we are operating in a relatively benign federation ecosystem that is controlled and cooperative consisting of government agencies and regulated private sector organisations such as banks and other financial institutions - there isn't much probablity that personal information will be marketed to third parties without the user's permission or even without the organisation's disclosure of this intent. The likelihood of sanction for privacy breaches replaces the need for independent behaviour ranking.

The syntax of our consent token is evolving, and shares some of the elements in the MVCP consent receipt. A significant difference is that the we don't identify the resource owner/user, as any unique identifier including a pseudonymous identifier would allow two entities to match the customer and diminish their privacy (as per the UMA audit ID discussion). We are looking at a consent token design that can also work in multi-actor use cases. The MVCP consent receipt addresses the exchange between two actors - the customer and the service provider, in the TOS and privacy statement context. More complex situations include joined up business processes with a customer and two or more RPs, the generic UMA pattern with an RP, RO and AS as an intermediary, and a third party online service as a business process intermediary perhaps enabling the workflow for one or more RPs, several ROs and the brokering service. In short, while the user wants to allow an RS to provide personal data to an RP, it can't necessarily be assumed that the interaction context for consent provision is directly operated by the RP.

Although our consent token is identityless, the Consent Service itself is aware of the user's pseudonymous identity and it is able to respond to consent transactions with RPs or the brokering service via an STS pseudonymous authentication opaque token exchange. 

When the user adds a consent, there are two parts to the Consent Service record. One part is the consent audit that captures the sufficient details to describe the consent event, the type of consent and the parties involved. The second part is human readable descriptive information that's closely based on the WG-InfoSharing draft Sharing Label design. This is relatively static content that is provided by the RP and currently this is preconfigured rather than being transaction based. In comparison with MVCP consent receipt, this means that descriptive elements such as purpose, location and third party sharing policy can be accessed by the user or other parties, but these don't have to be transmitted in the consent token. 

Each attribute provider/RS can choose whether it simply wants to trust that the brokering service has correctly obtained the user's consent, or whether it specifically wants to test the contents of the consent token or use it to maintain a comprehensive audit record for the information sharing request.

That's fairly much our current set of ideas about the means for handling consent and assertions/claims in a user-centric, privacy protective manner. Although our current implementation uses SAML messaging, our intention is that the pattern should be agnostic and could be UMAfied with OAuth/OpenID, or perhaps also support some custom exchanges where the RS brokering service needs to queue requests to a legacy or batch RS/attribute provider.

Lionel Klee
Principal Business Advisor
RealMe Programme | Digital Transformation
The Department of Internal Affairs Te Tari Taiwhenua
+64 4 463 1357
+64 21 618872
http://www.dia.govt.nz http://www.realme.govt.nz

-----Original Message-----
From: wg-uma-bounces at kantarainitiative.org [mailto:wg-uma-bounces at kantarainitiative.org] On Behalf Of Eve Maler
Sent: Wednesday, 20 August 2014 4:29 a.m.
Cc: Mark Lizar
Subject: [WG-UMA] Minimum Viable Consent Receipt draft spec

The MVCR concept is gaining shape in the Kantara Information Sharing WG. Take a look at the draft spec...


I could see a nice intersection of UMA and consent receipts where "claim-gathering" happens, and there are likely tie-ins to the auditing discussion as well. The RO could demand a consent receipt, or a promise to deliver a consent receipt, as a claim through his/her policy. A claims-gathering profile could potentially add the ability for the AS to supply information (could be an audit ID? and also maybe an RO pseudonymous identifier for the client to reference?) to the client in passing along the requirement for the claim, along with standardizing the semantics of the required claim.

These are just random thoughts... Does anyone else have any on this topic?


Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl

WG-UMA mailing list
WG-UMA at kantarainitiative.org

More information about the WG-UMA mailing list