- WG-UMA - mailman.kantarainitiative.org

Draft minutes of UMA telecon 2020-03-26
by Eve Maler 26 Mar '20

26 Mar '20

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-03-26 MinutesInterim meeting We will hold an interim meeting on *Apr 2* to discuss the proposed extension(s) in more depth. Eve will put it on the calendar. Roll call Quorum was reached. Approve minutes - - Approve minutes of UMA telecon 2020-03-12 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-03-12> Minutes APPROVED by acclamation. AdvCIS liaison report Report from Mark/Tim on Notice & Consent project <https://kantarainitiative.org/confluence/pages/viewpage.action?pageId=12546…> and next steps. Sal is the secretary of the group. The idea is to take the Consent Receipt work (the early technical working group), and move it forward. There is representation from COEL, DIACC, now UMA, other Kantara work groups, MyData operator groups, and more. There has been outreach to Nat Sakimura regarding relevant ISO specs. The idea is to synchronize it to address interoperability so that consent receipts can be used in the same way. It's a project group of the new ISI Work Group. The old CIS Work Group has been archived. People can see the project and group structure in the table of contents off to the left of the linked project page. This first meeting mostly consisted of introductions and basics. The idea is to cycle between each spec/use case, and examine spec sections and ensure they sync up. The goal is to publish in the July timeframe. There is some history provided about the initial Consent Receipt spec, since GDPR was published, on the main Notice & Consent <https://kantarainitiative.org/confluence/pages/viewpage.action?pageId=12546…> page. A tricky part is the IPR, since the work straddles work groups. Eve points to the GA4GH Passports <https://www.ga4gh.org/news/ga4gh-passports-and-the-authorization-and-authen…> work as being relevant; perhaps Carlos Garcia, as an UMAnitarian working on this project, could be a liaison from this perspective. Our work on the "devices and artifacts" around legal relationships could drive how we attach such "machine-readable licenses" as information-sharing agreements. The IEEE research that Lisa and Eve did (webinar version here <https://www.me2balliance.org/webinars.html>, paper version here <https://ieeexplore.ieee.org/document/9031549>) proposed why consent per se – and consent to contract, as in terms of service agreements – is problematic (disempowering) legally and experientially. That's where right-to-use licensing comes in, and these information sharing agreement efforts could solve the interop half of the problem. IDENTOS Resource Definitions/AS-first flows See Alec's email <https://kantarainitiative.org/pipermail/wg-uma/2020-March/005943.html> and our discussion in the last meeting <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-03-12> . How it works: This all works because RS's, and clients, and AS's, have figured out ahead of time what RS's and clients are capable of doing and handling, respectively. There is a trust framework that applies. Think of an immunization record. It can live in a whole bunch of places. The numbers below are from Alec's email. No. 1. FHIR isn't enough in a lot of ways. It's necessary to tag the scopes to say what the different clients can have access to, for example. And the resources need to be tagged to describe what they mean. What didn't exist that needed to be created? If there are three different FHIR repositories and you have to stand up a FHIR app, there's a lot of data you have to set up. "In Ontario, we're using these codes, and we're using SNOMED..." etc. It's metadata that maps FHIR to the local profiles that are specific to that community. Nancy notes that there are a lot of profiles of FHIR. She's involved in a lot of work to harmonize FHIR profiles. For example, there are profiles within the Claims area. It sounds like Alec has done similar work in Canada. Yes: Four different provinces have harmonized their profiles. Why does the AS define these general "resource definitions" vs. RS's? Because the AS is capable of handling these multiple profiles and so it needs to be the one to harmonize across them. Nancy asks: Most data sources don't contain adequate sensitivity data tagging, so: Does this include sensitivity support? The FHIR server along can't support this, so having a gateway in front of it that understands specific scopes and can edit the data would help. There is sort of a "well-known" description of metadata. It could be standardized in some fashion. No. 2a. Any client that can handle whatever subset of these resource definitions and their scopes can be registered for it statically. In their usage of this mechanism it's static, but it doesn't preclude dynamic client registration. No. 2b. When clients are registered, it's at this time that they receive "capability tickets". This could be static or dynamic. But since the clients can only do very specific things, the tickets are specific too. No. 3. How would, say, a new FHIR version ripple through a deployment like this? RS's could be versioned and clients that only understand certain versions could interface only with the versions they understand. How interdependent is Resource Definitions extension with the other extension? They are relatively separable. See the flow provided; step 8 is where Alec addresses this a bit. He'll try and provide a sequence diagram. Eve will set up an *interim call on Apr 2* to continue diving into the details of this. Interop Deferred. Attendees As of 17 Feb 2020, quorum is 5 of 8. (Domenico, Peter, Sal, Thomas, Andi, Maciej, Eve, Mike) 1. Domenico 2. Sal 3. Andi 4. Maciej 5. Eve 6. Mike Non-voting participants: - Tim - Anik - Alec - Nancy *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2020-03-26
by Eve Maler 26 Mar '20

26 Mar '20

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-03-26 Date and Time - *Thursdays 6:30am PT (last "summertime skew" meeting, earlier for UK and CET)* - Screenshare and dial-in: https://global.gotomeeting.com/join/857787301 - See UMA calendar for additional details: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Roll call - Approve minutes of UMA telecon 2020-03-12 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-03-12> - AdvCIS liaison report - IDENTOS Resource Definitions/AS-first flows - Interop - AOB *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Apologies for the abrupt end to the WG call / expect new dial-in details soon
by Eve Maler 14 Mar '20

14 Mar '20

Colin researched the matter and discovered that indeed our call abutted the ISI WG call time using the same GoToMeeting line, and we got bumped. (This happened on the previous call too, as some may recall.) To fix this, we’ll switch to the Kantara “GTM2” line in future. As soon as I’ve got a proper moment on Monday, I’ll fix the calendar entry, wiki page, etc. Those who keep manual calendar entries should prepare to “make a note of it”. And in any case, we shouldn’t be letting our calls drag too long after the bottom of the hour... Eve Maler (sent from my iPad) | cell +1 425 345 6756

1 0

Draft minutes of UMA telecon 2020-03-12
by Eve Maler 12 Mar '20

