[WG-UMA] Minimum Viable Consent Receipt draft spec

Adrian Gropper agropper at healthurl.com
Fri Aug 29 10:59:29 CDT 2014


This Guidance on implementing the 42 CFR Part 2 regulations on sharing of
sensitive information is useful in considering the use-case(s).

Adrian


On Fri, Aug 29, 2014 at 11:39 AM, Eve Maler <eve at xmlgrrl.com> wrote:

> (Not to weigh in on Adrian's question directly, but just to remind folks
> of a related resource...) Our analysis of UMA wrt the PbD principles is
> here:
>
> http://tinyurl.com/umapbd
>
> On 29 Aug 2014, at 7:23 AM, Adrian Gropper <agropper at healthurl.com> wrote:
>
> UMA allows, but does not require, the AS to be co-located with a Personal
> Data Store.
>
> To the extent we're trying to map PbD into UMA, does it make sense to fork
> the MVCS discussion into two different cases where the UMA AS is or is not
> under the personal control of the RO?
>
> Adrian
>
>
> On Thu, Aug 28, 2014 at 10:16 PM, Lionel Klee <Lionel.Klee at dia.govt.nz>
> wrote:
>
>>  Mark,
>>
>>
>>
>> Thanks for your response. Our overall programme was initiated in the
>> government domain, but a few years ago it was realised that there is a
>> significant overlap between government and private sector services, and
>> that working in conjunction with the private sector would bring more viable
>> economies of scale. The focus is now on a citizen's digital interactions
>> with "New Zealand Incorporated", although it would be fair to say that the
>> realistic boundaries are still being established. Banks and other financial
>> institutions are already participating and it's likely that education,
>> health and social service providers will also become involved - these are
>> typically organisations that are well trusted by the citizen.
>>
>>
>>
>> It's early days, and at this stage the RS/attribute providers are only
>> authoritative sources of information - government verified identity, NZ
>> Post verified address, and in due course other elements like tax number,
>> immigrant visa status, etc. Despite a substantial demand for self-asserted
>> information such as phone numbers, email address, and so forth, we have yet
>> to work out how to incorporate a citizen controlled personal data store.
>> Undoubtedly 'personal cloud services' will become ubiquitous, but until
>> this happens, we feel that the privacy concerns related to just a few
>> commercial operators providing 'vault' services (and potentially exploiting
>> this personal information) probably outweighs the online usability benefits
>> that would be delivered.
>>
>>
>>
>> Our latest architectural thinking hasn't been documented yet, as we're
>> part way through adjusting some of the pieces in the jigsaw where we
>> discovered that we had incorporated some potential constraints. For
>> example, the requesting party doesn't necessarily need to know which RS can
>> satisfy the attribute request; and, while the user at the RP expects a
>> real-time response, the attributes may not always need to be returned in
>> the session, but instead queued for delivery by another means or at another
>> time. Documentation on our current architecture is available in WG-egov -
>> https://kantarainitiative.org/confluence/display/eGov/Privacy+Enhanced+WebSSO,
>> including our existing approach to consent.
>>
>>
>>
>> Once we've done a bit more work on the changes that we are looking at we
>> can share the resulting documentation and consider how this fits with
>> initiatives such as the trust registry. I'd also like to contribute towards
>> restarting the work in the other branch of WG-InfoSharing around the
>> sharing label - in particular the user interface aspects around consent.
>> However, I'm going to be on holiday for the first three weeks of September,
>> so there will be a break in my active involvement with this work.
>>
>>
>>
>> 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
>>
>>
>>
>>
>>
>> *From:* Mark L [mailto:mark.lizar at gmail.com]
>> *Sent:* Wednesday, 27 August 2014 5:27 a.m.
>> *To:* Lionel Klee
>> *Cc:* Eve Maler; WG UMA; wg-infosharing at kantarainitiative.org
>> *Subject:* Re: [WG-UMA] Minimum Viable Consent Receipt draft spec
>>
>>
>>
>> Dear Lionel,
>>
>>
>>
>> This is great stuff thanks for posting.   The MVCR is intended to be a
>> personal data control facilitator that can work with existing IdM
>> architecture.   The intent is to focus on the social and legal elements and
>> provide a privacy by design solution at the cross roads of identity
>> management and basic data control signalling.   In other words the
>> intention is to make something that is generically usable for other
>> purposes, protocols, trust services  focused on personal data control (like
>> UMA).
>>
>>
>>
>> There are many modes of operendi in this space.  I like the RPs and RS
>> architecture you post below.  I think this may be very similar to an
>> architecture we are working on that has a distributed model in which the
>> data subject has control with a personal data store. Do you have a diagram
>> of this architecture?
>>
>>
>>
>>
>>
>> Where a data subject has/controls an authoritative source for data
>> sharing and preferences for (real me).  This is in the form of a open
>> personal data store or pcloud.    A data subject uses a receipt to inform a
>> service provider to share information, use preferences, by sending a link
>> to this pcloud with these resources/policies available. This context is
>> similar to the third party brokering service you mention.
>>
>>
>>
>> In this regard is the RS something akin to a personal cloud service (open
>> data store) ?
>>
>>
>>
>> As for the SAML approach you have this is also very interesting as we are
>> working on a registry for open notices (privacy policies, terms of
>> services) and we are examining the Kantara SAML Registry to see if and how
>> the Open Notice Registry may fit.  Here is the link:
>>
>>
>>
>> https://kantarainitiative.org/trust-registry/
>>
>>
>>
>> The general idea being of creating a consent receipt/token for people
>> that corresponds with SAML tokens.    Perhaps we can trade some
>> architecture diagrams and work on a case study.
>>
>>
>>
>> Also can you confirm that your architecture is government focused?
>>
>>
>>
>> (Open government context is a popular topic in which people/gov want
>> citizens to be able to see how their data is shared across government
>> departments. This is very similar to the basic 3rd party sharing scenario
>> that most people in this space are familiar with. Its also an NSTIC/IDSEG
>> focus and a focus in the EU funding call that is closing this week )
>>
>>
>>
>> Perhaps we can collaborate on this Use Case (with the SAML Registry) if
>> this is the case.
>>
>>
>>
>> Kind Regards,
>>
>>
>>
>> Mark
>>
>>
>>
>>
>>
>> On 22 Aug 2014, at 03:33, Lionel Klee <lionel.klee at dia.govt.nz> wrote:
>>
>>
>>
>> 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
>> <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
>>
>>
>
>
> --
> Adrian Gropper MD
> _______________________________________________
> WG-UMA mailing list
> WG-UMA at kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/wg-uma
>
>
>
> Eve Maler                                  http://www.xmlgrrl.com/blog
> +1 425 345 6756                         http://www.twitter.com/xmlgrrl
>
>


-- 
Adrian Gropper MD
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kantarainitiative.org/pipermail/wg-uma/attachments/20140829/aeebc386/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: HITPC_PSTT_DS4P_2014-06-10.pdf
Type: application/pdf
Size: 256209 bytes
Desc: not available
URL: <http://kantarainitiative.org/pipermail/wg-uma/attachments/20140829/aeebc386/attachment-0001.pdf>


More information about the WG-UMA mailing list