[WG-UMA] Minimum Viable Consent Receipt draft spec

gil.kirkpatrick at viewds.com gil.kirkpatrick at viewds.com
Thu Aug 21 21:40:13 CDT 2014


We (ViewDS) are working with a research team at the University of 
Wollongong to develop a consent-based authorization model for electronic 
health care records here in Australia as well.

-gil

------ Original Message ------
From: "Lionel Klee" <Lionel.Klee at dia.govt.nz>
To: "Eve Maler" <eve at xmlgrrl.com>; "WG UMA" 
<wg-uma at kantarainitiative.org>
Cc: "Mark Lizar" <mark.lizar at gmail.com>
Sent: 22/08/2014 12:33:55 PM
Subject: Re: [WG-UMA] Minimum Viable Consent Receipt draft spec

>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.
>To: WG UMA
>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...
>
>https://kantarainitiative.org/confluence/display/infosharing/Minimum+Viable+Consent+Receipt+%28MVCR%29+Specification+v.05
>
>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
>
>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
>http://kantarainitiative.org/mailman/listinfo/wg-uma
>_______________________________________________
>WG-UMA mailing list
>WG-UMA at kantarainitiative.org
>http://kantarainitiative.org/mailman/listinfo/wg-uma



More information about the WG-UMA mailing list