12 Mar '20

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-03-12 MinutesRoll call Quorum was reached. Approve minutes - - Approve minutes of UMA telecons 2019-10-03 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-10-03> , 2019-11-21 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-11-21> , 2019-12-05 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-12-05> , 2019-12-12 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-12-12> , 2019-12-19 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-12-19> , 2020-02-13 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-02-13> MOTION: Approve minutes of UMA telecons 2019-10-03 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-10-03> , 2019-11-21 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-11-21> , 2019-12-05 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-12-05> , 2019-12-12 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-12-12> , 2019-12-19 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-12-19> , 2020-02-13 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-02-13>. APPROVED. Extensions Alec and Anik: About a year ago, Alec shared how they were using UMA, and particularly modifying it. They have extended and profiled it for their use cases. They are going to share those with the group to get feedback. The first is for "RS Interoperability". This is to enable RS's to have a standard API. If there are, say, five FHIR servers, there can be discovery. Alec will send an email to the WG later today. This has been getting a lot of traction in healthcare in Canada. The second is about splitting the AS. The concept of a "cascading AS" has come up previously, and also a "personal AS" and potentially with a wallet component. This is related to that. The AS in this case doesn't deal with any personal information; it is delegated to a personal authorization server component. This goes into the world of SSI and wallets. The user can bring their own wallet that they can have a stronger relationship with than a "community" AS. This can solve some compliance challenges. This might just be one use case of UMA, or could potentially have broader implications. Alec will share at least the first one. Currently, "compliant UMA" has the client going "RS-first": the first thing it does it to "hit a resource". What they are doing still supports that flow. But they have extended the flow to have the client ask for a permission ticket first. "I'm a client and I need this kind of a service." Does this solve for a "classic" resource protection use case where the RO can protect any (arbitrary) resource? It constrains to a set of well-known resources. This isn't solving for Alice-to-Bob sharing. CanImmunize is an example of an app that gets access to immunization records. They can avoid integrating with every single "RS" (host of immunization records), by integrating with the AS that knows about all the actual RS's. Bob's client goes to the AS and looks for an immunization record. It could be at four RS's. It's told "It's at hospital C, and it looks 'standard' for some definition." George comments: "This sounds a lot like a trust-framework mechanism that manages authorizations of clients and which RSs that client is authorized to access." Resources get statically registered. The user gets to choose what scopes get shared, in an asynchronous policy-based way. The client is registered at the community AS. After Alice (the RO) is in the picture, the RqP presents (SSI-style) credentials (that is, VCs) to Alice's personal authorization server ("PAS"). (In other words, Alice's PAS is a verifier and the RqP is a holder of VCs.) The PAS is an agent managing policy at the community AS. Which extension features are to achieve privacy enhancement and which are to achieve resource standardization? Let's see if we can tease that out when we see the extension details. Adrian notes that there is a prescription monitoring law that seems to overlap with these requirements. Interop ForgeRock has a new "Secure Sharing <https://www.forgerock.com/blog/forgerock-secure-sharing-ingredients-who-wha…>" open-source RS implementation out. Eve will add it to the Implementations page. This is in addition to Gluu's Gluu Gateway RS implementation. Nancy's FHIR-based UMA implementation has been engaged in the healthcare connectathons. FHIR V4 is what's been generally targeted now. HEART now profiles UMA2. It would be a very good time for us to test and demonstrate interop. AS interop is the first step. Nancy suggests that we need a plan to test all the components. A HEART client would be valuable. HEART is just a superset of SMART. It could be valuable to work with the FAST people and that connectathon community. Our previous interop discussions led to this landing page <https://kantarainitiative.org/confluence/display/uma/UMA+Interoperability+T…> (and a bunch of discussion and conclusions in previous notes). We've had offers previously to develop a test harness. Colin will research funds availability. Any reason *not* to choose a healthcare use case for a first interop? Financial services is the other obvious one. Scott notes that in the Secure Sharing implementation, the idea was to start with a generic / abstract reference environment to help communicate the UMA concepts and value proposition, then move into industry-specific requirements. it's always somewhat cumbersome have an example in one industry and having to explain it to another. The implementation provides sample resources and scopes for several industries to reduce the need to say "imagine if you will ...". Fastest route to publishing current UMA relationship material? Relevant docs: - Business-Legal Framework and Use Cases <https://docs.google.com/document/d/1Accua4AWQrl6N0trjdj4NFA0fyDpOn2B1orupCu…> (GDoc) - Mapping Graphics <https://docs.google.com/presentation/d/1uigCMQI_TKuFyOstQTngYuZaqs36wwbE3BB…> (GSlides) - Legal Role Definitions <https://docs.google.com/presentation/d/1I12agEsfaJK3LEiJyROrJV3PCEmhlCzCxYS…> (GSlides) - Definitions and Use Cases Spreadsheet <https://docs.google.com/spreadsheets/d/1QT5LR_ibpwYwpD_XLQ1tB7OLXbdaT6Oi9aj…> (GSheet) Deferred, but interest continues in these use cases and potential solutions. Attendees As of 17 Feb 2020, quorum is 5 of 8. (Domenico, Peter, Sal, Thomas, Andi, Maciej, Eve, Mike) 1. Domenico 2. Sal 3. Thomas 4. Eve 5. Mike Non-voting participants: - Nancy - Scott - Adrian - George - Alec - Colin - Tim - Anik – IDENTOS – guest expert – helping to bring some UMA extension thinking into our realm today *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2020-03-12 (note "summertime skew")
by Eve Maler 10 Mar '20

