<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br>Hi Gil, <br><br>This sound like a great project, in the UK at this time their is a massive row over the diabolical situation around consent based authorisation. &nbsp;The UK gov passed a policy to opt everyone in by default to share medical records, unless a citizen opts out. &nbsp;&nbsp;We have had some discussions about this use case and how consent receipt can address this. <br><br>check out&nbsp;<a href="https://medconfidential.org/">https://medconfidential.org/</a><div><br>It would be great to find some convergence in this regard and we definitely invite this use case in CIS WG at Kantara. <br><br>At the moment, we are very keen over the next month to develop a physical space or IOT use case for a Consent-based authorisation model (e.g. a consent Receipt/Sign) and a physical space notice registry. &nbsp;&nbsp;The ambition is to utilise the MVCR as a generic framework for consent-based authorisations regardless of the context. <br><br>Kind Regards,<br><br>Mark <br><br>On 22 Aug 2014, at 03:40, <a href="mailto:gil.kirkpatrick@viewds.com">gil.kirkpatrick@viewds.com</a> wrote:<br><br><blockquote type="cite">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.<br><br>-gil<br><br>------ Original Message ------<br>From: "Lionel Klee" &lt;<a href="mailto:Lionel.Klee@dia.govt.nz">Lionel.Klee@dia.govt.nz</a>&gt;<br>To: "Eve Maler" &lt;<a href="mailto:eve@xmlgrrl.com">eve@xmlgrrl.com</a>&gt;; "WG UMA" &lt;<a href="mailto:wg-uma@kantarainitiative.org">wg-uma@kantarainitiative.org</a>&gt;<br>Cc: "Mark Lizar" &lt;<a href="mailto:mark.lizar@gmail.com">mark.lizar@gmail.com</a>&gt;<br>Sent: 22/08/2014 12:33:55 PM<br>Subject: Re: [WG-UMA] Minimum Viable Consent Receipt draft spec<br><br><blockquote type="cite">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.<br><br>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.<br><br>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.<br><br>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.<br><br>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<br>an RP, it can't necessarily be assumed that the interaction context for consent provision is directly operated by the RP.<br><br>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.<br><br>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.<br><br>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.<br><br>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.<br><br>Lionel Klee<br>Principal Business Advisor<br>RealMe Programme | Digital Transformation<br>The Department of Internal Affairs Te Tari Taiwhenua<br>+64 4 463 1357<br>+64 21 618872<br><a href="http://www.dia.govt.nz">http://www.dia.govt.nz</a> <a href="http://www.realme.govt.nz">http://www.realme.govt.nz</a><br><br><br>-----Original Message-----<br>From: <a href="mailto:wg-uma-bounces@kantarainitiative.org">wg-uma-bounces@kantarainitiative.org</a> [<a href="mailto:wg-uma-bounces@kantarainitiative.org">mailto:wg-uma-bounces@kantarainitiative.org</a>] On Behalf Of Eve Maler<br>Sent: Wednesday, 20 August 2014 4:29 a.m.<br>To: WG UMA<br>Cc: Mark Lizar<br>Subject: [WG-UMA] Minimum Viable Consent Receipt draft spec<br><br>The MVCR concept is gaining shape in the Kantara Information Sharing WG. Take a look at the draft spec...<br><br><a href="https://kantarainitiative.org/confluence/display/infosharing/Minimum+Viable+Consent+Receipt+%28MVCR%29+Specification+v.05">https://kantarainitiative.org/confluence/display/infosharing/Minimum+Viable+Consent+Receipt+%28MVCR%29+Specification+v.05</a><br><br>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.<br><br>These are just random thoughts... Does anyone else have any on this topic?<br><br>Eve<br><br>Eve Maler http://www.xmlgrrl.com/blog<br>+1 425 345 6756 http://www.twitter.com/xmlgrrl<br><br>_______________________________________________<br>WG-UMA mailing list<br>WG-UMA@kantarainitiative.org<br>http://kantarainitiative.org/mailman/listinfo/wg-uma<br>_______________________________________________<br>WG-UMA mailing list<br>WG-UMA@kantarainitiative.org<br>http://kantarainitiative.org/mailman/listinfo/wg-uma<br></blockquote><br></blockquote><br></div></body></html>