[WG-UMA] Minimum Viable Consent Receipt draft spec

Adrian Gropper agropper at healthurl.com
Fri Aug 29 09:23:32 CDT 2014


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kantarainitiative.org/pipermail/wg-uma/attachments/20140829/23d9e4de/attachment-0001.html>


More information about the WG-UMA mailing list