10 Mar '20

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-03-12 Date and Time - *Thursdays 6:30am PT (new time – and we are in "summertime skew" so it's one hour earlier for UK and CET)* - Screenshare and dial-in: https://global.gotomeeting.com/join/857787301 - See UMA calendar for additional details: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Roll call - Approve minutes of UMA telecons 2019-10-03 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-10-03> , 2019-11-21 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-11-21> , 2019-12-05 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-12-05> , 2019-12-12 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-12-12> , 2019-12-19 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-12-19> , 2020-02-13 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-02-13> - Extensions - Interop - Publishing the relationship material - AOB *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Re: [WG-UMA] [projectvrm] A ... not sure what, exactly ... development in India
by Adrian Gropper 05 Mar '20

05 Mar '20

It's not that simple and I'm not sure "we all agree" on much. On #1 - we probably all agree that all businesses should offer an API, but: - Why should there be a size criteria? Any business that keeps tax records is large enough to offer some API. Let's call it the Minimum Viable API. - To simplify the MVAPI, there would need to be a standard and secure digital ID for each customer that wants access to the API. The cost of presenting a standard identifier like a W3C DID is borne by the customer (smartphone, digital wallet, wallet backup / recovery services). The business does not have to bear any significant costs or could charge extra for API access. Then the law would apply to all businesses but might limit how much they can charge. This is pretty much how US health records API is regulated. - I don't think it's useful to argue over human rights to either portability or interoperability. It's too abstract. Why not just mandate the API as an extension of tax policy? Failure to put up an API responsive to an individual's DID would be a form of tax fraud. - I doubt we can all agree on the data model for an API, so what does "well-formed" mean. I suggest a labeling approach instead. Any business can use any data model and ontology they want as long as they publish the documentation. The cost of decoding will be borne by the data user. Businesses that fail to use common API will be imposing a cost on their API customers and may lose business. This avoids all sorts of regulatory capture and bureaucracy. On #2 - Regulating "informed" or "consent" for data uses is a bridge too far. It looks like 20-page privacy policies that nobody can read, armies of IAPP lawyers to monitor "compliance" while extracting maximum leverage over customers, and a whole higher education industry built around https://twitter.com/darkpatterns - We need standardized labels for how a business processes personal data. https://ssrn.com/abstract=3439701 is one example from Patient Privacy Rights. The whole point, is to drive businesses to use standardized labels either through customer pressure or regualtion. - Businesses that want to send or receive (share) personal data with any others should be required to ask specific permission _each time_ from an agent specified separately by each data subject. Yes, this would be relatively inefficient compared to today's practices but networks are cheap and informed prior consent is not realistic. Data and Society hosted a good talk today titled "Abolish Big Data" https://datasociety.net/events/abolish-big-data/ It argues that most of the big data is being used to screw us and mentions data trusts as a possible solution. Data trusts are an immature concept but worth considering because it's one approach to decentralizing governance. Until we figure out data governance principles that are transparent and contextual to specific communities we should limit data aggregation by default and focus on personal agents and other fiduciaries. - Adrian On Wed, Mar 4, 2020 at 4:52 AM Julian Ranger <Julian(a)jranger.com> wrote: > Hopefully what we all agree on is portability of data and transferability > of services (I would write interoperability, but that just technically > helps transferability – very much desired). We must be able to get our > data as individuals from services that hold the data, and swap between > services – and also swap between services (such as digi.me) that help us > hold and control our data too. If we do portability and transferability > right (which requires standards that people are working on, including us at > digi.me) then ultimately we can choose the business relationship(s) that > work best for us as individuals – whether end to end, full separation of > concerns, other. > > > > To get to this point what we need more than anything is data portability > to get the ecosystem moving – to enable personal data to be used and reused > (all controlled by the individual) to generate more value. We are in > danger of losing sight o fthis in all the privacy legislation that is being > proposed, and amid a clamour for interoperability, standards, extra > actions, et al. Free the data in any format/method you can (preferably > “well formed API”) so individuals can getteh data and then worry about > making it simpler and better – but don’t delay getting that data out. > > > > Any legislation that wants to kick start the right use of data really only > needs two aspects: > > > > 1. Data Portability right for individual with “well formed API” > mandated for businesses over size x (debate size x) > 2. Explicit & informed cosnent – so no data behind our backs > 1. (and yes other legal reasons for data processing exist, but they > are and should be very specific) > > > > Big issue for this year and moving forwards is avoiding > over-complexification of legislation (as has happened with Australian > Consumer data Right for example). > > > > Jules > > > > *From:* jim pasquale <jimpasquale(a)gmail.com> > *Sent:* 03 March 2020 16:44 > *To:* Doc Searls <anitadrink(a)gmail.com>; Julian Ranger <Julian(a)jranger.com>; > Adrian Gropper <agropper(a)healthurl.com> > *Cc:* Henrik Biering <hb(a)peercraft.com>; Project VRM < > projectvrm(a)eon.law.harvard.edu>; wg-uma(a)kantarainitiative.org WG < > WG-UMA(a)kantarainitiative.org>; wg-isi(a)kantarainitiative.org > *Subject:* Re: [WG-UMA] [projectvrm] A ... not sure what, exactly ... > development in India > > > > And adding some more research, while a year old I didn’t think individuals > have moved off this needle much: > > > > > https://dma.org.uk/uploads/misc/5a857c4fdf846-data-privacy---what-the-consu… > > > > Lots of good insights Lisa shared from someone who shared it with her. > > > > > > On Mar 3, 2020, at 11:16 AM, Doc Searls <anitadrink(a)gmail.com> wrote: > > > > Good back-and-forth here. > > > > BTW, the better link (because it goes to the one post and not all the > tagged posts) is > https://blogs.harvard.edu/vrm/2009/04/12/vrm-and-the-four-party-system/ > > > > Doc > > > > On Mar 1, 2020, at 1:01 PM, Henrik Biering <hb(a)peercraft.com> wrote: > > > > I like Julians explanation that appears to be based on the roles of > business entities rather than the roles of technical solution components as > the SoC proposed by Adrian. > > To me SoC should ensure what Doc phrased here a long time ago: > https://blogs.harvard.edu/vrm/tag/first-party/ > > "Fourth parties also need to be *substitutable*. They need *service > portability*, just as the customer needs *data portability* between > fourth (and other) party services. That way whatever they can provide can > be swapped out by the user, if need be." > > This means that services like Digi.me <http://digi.me/> that leaves the > data controller role to the individual may have agreements with 2. and 3. > parties as long as they are transparent to the user. But it means that a > user may need to substitute the 4. party if he/she should decide to switch > to another 2. party. > > 4. party services like recommender and relationship management services on > the other hand naturally cannot coexist with any contractual relationship > between a 4. party and any 2. or individual 3. parties. 4. parties may > only facilitate interactions (anonymously or identified) between 1. and 2. > parties following instructions from the 1. party. This is evidenced by the > huge amount of claimed 4. party "comparison services" that overwhelmingly > have turned out to be concealed 3. party services. And any separation of > roles at the technical level would not prevent this from happening. > > So SoC may have different implications depending on the nature of services. > > Once appropriate SoC has been determined at the business layer, then it is > up to technical standards to ensure that: > > * that these concerns including - also legal and ethical requirements - > can be enforced by technology rather than policy > > * service portability as well as data portability can be implemented as > required to support the business layer SoC in easy and nondiscriminatory > ways. > > /Henrik > > Den 01-03-2020 kl. 16:57 skrev Julian Ranger: > > Adrian, > > > > Re “the pushback is that no private business wants to be strictly a data > controller and forego access to the data itself as part of their business > model” > > > > Some businesses, i.e. digi.me, want to be neither a data controller nor > have access to the data itself – and that is ultimately the right answer. > Don’t see, touch ro hold the data. Now whether current implementations > (ours included) meet you strict definition of SoC I don’t know, but to me > it is clear that the individual’s data stores should only be handled by > software that the individual chooses to run and that processing should sit > within thinteh inidividual’s domain (until such time as the individual > specifically allows data to leave their domain). > > > > Jules > > > > > > *From:* Doc Searls <anitadrink(a)gmail.com> <anitadrink(a)gmail.com> > *Sent:* 24 February 2020 20:02 > *To:* Adrian Gropper <agropper(a)healthurl.com> <agropper(a)healthurl.com> > *Cc:* Tim Reiniger <tsreiniger(a)gmail.com> <tsreiniger(a)gmail.com>; LaVonne > Reimer <lreimer(a)lumeno.us> <lreimer(a)lumeno.us>; ProjectVRM list > <projectvrm(a)eon.law.harvard.edu> <projectvrm(a)eon.law.harvard.edu>; > wg-uma(a)kantarainitiative.org WG <WG-UMA(a)kantarainitiative.org> > <WG-UMA(a)kantarainitiative.org> > *Subject:* Re: [WG-UMA] [projectvrm] A ... not sure what, exactly ... > development in India > > > > > > On Feb 24, 2020, at 11:49 AM, Adrian Gropper <agropper(a)healthurl.com> > wrote: > > > > This is a good thing. There’s some overlap between the Solid folks and > those of us working on SSI standards. Although they don’t say it publicly, > I’ve been assured that Inrupt will implement and respect what I call > Separation of Concerns standards. > > > > I saw the same potential synergies. > > > > Separation of Concerns means that the data controller can be specified by > the data subject separately form the data storage or other data processors. > UMA2 can already do that and it’s likely that the upcoming IETF OAuth3 > standards will also support SoC. A pod would then be a special case of a > co-located controller and storage. > > > > Our HIE of One Trustee project has always done this. We keep separate > github repos for the two separate concerns in order to demonstrate the > standards that connect them and to highlight gaps in the standards that > still need improvement. > > > > Defining agency as requiring SoC seems to be controversial. There’s > pushback because the standards are immature. I suspect another, unstated > reason for the pushback is that no private business wants to be strictly a > data controller and forego access to the data itself as part of their > business model. > > > > Sounds right. > > > > I’m curious what others on this list think about defining agency in terms > of SoC. > > > > My own small thought on it (having not thought or known enough about it, > so far) is that it makes sense. Given the ease of data spread—with lost > personal agency in the midst—it's important to keep ambiguities minimized > and separate responsibilities clear. > > > > Doc > > > > > - Adrian > > > > > > > > On Mon, Feb 24, 2020 at 4:26 PM Tim Reiniger <tsreiniger(a)gmail.com> wrote: > > Adrian, > > > > Thank you for compiling this great list! If you haven't seen this story, > this might become an addition: > https://www.schneier.com/blog/archives/2020/02/inrupt_tim_bern.html. See > what you think! > > > > Regards, > > > > Tim > > > > On Thu, Feb 13, 2020 at 1:02 PM Adrian Gropper <agropper(a)healthurl.com> > wrote: > > This is an important development in the global context of giving agency to > individuals. Here is my current list of related initiatives. Note that all > of these are works-in-progress. In no particular order: > > > > - US ACCESS Act > https://blog.petrieflom.law.harvard.edu/2019/10/24/access-act-points-the-wa… > <https://blog.petrieflom.law.harvard.edu/2019/10/24/access-act-points-the-wa…> > > - EU+ MyData Operators > https://docs.google.com/presentation/d/1J71J8_8kSiIXmVXSkQbRixmv0rxQXC_d-I6… > > - EU Open Banking and PSD 2 > https://www.altexsoft.com/blog/engineering/open-banking-and-financial-apis-… > > - India Open Banking > https://www.bloomberg.com/news/articles/2020-01-13/india-s-about-to-hand-pe… > > - SSI and Rebooting Web of Trust > https://github.com/WebOfTrustInfo/rwot10-buenosaires/blob/master/topics-and… > > - IETF Transactional Authorization > https://tools.ietf.org/html/draft-richer-transactional-authz-03 > > > > The common thread across all of these is an authorization server acting on > behalf of a data subject. This is a very different model from GDPR, HIPAA, > CCPA, the proposed India Personal Data Protection Bill or the other 9 > privacy bills being considered in Washington. > > > > - Adrian > > > > > > > > > > On Tue, Feb 11, 2020 at 2:07 PM LaVonne Reimer <lreimer(a)lumeno.us> wrote: > > Thanks for bringing this to our attention. > > > > This is squarely my area (by way of Descant). I'm a bit crunched at the > moment so not able to provide a thorough analysis relative to VRM but if > you think back to everything I've said in past VRM days as well as on these > threads, it claims to provide a data facilitator platform congruent with > all that working code I've been sitting on for much too long! > > > > First, thoughts on the article. Then below that, a reference to the > Equifax announcement yesterday. > > > > A couple characteristics that fit the VRM way, and that are at least > implied in the article: > > - It revisits the flows of data for credit analysis "through the eyes > of" the subjects of the data. It's always important to question the extent > of this agency when it's banks rolling out the solution but the spirit of > subject-driven data flows seems to be present. > - It addresses a gap in data pipeline management on a narrower basis > than will be necessary to scale and than we offer via Descant. See the > specific reference to an India-specific requirement that financial data be > reported in a standard, machine-readable format. More on this below. > - It suggests consents will be easier to understand because data > subjects can choose to share portions of data. This is a very big challenge > and one we've largely solved by enabling UI/UX that spreads out consents > across touchpoints. Easier to provide for context-based consent in that > manner. It's not clear that India is thinking in these terms. Indeed the > intent seems to be that fintech startups will build apps on top of the > platform. Unless there are constraints on the spirit and intent of such > apps, they could be heading back to opacity with little opportunity to pull > it back. Also, more on this below. > > *Data pipeline management: * > > Of all the big data challenges addressed over the past decade, pipeline > management has only recently popped up as a significant area. I have only > seen developments (and patent filings) for pipelines within enterprises. > The essence is that applying transformation, processing, and governance to > data while in motion streamlines its path to insights. As the category > implies, it's a more fluid approach to data management for sure as compared > to the old ETL model and arguably data lakes. > > > > A facilitator platform that replaces credit bureaus will need to > management multiple pipelines, each potentially presenting different levels > of privacy-sensitivity and latency concerns. The solution announced by this > article is a reasonable start but not as extensive as would be needed to > truly replace an Equifax. I didn't see a plan to, say, open source the > system so extensions for additional data pipelines could emerge. > > > > Note that this data challenge is not obviously about privacy but it is > critical if the goal is to replace intermediated data solutions. This is a > good a place as any to include a link to an opinion in yesterday's NYT > about the indictment of Chinese hackers for the Equifax breach. Author > makes the point that the whole model underlying Equifax and data brokers is > the problem. And that is a more complicated data pipeline problem than > consents. > > > > > https://www.nytimes.com/2020/02/10/opinion/equifax-breach-china-hacking.html > > > > *Context-based consent etc:* > > Just adding a short note that I've been studying recent efforts to add > language to open source licenses that encompasses privacy, data rights, > and/or human dignity. As far as I can see, this is all new territory. In > the "humanitarian license," the author combines language from the MIT open > source license with language out of the UN's declaration of human rights. > So far OSI seems poised to reject it as a "blessed" open source license. > NYU School of Law also has some similar projects underway. > > > > I care about this because when I think about open sourcing the > data-sharing platform of Descant, I worry much more about extensions in > conflict with the ethos of people in charge of their own data than specific > uses of the source code. This goes to my concern that opening up for > fintech startups would be problematic if there's no way to police data > usage. > > > > Again, this is all off the top of my head. The title is correct that it is > better than the US but then we are a dark and surveilled country headed for > very bad days unless we can get a grip. > > > > Let me know of any questions/afterthoughts. > > > > Thanks again Doc!! > > > > LaVonne > > 503-720-0690 > > > > On Tue, Feb 11, 2020 at 1:31 PM Doc Searls <anitadrink(a)gmail.com> wrote: > > Headlines: > > > > India’s About to Hand People Data Americans Can Only Dream Of > By Saritha Rai > January 12, 2020, 11:01 PM EST > > • New system aims to protect data and unlock the credit market > > • India joins a growing movement to give consumers data control > > > > < > https://www.bloomberg.com/news/articles/2020-01-13/india-s-about-to-hand-pe… > > > > > > Anybody familiar with this want to lay it out in VRM terms (good, bad or > otherwise)? > > > > Doc > > > > -- > > LaVonne Reimer, Founder > Lumenous > 503-720-0690 (cell) > lavonnereimer (skype) > > www.lumenous.net > > > > _______________________________________________ > WG-UMA mailing list > WG-UMA(a)kantarainitiative.org > https://kantarainitiative.org/mailman/listinfo/wg-uma > > > > >

1 0

Re: [WG-UMA] [projectvrm] A ... not sure what, exactly ... development in India
by Adrian Gropper 03 Mar '20

03 Mar '20

Jules - you overstate the difficulty. Let's take a very simple example of SoC: Information Governance Labels separate from Service Registries. Neither of these concerns has any access to a personal data item. A label can be standardized by one entity (e.g. the PPR Information Governance Label https://ssrn.com/abstract=3439701 ) and another entity could decide to act as registrar (e.g. digi.me or the Apple App Store) to simply post the label for services that choose to use it. In this example, MyData would choose to play either the "standards" role or the registry role but not both. I put standards in "" because PPR did not engage in a formal ANSI-accredited standards process for the IGL. It's simply a voluntary effort as an example to others that might do the same. Secondly, nothing keeps digi.me or Apple from participating in SoC standards efforts at some level even as they execute their current market strategy as end-to-end. My point is that SoC can be introduced as gently as anyone wants. I don't buy the idea that end-to-end implementations like digi.me come first because if that's the case, then Apple wins hands-down. - Adrian On Mon, Mar 2, 2020 at 2:46 PM Julian Ranger <Julian(a)jranger.com> wrote: > Adrian – splitting functionality is a very difficult thing to do in this > case. At digi.me we provide an end to end service from data into an > individual to data out – we can therefore ensure that the intermediate > steps all work together smoothly. In some future world where each step is > a well known process then one could mix and match, but that would require > each step to be well understood and agreed as a separate functional entity > which then chains to another functionally separate entity. For such chains > to exist there has to be implementations in this new world that a) work and > then b) have a desire to interoperate with other working chains – that will > take time as companies work out what can work and won’t technically, > financially and operationally with the user involved. If we want any level > of MyData operations in the near term then getting some successful end to > end implementations out into the wild is step 1; making them componentised > (SoC) and interoperable is definitely step 2. Jules > > > > *From:* Adrian Gropper <agropper(a)healthurl.com> > *Sent:* 01 March 2020 17:13 > *To:* Julian Ranger <Julian(a)jranger.com> > *Cc:* Antti Jogi Poikola <antti.poikola(a)gmail.com>; Doc Searls < > anitadrink(a)gmail.com>; LaVonne Reimer <lreimer(a)lumeno.us>; ProjectVRM > list <projectvrm(a)eon.law.harvard.edu>; Tim Reiniger <tsreiniger(a)gmail.com>; > wg-uma(a)kantarainitiative.org WG <WG-UMA(a)kantarainitiative.org> > *Subject:* Re: [WG-UMA] [projectvrm] A ... not sure what, exactly ... > development in India > > > > Julian, > > > > Thank you for engaging, as you always do. > > > > This is not about my definition of strict or anyone else’s. It’s about the > role of standards to enable and empower individuals. > > > > For example, as I understand it, digi.me has an ontology component and a > consent component. The ontology component can and does add value because it > has access to the data in the clear. The consent component can and does add > value because it can control use of the data without access to the clear > text data itself. (It could, in principle, control the flow of data > directly from a streaming source to a data processor destination.) > > > > The decision on how to connect the ontology component to the consent > component of digi.me is entirely up to digi.me. They could choose to use > a standard like UMA internally and also expose that control connection > externally. This would empower the individual customer to make separate > choice of their ontology or their consent managers. This, in turn, reduces > lock-in and promotes competition, both of which can benefit the customer. > > > > The tradeoff comes when a service provider that builds on separation of > concerns, such as our HIE of One Trustee project, cannot find investors to > sponsor the added standards work and risk of customer churn. Separation of > Concerns is therefore a finance problem more than it is a standards problem. > > > > I’m aware of only a few groups that have chosen to tackle the finance > problem and they are quite immature. One is the Digital Life Collective (by > Philip Sheldrake) others look more like Decentralized Autonomous > Organizations (DAO) and more recently, Decentralized Finance (DeFi). These > groups are so busy re-inventing management structures that they can’t be > bothered with mundane things like standards process. > > > > The other group worth mentioning is MyData. They are also immature and > have partitioned this Separation of Concerns issue into a MyData Operator > discussion (where digi.me is a participant). What MyData does has some > impact on immature EU Data Privacy regulations. Our handling of the SoC and > standards will be, IMHO, the real test of the MyData model. > > > > (Privacy regulators are the most immature group of all. They are still > oblivious to the relationship between standards and competition. The giant > platform vendors are desperately hoping to be regulated as giant platforms > rather than give innovators the opportunity that comes with Separation of > Concerns.) > > > > In other words, customers almost always come second to finance. The sole > exception seems to be open source software projects which dispense with > finance by design and deal with management as little as possible. > > > > - Adrian > > > > On Sun, Mar 1, 2020 at 10:57 AM Julian Ranger <Julian(a)jranger.com> wrote: > > Adrian, > > > > Re “the pushback is that no private business wants to be strictly a data > controller and forego access to the data itself as part of their business > model” > > > > Some businesses, i.e. digi.me, want to be neither a data controller nor > have access to the data itself – and that is ultimately the right answer. > Don’t see, touch ro hold the data. Now whether current implementations > (ours included) meet you strict definition of SoC I don’t know, but to me > it is clear that the individual’s data stores should only be handled by > software that the individual chooses to run and that processing should sit > within thinteh inidividual’s domain (until such time as the individual > specifically allows data to leave their domain). > > > > Jules > > > > > > *From:* Doc Searls <anitadrink(a)gmail.com> > *Sent:* 24 February 2020 20:02 > *To:* Adrian Gropper <agropper(a)healthurl.com> > *Cc:* Tim Reiniger <tsreiniger(a)gmail.com>; LaVonne Reimer < > lreimer(a)lumeno.us>; ProjectVRM list <projectvrm(a)eon.law.harvard.edu>; > wg-uma(a)kantarainitiative.org WG <WG-UMA(a)kantarainitiative.org> > *Subject:* Re: [WG-UMA] [projectvrm] A ... not sure what, exactly ... > development in India > > > > > > On Feb 24, 2020, at 11:49 AM, Adrian Gropper <agropper(a)healthurl.com> > wrote: > > > > This is a good thing. There’s some overlap between the Solid folks and > those of us working on SSI standards. Although they don’t say it publicly, > I’ve been assured that Inrupt will implement and respect what I call > Separation of Concerns standards. > > > > I saw the same potential synergies. > > Separation of Concerns means that the data controller can be specified by > the data subject separately form the data storage or other data processors. > UMA2 can already do that and it’s likely that the upcoming IETF OAuth3 > standards will also support SoC. A pod would then be a special case of a > co-located controller and storage. > > > > Our HIE of One Trustee project has always done this. We keep separate > github repos for the two separate concerns in order to demonstrate the > standards that connect them and to highlight gaps in the standards that > still need improvement. > > > > Defining agency as requiring SoC seems to be controversial. There’s > pushback because the standards are immature. I suspect another, unstated > reason for the pushback is that no private business wants to be strictly a > data controller and forego access to the data itself as part of their > business model. > > > > Sounds right. > > I’m curious what others on this list think about defining agency in terms > of SoC. > > > > My own small thought on it (having not thought or known enough about it, > so far) is that it makes sense. Given the ease of data spread—with lost > personal agency in the midst—it's important to keep ambiguities minimized > and separate responsibilities clear. > > > > Doc > > > > - Adrian > > > > > > > > On Mon, Feb 24, 2020 at 4:26 PM Tim Reiniger <tsreiniger(a)gmail.com> wrote: > > Adrian, > > > > Thank you for compiling this great list! If you haven't seen this story, > this might become an addition: > https://www.schneier.com/blog/archives/2020/02/inrupt_tim_bern.html. See > what you think! > > > > Regards, > > > > Tim > > > > On Thu, Feb 13, 2020 at 1:02 PM Adrian Gropper <agropper(a)healthurl.com> > wrote: > > This is an important development in the global context of giving agency to > individuals. Here is my current list of related initiatives. Note that all > of these are works-in-progress. In no particular order: > > > > - US ACCESS Act > https://blog.petrieflom.law.harvard.edu/2019/10/24/access-act-points-the-wa… > > - EU+ MyData Operators > https://docs.google.com/presentation/d/1J71J8_8kSiIXmVXSkQbRixmv0rxQXC_d-I6… > > - EU Open Banking and PSD 2 > https://www.altexsoft.com/blog/engineering/open-banking-and-financial-apis-… > > - India Open Banking https://www.bloomberg.com/news/articles/2020-01-13/india-s-about-to-hand-pe… > > > - SSI and Rebooting Web of Trust > https://github.com/WebOfTrustInfo/rwot10-buenosaires/blob/master/topics-and… > > - IETF Transactional Authorization > https://tools.ietf.org/html/draft-richer-transactional-authz-03 > > > > The common thread across all of these is an authorization server acting on > behalf of a data subject. This is a very different model from GDPR, HIPAA, > CCPA, the proposed India Personal Data Protection Bill or the other 9 > privacy bills being considered in Washington. > > > > - Adrian > > > > > > > > > > On Tue, Feb 11, 2020 at 2:07 PM LaVonne Reimer <lreimer(a)lumeno.us> wrote: > > Thanks for bringing this to our attention. > > > > This is squarely my area (by way of Descant). I'm a bit crunched at the > moment so not able to provide a thorough analysis relative to VRM but if > you think back to everything I've said in past VRM days as well as on these > threads, it claims to provide a data facilitator platform congruent with > all that working code I've been sitting on for much too long! > > > > First, thoughts on the article. Then below that, a reference to the > Equifax announcement yesterday. > > > > A couple characteristics that fit the VRM way, and that are at least > implied in the article: > > - It revisits the flows of data for credit analysis "through the eyes > of" the subjects of the data. It's always important to question the extent > of this agency when it's banks rolling out the solution but the spirit of > subject-driven data flows seems to be present. > - It addresses a gap in data pipeline management on a narrower basis > than will be necessary to scale and than we offer via Descant. See the > specific reference to an India-specific requirement that financial data be > reported in a standard, machine-readable format. More on this below. > - It suggests consents will be easier to understand because data > subjects can choose to share portions of data. This is a very big challenge > and one we've largely solved by enabling UI/UX that spreads out consents > across touchpoints. Easier to provide for context-based consent in that > manner. It's not clear that India is thinking in these terms. Indeed the > intent seems to be that fintech startups will build apps on top of the > platform. Unless there are constraints on the spirit and intent of such > apps, they could be heading back to opacity with little opportunity to pull > it back. Also, more on this below. > > *Data pipeline management: * > > Of all the big data challenges addressed over the past decade, pipeline > management has only recently popped up as a significant area. I have only > seen developments (and patent filings) for pipelines within enterprises. > The essence is that applying transformation, processing, and governance to > data while in motion streamlines its path to insights. As the category > implies, it's a more fluid approach to data management for sure as compared > to the old ETL model and arguably data lakes. > > > > A facilitator platform that replaces credit bureaus will need to > management multiple pipelines, each potentially presenting different levels > of privacy-sensitivity and latency concerns. The solution announced by this > article is a reasonable start but not as extensive as would be needed to > truly replace an Equifax. I didn't see a plan to, say, open source the > system so extensions for additional data pipelines could emerge. > > > > Note that this data challenge is not obviously about privacy but it is > critical if the goal is to replace intermediated data solutions. This is a > good a place as any to include a link to an opinion in yesterday's NYT > about the indictment of Chinese hackers for the Equifax breach. Author > makes the point that the whole model underlying Equifax and data brokers is > the problem. And that is a more complicated data pipeline problem than > consents. > > > > > https://www.nytimes.com/2020/02/10/opinion/equifax-breach-china-hacking.html > > > > *Context-based consent etc:* > > Just adding a short note that I've been studying recent efforts to add > language to open source licenses that encompasses privacy, data rights, > and/or human dignity. As far as I can see, this is all new territory. In > the "humanitarian license," the author combines language from the MIT open > source license with language out of the UN's declaration of human rights. > So far OSI seems poised to reject it as a "blessed" open source license. > NYU School of Law also has some similar projects underway. > > > > I care about this because when I think about open sourcing the > data-sharing platform of Descant, I worry much more about extensions in > conflict with the ethos of people in charge of their own data than specific > uses of the source code. This goes to my concern that opening up for > fintech startups would be problematic if there's no way to police data > usage. > > > > Again, this is all off the top of my head. The title is correct that it is > better than the US but then we are a dark and surveilled country headed for > very bad days unless we can get a grip. > > > > Let me know of any questions/afterthoughts. > > > > Thanks again Doc!! > > > > LaVonne > > 503-720-0690 > > > > On Tue, Feb 11, 2020 at 1:31 PM Doc Searls <anitadrink(a)gmail.com> wrote: > > Headlines: > > > > India’s About to Hand People Data Americans Can Only Dream Of > By Saritha Rai > January 12, 2020, 11:01 PM EST > > • New system aims to protect data and unlock the credit market > > • India joins a growing movement to give consumers data control > > > > < > https://www.bloomberg.com/news/articles/2020-01-13/india-s-about-to-hand-pe… > > > > > > Anybody familiar with this want to lay it out in VRM terms (good, bad or > otherwise)? > > > > Doc > > > > -- > > LaVonne Reimer, Founder > Lumenous > 503-720-0690 (cell) > lavonnereimer (skype) > > www.lumenous.net > > > > _______________________________________________ > WG-UMA mailing list > WG-UMA(a)kantarainitiative.org > https://kantarainitiative.org/mailman/listinfo/wg-uma > > > >

1 0

Re: [WG-UMA] [projectvrm] A ... not sure what, exactly ... development in India
by Henrik Biering 01 Mar '20

01 Mar '20

I like Julians explanation that appears to be based on the roles of business entities rather than the roles of technical solution components as the SoC proposed by Adrian. To me SoC should ensure what Doc phrased here a long time ago: https://blogs.harvard.edu/vrm/tag/first-party/ "Fourth parties also need to be /substitutable/. They need /service portability/, just as the customer needs /data portability/ between fourth (and other) party services. That way whatever they can provide can be swapped out by the user, if need be." This means that services like Digi.me that leaves the data controller role to the individual may have agreements with 2. and 3. parties as long as they are transparent to the user. But it means that a user may need to substitute the 4. party if he/she should decide to switch to another 2. party. 4. party services like recommender and relationship management services on the other hand naturally cannot coexist with any contractual relationship between a 4. party and any 2. or individual 3. parties. 4. parties may only facilitate interactions (anonymously or identified) between 1. and 2. parties following instructions from the 1. party. This is evidenced by the huge amount of claimed 4. party "comparison services" that overwhelmingly have turned out to be concealed 3. party services. And any separation of roles at the technical level would not prevent this from happening. So SoC may have different implications depending on the nature of services. Once appropriate SoC has been determined at the business layer, then it is up to technical standards to ensure that: * that these concerns including - also legal and ethical requirements - can be enforced by technology rather than policy * service portability as well as data portability can be implemented as required to support the business layer SoC in easy and nondiscriminatory ways. /Henrik Den 01-03-2020 kl. 16:57 skrev Julian Ranger: > > Adrian, > > Re “the pushback is that no private business wants to be strictly a > data controller and forego access to the data itself as part of their > business model” > > Some businesses, i.e. digi.me, want to be neither a data controller > nor have access to the data itself – and that is ultimately the right > answer. Don’t see, touch ro hold the data. Now whether current > implementations (ours included) meet you strict definition of SoC I > don’t know, but to me it is clear that the individual’s data stores > should only be handled by software that the individual chooses to run > and that processing should sit within thinteh inidividual’s domain > (until such time as the individual specifically allows data to leave > their domain). > > Jules > > *From:*Doc Searls <anitadrink(a)gmail.com> > *Sent:* 24 February 2020 20:02 > *To:* Adrian Gropper <agropper(a)healthurl.com> > *Cc:* Tim Reiniger <tsreiniger(a)gmail.com>; LaVonne Reimer > <lreimer(a)lumeno.us>; ProjectVRM list <projectvrm(a)eon.law.harvard.edu>; > wg-uma(a)kantarainitiative.org WG <WG-UMA(a)kantarainitiative.org> > *Subject:* Re: [WG-UMA] [projectvrm] A ... not sure what, exactly ... > development in India > > On Feb 24, 2020, at 11:49 AM, Adrian Gropper > <agropper(a)healthurl.com <mailto:agropper@healthurl.com>> wrote: > > This is a good thing. There’s some overlap between the Solid folks > and those of us working on SSI standards. Although they don’t say > it publicly, I’ve been assured that Inrupt will implement and > respect what I call Separation of Concerns standards. > > I saw the same potential synergies. > > > Separation of Concerns means that the data controller can be > specified by the data subject separately form the data storage or > other data processors. UMA2 can already do that and it’s likely > that the upcoming IETF OAuth3 standards will also support SoC. A > pod would then be a special case of a co-located controller and > storage. > > Our HIE of One Trustee project has always done this. We keep > separate github repos for the two separate concerns in order to > demonstrate the standards that connect them and to highlight gaps > in the standards that still need improvement. > > Defining agency as requiring SoC seems to be controversial. > There’s pushback because the standards are immature. I suspect > another, unstated reason for the pushback is that no private > business wants to be strictly a data controller and forego access > to the data itself as part of their business model. > > Sounds right. > > > I’m curious what others on this list think about defining agency > in terms of SoC. > > My own small thought on it (having not thought or known enough about > it, so far) is that it makes sense. Given the ease of data spread—with > lost personal agency in the midst—it's important to keep ambiguities > minimized and separate responsibilities clear. > > Doc > > - Adrian > > On Mon, Feb 24, 2020 at 4:26 PM Tim Reiniger <tsreiniger(a)gmail.com > <mailto:tsreiniger@gmail.com>> wrote: > > Adrian, > > Thank you for compiling this great list! If you haven't seen > this story, this might become an addition: > https://www.schneier.com/blog/archives/2020/02/inrupt_tim_bern.html. > See what you think! > > Regards, > > Tim > > On Thu, Feb 13, 2020 at 1:02 PM Adrian Gropper > <agropper(a)healthurl.com <mailto:agropper@healthurl.com>> wrote: > > This is an important development in the global context of > giving agency to individuals. Here is my current list of > related initiatives. Note that all of these are > works-in-progress. In no particular order: > > - US ACCESS Act > https://blog.petrieflom.law.harvard.edu/2019/10/24/access-act-points-the-wa… > > - EU+ MyData Operators > https://docs.google.com/presentation/d/1J71J8_8kSiIXmVXSkQbRixmv0rxQXC_d-I6… > > - EU Open Banking and PSD 2 > https://www.altexsoft.com/blog/engineering/open-banking-and-financial-apis-… > > - India Open Banking > https://www.bloomberg.com/news/articles/2020-01-13/india-s-about-to-hand-pe… > > > - SSI and Rebooting Web of Trust > https://github.com/WebOfTrustInfo/rwot10-buenosaires/blob/master/topics-and… > > - IETF Transactional Authorization > https://tools.ietf.org/html/draft-richer-transactional-authz-03 > > > The common thread across all of these is an authorization > server acting on behalf of a data subject. This is a very > different model from GDPR, HIPAA, CCPA, the proposed India > Personal Data Protection Bill or the other 9 privacy bills > being considered in Washington. > > - Adrian > > On Tue, Feb 11, 2020 at 2:07 PM LaVonne Reimer > <lreimer(a)lumeno.us <mailto:lreimer@lumeno.us>> wrote: > > Thanks for bringing this to our attention. > > This is squarely my area (by way of Descant). I'm a > bit crunched at the moment so not able to provide a > thorough analysis relative to VRM but if you think > back to everything I've said in past VRM days as well > as on these threads, it claims to provide a data > facilitator platform congruent with all that working > code I've been sitting on for much too long! > > First, thoughts on the article. Then below that, a > reference to the Equifax announcement yesterday. > > A couple characteristics that fit the VRM way, and > that are at least implied in the article: > > * It revisits the flows of data for credit analysis > "through the eyes of" the subjects of the data. > It's always important to question the extent of > this agency when it's banks rolling out the > solution but the spirit of subject-driven data > flows seems to be present. > * It addresses a gap in data pipeline management on > a narrower basis than will be necessary to scale > and than we offer via Descant. See the specific > reference to an India-specific requirement that > financial data be reported in a standard, > machine-readable format. More on this below. > * It suggests consents will be easier to understand > because data subjects can choose to share portions > of data. This is a very big challenge and one > we've largely solved by enabling UI/UX that > spreads out consents across touchpoints. Easier to > provide for context-based consent in that manner. > It's not clear that India is thinking in these > terms. Indeed the intent seems to be that fintech > startups will build apps on top of the platform. > Unless there are constraints on the spirit and > intent of such apps, they could be heading back to > opacity with little opportunity to pull it back. > Also, more on this below. > > *Data pipeline management: * > > Of all the big data challenges addressed over the past > decade, pipeline management has only recently popped > up as a significant area. I have only seen > developments (and patent filings) for pipelines within > enterprises. The essence is that applying > transformation, processing, and governance to data > while in motion streamlines its path to insights. As > the category implies, it's a more fluid approach to > data management for sure as compared to the old ETL > model and arguably data lakes. > > A facilitator platform that replaces credit bureaus > will need to management multiple pipelines, each > potentially presenting different levels of > privacy-sensitivity and latency concerns. The solution > announced by this article is a reasonable start but > not as extensive as would be needed to truly replace > an Equifax. I didn't see a plan to, say, open source > the system so extensions for additional data pipelines > could emerge. > > Note that this data challenge is not obviously about > privacy but it is critical if the goal is to replace > intermediated data solutions. This is a good a place > as any to include a link to an opinion in yesterday's > NYT about the indictment of Chinese hackers for the > Equifax breach. Author makes the point that the whole > model underlying Equifax and data brokers is the > problem. And that is a more complicated data pipeline > problem than consents. > > https://www.nytimes.com/2020/02/10/opinion/equifax-breach-china-hacking.html > > *Context-based consent etc:* > > Just adding a short note that I've been studying > recent efforts to add language to open source licenses > that encompasses privacy, data rights, and/or human > dignity. As far as I can see, this is all new > territory. In the "humanitarian license," the author > combines language from the MIT open source license > with language out of the UN's declaration of human > rights. So far OSI seems poised to reject it as a > "blessed" open source license. NYU School of Law also > has some similar projects underway. > > I care about this because when I think about open > sourcing the data-sharing platform of Descant, I worry > much more about extensions in conflict with the ethos > of people in charge of their own data than specific > uses of the source code. This goes to my concern that > opening up for fintech startups would be problematic > if there's no way to police data usage. > > Again, this is all off the top of my head. The title > is correct that it is better than the US but then we > are a dark and surveilled country headed for very bad > days unless we can get a grip. > > Let me know of any questions/afterthoughts. > > Thanks again Doc!! > > LaVonne > > 503-720-0690 > > On Tue, Feb 11, 2020 at 1:31 PM Doc Searls > <anitadrink(a)gmail.com <mailto:anitadrink@gmail.com>> > wrote: > > Headlines: > > India’s About to Hand People Data Americans Can > Only Dream Of > By Saritha Rai > January 12, 2020, 11:01 PM EST > > • New system aims to protect data and unlock the > credit market > > • India joins a growing movement to give > consumers data control > > <https://www.bloomberg.com/news/articles/2020-01-13/india-s-about-to-hand-pe…> > > Anybody familiar with this want to lay it out in > VRM terms (good, bad or otherwise)? > > Doc > > > > -- > > LaVonne Reimer, Founder > Lumenous > 503-720-0690 (cell) > lavonnereimer (skype) > > www.lumenous.net <http://www.lumenous.net/> > > _______________________________________________ > WG-UMA mailing list > WG-UMA(a)kantarainitiative.org > <mailto:WG-UMA@kantarainitiative.org> > https://kantarainitiative.org/mailman/listinfo/wg-uma >

1 0

Re: [WG-UMA] [projectvrm] A ... not sure what, exactly ... development in India
by Adrian Gropper 01 Mar '20

01 Mar '20

Julian, Thank you for engaging, as you always do. This is not about my definition of strict or anyone else’s. It’s about the role of standards to enable and empower individuals. For example, as I understand it, digi.me has an ontology component and a consent component. The ontology component can and does add value because it has access to the data in the clear. The consent component can and does add value because it can control use of the data without access to the clear text data itself. (It could, in principle, control the flow of data directly from a streaming source to a data processor destination.) The decision on how to connect the ontology component to the consent component of digi.me is entirely up to digi.me. They could choose to use a standard like UMA internally and also expose that control connection externally. This would empower the individual customer to make separate choice of their ontology or their consent managers. This, in turn, reduces lock-in and promotes competition, both of which can benefit the customer. The tradeoff comes when a service provider that builds on separation of concerns, such as our HIE of One Trustee project, cannot find investors to sponsor the added standards work and risk of customer churn. Separation of Concerns is therefore a finance problem more than it is a standards problem. I’m aware of only a few groups that have chosen to tackle the finance problem and they are quite immature. One is the Digital Life Collective (by Philip Sheldrake) others look more like Decentralized Autonomous Organizations (DAO) and more recently, Decentralized Finance (DeFi). These groups are so busy re-inventing management structures that they can’t be bothered with mundane things like standards process. The other group worth mentioning is MyData. They are also immature and have partitioned this Separation of Concerns issue into a MyData Operator discussion (where digi.me is a participant). What MyData does has some impact on immature EU Data Privacy regulations. Our handling of the SoC and standards will be, IMHO, the real test of the MyData model. (Privacy regulators are the most immature group of all. They are still oblivious to the relationship between standards and competition. The giant platform vendors are desperately hoping to be regulated as giant platforms rather than give innovators the opportunity that comes with Separation of Concerns.) In other words, customers almost always come second to finance. The sole exception seems to be open source software projects which dispense with finance by design and deal with management as little as possible. - Adrian On Sun, Mar 1, 2020 at 10:57 AM Julian Ranger <Julian(a)jranger.com> wrote: > Adrian, > > > > Re “the pushback is that no private business wants to be strictly a data > controller and forego access to the data itself as part of their business > model” > > > > Some businesses, i.e. digi.me, want to be neither a data controller nor > have access to the data itself – and that is ultimately the right answer. > Don’t see, touch ro hold the data. Now whether current implementations > (ours included) meet you strict definition of SoC I don’t know, but to me > it is clear that the individual’s data stores should only be handled by > software that the individual chooses to run and that processing should sit > within thinteh inidividual’s domain (until such time as the individual > specifically allows data to leave their domain). > > > > Jules > > > > > > *From:* Doc Searls <anitadrink(a)gmail.com> > *Sent:* 24 February 2020 20:02 > *To:* Adrian Gropper <agropper(a)healthurl.com> > *Cc:* Tim Reiniger <tsreiniger(a)gmail.com>; LaVonne Reimer < > lreimer(a)lumeno.us>; ProjectVRM list <projectvrm(a)eon.law.harvard.edu>; > wg-uma(a)kantarainitiative.org WG <WG-UMA(a)kantarainitiative.org> > *Subject:* Re: [WG-UMA] [projectvrm] A ... not sure what, exactly ... > development in India > > > > > > On Feb 24, 2020, at 11:49 AM, Adrian Gropper <agropper(a)healthurl.com> > wrote: > > > > This is a good thing. There’s some overlap between the Solid folks and > those of us working on SSI standards. Although they don’t say it publicly, > I’ve been assured that Inrupt will implement and respect what I call > Separation of Concerns standards. > > > > I saw the same potential synergies. > > > Separation of Concerns means that the data controller can be specified by > the data subject separately form the data storage or other data processors. > UMA2 can already do that and it’s likely that the upcoming IETF OAuth3 > standards will also support SoC. A pod would then be a special case of a > co-located controller and storage. > > > > Our HIE of One Trustee project has always done this. We keep separate > github repos for the two separate concerns in order to demonstrate the > standards that connect them and to highlight gaps in the standards that > still need improvement. > > > > Defining agency as requiring SoC seems to be controversial. There’s > pushback because the standards are immature. I suspect another, unstated > reason for the pushback is that no private business wants to be strictly a > data controller and forego access to the data itself as part of their > business model. > > > > Sounds right. > > > I’m curious what others on this list think about defining agency in terms > of SoC. > > > > My own small thought on it (having not thought or known enough about it, > so far) is that it makes sense. Given the ease of data spread—with lost > personal agency in the midst—it's important to keep ambiguities minimized > and separate responsibilities clear. > > > > Doc > > > > - Adrian > > > > > > > > On Mon, Feb 24, 2020 at 4:26 PM Tim Reiniger <tsreiniger(a)gmail.com> wrote: > > Adrian, > > > > Thank you for compiling this great list! If you haven't seen this story, > this might become an addition: > https://www.schneier.com/blog/archives/2020/02/inrupt_tim_bern.html. See > what you think! > > > > Regards, > > > > Tim > > > > On Thu, Feb 13, 2020 at 1:02 PM Adrian Gropper <agropper(a)healthurl.com> > wrote: > > This is an important development in the global context of giving agency to > individuals. Here is my current list of related initiatives. Note that all > of these are works-in-progress. In no particular order: > > > > - US ACCESS Act > https://blog.petrieflom.law.harvard.edu/2019/10/24/access-act-points-the-wa… > > - EU+ MyData Operators > https://docs.google.com/presentation/d/1J71J8_8kSiIXmVXSkQbRixmv0rxQXC_d-I6… > > - EU Open Banking and PSD 2 > https://www.altexsoft.com/blog/engineering/open-banking-and-financial-apis-… > > - India Open Banking https://www.bloomberg.com/news/articles/2020-01-13/india-s-about-to-hand-pe… > > > - SSI and Rebooting Web of Trust > https://github.com/WebOfTrustInfo/rwot10-buenosaires/blob/master/topics-and… > > - IETF Transactional Authorization > https://tools.ietf.org/html/draft-richer-transactional-authz-03 > > > > The common thread across all of these is an authorization server acting on > behalf of a data subject. This is a very different model from GDPR, HIPAA, > CCPA, the proposed India Personal Data Protection Bill or the other 9 > privacy bills being considered in Washington. > > > > - Adrian > > > > > > > > > > On Tue, Feb 11, 2020 at 2:07 PM LaVonne Reimer <lreimer(a)lumeno.us> wrote: > > Thanks for bringing this to our attention. > > > > This is squarely my area (by way of Descant). I'm a bit crunched at the > moment so not able to provide a thorough analysis relative to VRM but if > you think back to everything I've said in past VRM days as well as on these > threads, it claims to provide a data facilitator platform congruent with > all that working code I've been sitting on for much too long! > > > > First, thoughts on the article. Then below that, a reference to the > Equifax announcement yesterday. > > > > A couple characteristics that fit the VRM way, and that are at least > implied in the article: > > - It revisits the flows of data for credit analysis "through the eyes > of" the subjects of the data. It's always important to question the extent > of this agency when it's banks rolling out the solution but the spirit of > subject-driven data flows seems to be present. > - It addresses a gap in data pipeline management on a narrower basis > than will be necessary to scale and than we offer via Descant. See the > specific reference to an India-specific requirement that financial data be > reported in a standard, machine-readable format. More on this below. > - It suggests consents will be easier to understand because data > subjects can choose to share portions of data. This is a very big challenge > and one we've largely solved by enabling UI/UX that spreads out consents > across touchpoints. Easier to provide for context-based consent in that > manner. It's not clear that India is thinking in these terms. Indeed the > intent seems to be that fintech startups will build apps on top of the > platform. Unless there are constraints on the spirit and intent of such > apps, they could be heading back to opacity with little opportunity to pull > it back. Also, more on this below. > > *Data pipeline management: * > > Of all the big data challenges addressed over the past decade, pipeline > management has only recently popped up as a significant area. I have only > seen developments (and patent filings) for pipelines within enterprises. > The essence is that applying transformation, processing, and governance to > data while in motion streamlines its path to insights. As the category > implies, it's a more fluid approach to data management for sure as compared > to the old ETL model and arguably data lakes. > > > > A facilitator platform that replaces credit bureaus will need to > management multiple pipelines, each potentially presenting different levels > of privacy-sensitivity and latency concerns. The solution announced by this > article is a reasonable start but not as extensive as would be needed to > truly replace an Equifax. I didn't see a plan to, say, open source the > system so extensions for additional data pipelines could emerge. > > > > Note that this data challenge is not obviously about privacy but it is > critical if the goal is to replace intermediated data solutions. This is a > good a place as any to include a link to an opinion in yesterday's NYT > about the indictment of Chinese hackers for the Equifax breach. Author > makes the point that the whole model underlying Equifax and data brokers is > the problem. And that is a more complicated data pipeline problem than > consents. > > > > > https://www.nytimes.com/2020/02/10/opinion/equifax-breach-china-hacking.html > > > > *Context-based consent etc:* > > Just adding a short note that I've been studying recent efforts to add > language to open source licenses that encompasses privacy, data rights, > and/or human dignity. As far as I can see, this is all new territory. In > the "humanitarian license," the author combines language from the MIT open > source license with language out of the UN's declaration of human rights. > So far OSI seems poised to reject it as a "blessed" open source license. > NYU School of Law also has some similar projects underway. > > > > I care about this because when I think about open sourcing the > data-sharing platform of Descant, I worry much more about extensions in > conflict with the ethos of people in charge of their own data than specific > uses of the source code. This goes to my concern that opening up for > fintech startups would be problematic if there's no way to police data > usage. > > > > Again, this is all off the top of my head. The title is correct that it is > better than the US but then we are a dark and surveilled country headed for > very bad days unless we can get a grip. > > > > Let me know of any questions/afterthoughts. > > > > Thanks again Doc!! > > > > LaVonne > > 503-720-0690 > > > > On Tue, Feb 11, 2020 at 1:31 PM Doc Searls <anitadrink(a)gmail.com> wrote: > > Headlines: > > > > India’s About to Hand People Data Americans Can Only Dream Of > By Saritha Rai > January 12, 2020, 11:01 PM EST > > • New system aims to protect data and unlock the credit market > > • India joins a growing movement to give consumers data control > > > > < > https://www.bloomberg.com/news/articles/2020-01-13/india-s-about-to-hand-pe… > > > > > > Anybody familiar with this want to lay it out in VRM terms (good, bad or > otherwise)? > > > > Doc > > > > -- > > LaVonne Reimer, Founder > Lumenous > 503-720-0690 (cell) > lavonnereimer (skype) > > www.lumenous.net > > > > _______________________________________________ > WG-UMA mailing list > WG-UMA(a)kantarainitiative.org > https://kantarainitiative.org/mailman/listinfo/wg-uma > > >

1 0

UMAnitarians at RSAC: Meet in person instead of telecon?
by Eve Maler 26 Feb '20

26 Feb '20

Do we have enough UMAnitarians in SF to make it worthwhile to try and get together Thursday morning for breakfast at, say, 8am instead of doing our call at 6:30am PT? *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 1