Standing agenda for 2019: Work on producing our second legal-business framework report by September, initially focusing the work on use cases that illustrate each of our mappings from business relationships (and changes in those relationships) to UMA technical artifacts.
...
(Notes from the 2015 series were kept in email: 2015-08-0706, 2015-08-14, 2015-08-21, 2015-08-28, 2015-09-04, 2015-09-11, 2015-09-25, 2015-10-02, 2015-10-09, 2015-10-16, 2015-10-23, 2015-10-30, 2015-11-06, 2015-11-20, 2015-12-04, 2015-12-11, 2015-12-18.)
Date and Time
"Legal" topics are currently being covered in a separate legal-business framework meeting series. See the UMA calendar for details-18.)
Date, Time, Documents
"Legal" topics are currently being covered in a separate legal-business framework meeting series. See the UMA calendar for details. Current documents being worked on (WG participants will receive edit access for the asking; others may receive view access):
- Business-Legal Framework and Use Cases (GDoc)
- Mapping Graphics (GSlides)
- Legal Role Definitions (GSlides)
- Definitions and Use Cases Spreadsheet (GSheet)
2020-01-28
Attending: Eve, Domenico, Colin, Tim, Lisa
This is the last time we'll be meeting at this hour where it's the "biz-legal call". We'll see what the results of the Doodle poll are in terms of a new hour. Please fill out that poll!
Tim likes that the Guardianship paper really wrestles with the temporal dynamics of guardianship. Tim had introduced the concept of "diachronic" issues in our work on the first Report, though it looks like the word itself didn't survive the editing process through to the final version. These aspects reflect (literal) life cycle changes that traditional IAM typically handles through workflow approvals and the like. Colin would have liked to see a reflection of existing work. Likely people are not fully understanding both UMA and OAuth, both of which handle delegation of authorization in some subtle ways. We need to make this really easy to understand with some demos.
The very first step in a Me2B relationship, delegating a guardian – or other RRA (resource rights administrator) – relationship, is not yet today interoperable in an OAuth or UMA world. Does profiling OAuth with a claim representing this semantic make sense?
We looked at the original NZ POC case study to see if it had any examples of guardianship or interesting delegation. The Aroha/Bailey use case is about "classic" delegation of access, though it includes mobile notifications of IoT data, which is nice. The ministry of education/picking up kids use case is about chaining delegation.
At Kantara we produce reports and specifications. We could analyze the use cases covered by the paper; our BLT work address guardianship along with various non-guardianship delegation use cases between data subjects and RRAs. UMA's architecture and Sovrin's architecture are pretty different. However, Identos has created an extension that seems to be potentially valuable in privacy-enhancing an UMA AS in an SSI-ish context, and Adrian and his cohorts have integrated uPort for providing RqP verifiable claims. We'd like to get a broader shared understanding in the group about these options.
2020-01-21
Attending: Eve, Andi, Domenico, Lisa, Nancy, Tim, Colin
Through her colleagues, Eve recently came upon the work of the Sovrin Guardianship group (which overlaps in some respects with our biz-legal work) and the DIDauthz work (which references OAuth and UMA). Nancy brings up the FAST work in healthcare, which is trying to accelerate solutions to common challenges. What is the best way for us to accelerate our own work and goals, and how we can center on the end-user perspective (the "User" in UMA)? Lisa notes the DIDUX working group, given this desired perspective.
Tim notes the rationale stated in the paper on p. 9 for the guardianship work: "In short, carefully constructed guardianship is essential to SSI. Without it, SSI solutions will either tend towards centralisation or exclude billions of people." This is somewhat a weird way to think, in Eve's opinion, because it's constructed around the goal of digital identity (an "input metric") as opposed to what people actually want out of digital services (an "output metric"). If we don't get out of this mindset, we may not get to the point of being creative enough to solve the next generation of problems. Tim notes that the UN and the World Bank are saying that legal identity is a human right. (Though "legal identity" is not the same thing as "(a) digital identity".) She takes the sentiment of wanting to solve the thorny problem of "offline and online" mixes of people, though. Lisa suggests that we pull Adrian into an analysis. Eve thinks Justin could shed light too.
Eve is going to pare down our meetings so that we only meet on Tuesdays. She'll send a note to the list just to be sure this doesn't cause any heartburn for our voting participants.
Homework for next time: Everyone please study the paper and the use cases, paying particular attention to the terminology and concepts, and seeing if we have comments or could use some of them. Eve will look into her team's ability to develop demos of the use cases in the paper (or equivalent), on an UMA/OAuth basis and potentially SSI. Others are welcome to do that too.
We are meeting next Tuesday. No meeting on Feb 4 as Eve is traveling.
2020-01-07
Attending: Eve, Tim, Lisa, Domenico
Could UMA be additive as a solution to the human rights efforts such as in the UN? Digital human rights is a driving motivation for Lisa. Rights and corresponding responsibilities need to be ensconced in technology where possible. An old writeup about UMA implications of Privacy by Design principles (for which the tiny URL is http://tinyurl.com/umapbd) is probably a bit out of date but helpful on this score. Me2B recently did a small ethnographic study, discovering some interesting – if perhaps nominally obvious – things about surveillance and awareness about it. There is a faction among healthcare IT people saying that informed consent is literally impossible. This is akin to the qualia problem: you can't inspect someone else's brain to know what they know. If this is the case, and even given that "consent is stupid", it's better to assert permissions as proposed in the LeVasseur/Maler paper. If people won't even read books now because their attention spans are shot in the modern era, then how can we expect them to read ToS? There's a Japanese word for the pile of books you have but haven't read, tsundoku, and now we have the digital version too.
To bring the news about what UMA can solve and how it can support "IRM" challenges, we want to publish the material we've put together in smaller bites, possibly in blog posts.
We talked a bit about the JLINC protocol, which can be found here.
2019-12-17
Attending: Eve, Cigdem, Domenico, Lisa, Colin
Note that we did rename (renumber) the states, so that the "little Johnny" use case is now State 2 because it's the next most common.
Domenico shared a great new non-tabular graphic that is helping us think about what we really mean by the first four states. (See the wiki version of these notes for the graphic.)
In the "Mapping graphics" deck, Eve had put some comments about needing to see the DS-as-RRA aspect as donning a role, and Cigdem raised this as well. The states we've been talking about are at a pretty operational level, meaning they allow us to specify details of implementation such as role changes and provisioning/deprovisioning requirements that could built into compound workflows. We're likely to have to go to the level of tackling the "multiple Data Subjects" use cases.
In healthcare, you could commonly have state transitions like 2-4-1, or 2-4-2-1 as little Johnny has his mother added to manage his EHR, then his father, then grows up and starts managing his own resources. We actually map cradle-to-grave scenarios somewhat like this in the "Legal role definitions" deck.
How does one map three-dimensional values in two-dimensional space? You split out one of the dimensions to two flat ones, or you have multiple tables. Ugh.
We observe that adding and removing RRAs is a provisioning/deprovisioning action, and adjusting whether the DS is one of the RRAs is a role change action, what if we think of this as two different "tables" (maybe tables in a technical viewpoint, but potentially not for the document)? They're orthogonal actions, which could be built up to form a "workflow" that triggers when you need to move from one state to another, like when Johnny e.g. hits a certain age, or succeeds in asking the court to be emancipated from his parents, or when a couple divorces, or when a temperature sensor hits a certain temperature, etc.
There can be harder edge cases for what to do around, say, historical bank account data vs. new data going forward in the case of multiple-down-to-single bank account data. What do banks do today? Do they close the joint account and open a new single-owner account for the newly divorced person?
Lisa shared a great "IRL mapping sketch" that is inspiring us to add a graphical version of the "typical use case" to the doc.
2019-12-10
Attending: Eve, Andi, Cigdem, Tim, Colin, Mark, Nancy
Lisa and Eve subsequently discussed the intro section and Eve did some more editing of it. This led her to bring up a few more legal party terminology and definition questions. It looks like we can remove the "Individual or Legal Person" phrases where they occur currently in the definitions of RRA and RqP. Let's do that. (Eve edited this live on the call, in both the canonical spreadsheet version and in the report.)
We discussed the question of Requesting Agent/Requesting Party. Tim made the excellent point that, until we hear that the outside world has a problem with the terms, we probably don't want to obsess any more about it. We could change it later if it turns out to present friction. We acknowledge that "agent" is a very different thing in the legal and technical worlds. Capitalized words are used in their legal party senses and we say that in the report, so legal experts and similar should be prepared to understand such terms in their legal senses.
We discussed whether to cram mentions of "agency contract" and "access contract" into the pentagram diagram (new nickname!). Should we do "progressive disclosure" in the document and have a version that has just the dashed pentagram, possibly with the agency and access contract wording added, and then a version with the delegation and license details added? If he is willing, let's ask Domenico to create a short series of diagrams.
AI: Eve/Domenico: Eve to ask Domenico to create several pentagrams (these are all additive):
- One with just the dashed pentagram lines and agency contract/access contract labels (as illustrated on the old "spaghetti" diagram on slide 7 here) – delegation/licensing relationship arrows removed
- One with all the delegation/licensing relationship arrows added back, as currently exist in the diagram
- One with a "spur on the left side with Data Subject-to-RRA relationship arrows added (as illustrated on the left side of slide 9 here)
- One with a "spur" on the right side with a Requesting Party-to-Requesting Agent arrow added (as illustrated on the right side of slide 9 here)
AI: Eve/Domenico: Eve to ask Domenico to create two table-oriented "state" diagrams (slides 3 and 4 here):
- One without arrows
- One to reflect the state changes with the arrows
2019-12-03
Attending: Eve, Domenico, Lisa, Nancy (regrets: Tim)
Lisa's and Eve's "Beyond Consent" article is now in a near-final version; Lisa kindly agreed (when asked by Eve) to distribute this version to the UMA WG.
Consensus: We looked at the Typical Use Case section of the doc and concluded that we do like having the "typical use case" for technical roles presented, followed by the formal definitions of said roles. Let's also plan to publish the spreadsheet as a companion Report because it can serve as the "source of truth" of definitions and relationships. We can prepare an Annex or Appendix or whatever we want to call it in this Report that consists of tables, along with a citation to the spreadsheet that has "live" data. We can say "In case of any discrepancy, the spreadsheet has the most accurate data" etc.
Assumption: We note here – but don't want to note in the Report, because it would complicate things for the readers – that EHR data typically gets selectively copied to a portal, and doesn't "live" there. If we elucidated all of our assumptions and caveats in the "typical use case", we'd never get anywhere. Nancy is clarifying for our group exactly how SMEs would split hairs on primary storage of health data. We agree that our audience will be motivated simply to understand the UMA paradigm at a relatively high level at this stage.
Lisa asks (paraphrased): When we say the resource owner "manages" resources at the RS and "controls" access at the AS, is she doing that at an app of some sort? Why are we saying Alice is interacting directly with services here and not apps? She does use apps, but we don't talk about them in protocol-related conversations because those interactions aren't "on the wire"; there are no UMA-dictated messages involved. However, those who deploy UMA-enabled systems do have to concern themselves with the implementation and deployment of such apps! Eve's recent webinar with Steve Giovannetti covered the four elements of integration and deployment needed:
- Deploy an AS. We have noted many times that policy engine functionality is something each AS can compete on because it lets ROs get more sophistication in policy-setting ability. However, often in healthcare use case conversations, the idea of policy interoperability comes up too.
- Integrate/create your client app (if you already have a client, you have to UMA-enable it) – is there room for creating "UMAlet" middleware? Gluu has talked about its open-source middleware in the past.
- Deploy your RS (if you already have RS apps, you need to UMA-enable them) – there are a couple of different approaches, gateway/proxy (could be in the cloud) and an SDK for UMA-enabling apps. The former seems preferred. Eve calls these "protectlets"
. - Encourage data partners to implement their own RS's – if you have a wide data ecosystem (i.e., multiple RS's in different domains), your partners will have to UMA-enable their hosts. Helping them do this is good business! See just above. Nancy notes that Patient Centric Solutions' new PatientShare offering does exactly this.
This whole list opens up the idea of publishing an auxiliary document called something like an UMA Deployment Guide and stimulating open source (once more) to encourage deployments.
Proposal: Lisa suggests that, since the Operators are extremely likely to be Legal Persons, we should acknowledge the obvious and enhance the formal definitions in the document somehow so that it won't trip up people who read them there. Maybe we can insert some bracketed text and/or italicize some? She will draft some candidate text and let's discuss it on the list. There are so many considerations around this question – rhetorical, UMA maturity, etc., that it's not even funny.
Domenico comments on the concept of a "data ecosystem". We've been talking about wide ecosystems for a while, but it seems there are different kinds of wide ecosystems. Lisa says: "UMA is an ecosystem builder." Nice! Eve has often called OAuth2 a protocol framework because it has so many choices that it's not just one protocol; unfortunately that has risked interoperability and security. XYZ is trying to enable protocol-building without all those sacrifices. UMA is meant to make it possible to build data – and data-sharing – ecosystems without sacrifices and compromises.
2019-11-05
Attending: Eve, Nancy, Tim (regrets: Cigdem, Andi)
We have been dealing with the "multiple RRAs" state table as if there is always and only a single DS. For simplicity, perhaps we should continue in this vein. It would be insanely complex to imagine that there are multiple DS's as well. The "co-equal rights" question is about resource administration rights specifically. However, a number of real-life use cases have the "multiple DS" situation: joint bank accounts where both account holders should have exactly equal rights, etc. In implementation, this is a problem and is generally handled badly, in that one person is made "primary" and the other(s) "secondary. In some use cases this divide is appropriate (main householder vs. other people in the household for digital streaming services), but for things like a joint bank account or other spouse-type membership accounts, both/all holders should really be co-equal – until such time as there is a divorce or other split and the number of DS's goes back down to exactly 1. What if two brothers share a bank account and one of them has to be removed from managing it for malfeasance and the other brother is managing it for the two of them, somewhat like in the Gravity Payments case?
To clarify whether we need to focus on multiple-DS use cases and whether they are sufficiently valuable to solve, Eve will ask an FSI/bank expert to join us at our next meeting. Nancy will do the same for a genomic data expert.
The current use cases that we've mentioned under State 3 in the table ("joint bank account each with equal access, joint tenancy") look like they're not actually correct because they probably refer to multiple DS's, so we have to sort out whether we're going to treat multiple DS's or not, and move the use cases over if so.
AI: Nancy and Eve: Find experts to join our next call to establish existence and priority of multiple-DS use cases in different sectors.
2019-10-29
Attending: Eve, Cigdem, Nancy, Andi, Adrian, Tim (regrets: Domenico)
We worked through the section after the Introduction. We want to get to the RRA-centered states and state changes content next time. Nancy has provided some rough content/use cases that are healthcare-focused that we can use as a base. Let's also add (say) FSI-focused use cases. There is also the co-equal rights challenge (multiple co-equal resource owners/RRAs? and also DS's?).
2019-10-22
Attending: Eve, Colin, Nancy, Andi, Domenico
We worked directly in the document, accepting suggestions and editing the results.
We discussed whether we should keep "Alice" for consistency as the resource owner name, vs. use variety (e.g. the "Jane" example as in Andi's new "simple example up top).
AI: Domenico: In the Mapping Graphics slide 19 graphic, can he please ensure that the "technical terms" (currently with no-color background outside the legal terms) be distinguished somehow (maybe with italic or with a color background) and be all lowercase?
In the Typical Use Case section, let's try telling a brief narrative story about the life insurance use case, either before or after the technical definitions, so as to make it easy for nontechnical readers to understand those definitions. We do need the technical definitions – otherwise we can't delve into the permission token/license work that the paper needs to do.
2019-10-01
Attending: Eve, Andi, Domenico, Nancy, Tim, Cigdem
If we are addressing a business-legal audience, should we start with a relatively technical approach, or should we start with use cases? We do have a challenge with people not understanding UMA. We are finding confusion out there. We did say at the end of the last paper: "The next papers in this series will explore the application of UMA licensing model to specific use cases for various categories of owners and custodians of personal digital assets in the global digital information society." So we could start with a (full?) set of concrete use cases, and then work through them step-wise.
So let's have an outline like this:
- Part 1: Introduction
- Explain UMA at a high level to a primarily business-technical audience
- Explain technical terms in the context of State 1: RO = DS = singular RRA
- Explain UMA at a high level to a primarily business-technical audience
- Part 2: Delegation of Resource Rights Administration Use Cases
- Use cases written in simple language (maybe one paragraph each), illustrating various of the DS/RO/RRA states and state changes
- A state machine showing the states and changes
- A section working through those use cases with the permission token flows and consequences
- Part 3: Sharing relationship use cases (policies change based on changes in relationship with RqA?)
- Subsections are like part 2's subsections...
- Part 4: Delegation of Requesting Agent Role Use Cases
- (e.g., Alice shares her connected car with Bob and he gives his keys to her car to the valet for parking)
It's perfectly fine to blow up the text that's in the current document vs. trying to make the existing text work. Nothing in there is sacred. Andi's schedule has now cleared enough that he should be able to contribute significantly for the next couple of weeks.
Future meetings: The call next week (Oct 8) is already cancelled. Eve can't make the call on Oct 15 but Ruth P has kindly agreed to start the call!
2019-09-24
Attending: Eve, Cigdem, Domenico, Nancy, Tim, Vlad, Sal
At the DS-RRA wrangling layer where UMA doesn't have any artifacts, there will typically be a lot of identity and access management taking place. What technical artifacts can we expect to be used there? Typically many proprietary ones, but also potentially some standardized ones, such as federation standards like SAML and OIDC, maybe provisioning standards like SCIM, maybe auditing-friendly standards like consent receipts, etc. We have already mentioned consent receipts in our "devices and artifacts" capture.
The topic discussed last time was: Could/How could UMA be used to achieve user control of the initial user relationship with a service provider? The answer in today's world is that UMA was designed with today's imperfect situation in mind, which presumes opt-in cookie consent, opt-in terms and conditions, opt-in OAuth app connections, and opt-in AS-RS connections for UMA, which are all sub-optimal. However, the Lisa/Eve paper proposes an architectural way forward for fixing these broken patterns, which is to use the "Open Banking trick" for intent registration. The trick uses the nexus of the Open Banking APIs and OIDC request objects to allow transaction authorization of payment of a specific amount of money for a single payment, vs. authorization of an OAuth scope for an indefinite period. Theoretically, this "intent registration" ahead of time by a user at a client app (TPP) could be used to allow transactional (one-time) "intent registration" of user-centric terms and conditions, not just payment of money. Flows still to be worked out for each use case of user/service interaction, of course!
Cigdem had commented about moving up the Legal Parties discussion in the document and we agree. She will do some "invasive" editing of the doc.
Eve can't make Oct 8th or Oct 15th. It sounds like we have critical mass of people to join on the 15th so Eve will ensure someone can open the bridge on that day. In the meantime Cigdem will edit the doc.
We haven't discussed Nancy's latest submitted set of use cases, including healthcare and banking. One of Eve's goals is to include as many submitted real-life use cases as possible. We've already got quite a few. She's started a couple of templates for some more in the "mapping" slide deck.
2019-09-17
Attending: Tim R, Lisa L, David Thelander, Pete Palmer, Ruth P (Kantara)
The group discussed whether and how UMA currently treats first order legal relationships (i.e. the creation of the initial legal relationship between the consumer/data subject/legal representative and the service provider and/resource server operator. For purposes of this first order legal relationship, the group further discussed the possibility of deploying a 'reverse EULA' as discussed in the recent paper published by Lisa and Eve. Lisa reported that the Me2B organization has a legal subcommittee that is now actively developing model 'reverse EULA' language. It was suggested that UMA might collaborate with Me2B on this effort. [Editor's note: The Proposed UMA Business Licensing Model contemplates that the ASO, using an Access Contract vehicle that authorizes licensing, is the entity that creates the first order legal relationship with the Service Providers and Resource Service Operators.]
Follow-up actions: Lisa has offered to share information on the Me2B efforts to create model 'reverse EULA' terms. In particular, Scott David has prepared excellent initial legal materials. David T has legal expertise with software licensing and also offered to assist with developing standard licensing terms.
2019-09-10
Attending: Eve, Andi, Nancy, Domenico, Vlad, Cigdem
Our agenda for today: "Start to document the full value and structure of a final "WG draft report" (or is it a spec?) deliverable that we can put together with all this fodder based on our work over the last several months. We had said our deliverable timing would be September... :)"
The value-add of "UMA-biz-legal-relationships" above and beyond "UMA-technical", we think, is that (e.g.) the operator of a service or client, or the RRA or requesting party, can auditably prove what another party needs it to prove regarding a commitment or promise it has made to the other party. And if necessary, if enforcement can't take place at a technical level, it can take place in a court of law as required (because you have audit logs and non-repudiable artifacts to point to). All of these loosely coupled parties need to cooperate and have their interests sufficiently aligned to have selective sharing work. See examples listed in the Sources of liability tension section on the UMA Legal page here.
Which party cares most about changes, additions, and subtractions in the RRA role? The ASO. The PAT is the "thin reed" of technology (a technical artifact) that binds the ro, as, and rs. Is it enough to give us a technical means of controlling lots of biz-legal-relationships scenarios?
We have several sets of scenarios. One is the ro/RRA state diagram. A second could be a rqp/Requesting Agent/Requesting Party state diagram (that doesn't exist yet). A third that doesn't have a diagram yet is where only policies (a non-UMA artifact) change in response to the ro/RRA sharing on the basis of a relationship. Example: Alice wants to share a set of resources with "whoever is in the 'spouse' relationship" with her. If she indicates that no one is now in that relationship, her policies reconfigure and sharing ends. What's attractive is that both Alice and the ASO and RSO(s), by extension, can all know that sharing ended even if it's a big complicated set of resources that was shared. In this third case, is it really in our scope to be talking about these policies? We could say they're out of scope, but some "consent" (could be described as authorization policy and sometimes is) data formats are standardized, e.g. in HL7 (a Consent record) and XACML, and it is sometimes desired to "federate" consent servers, and even though UMA doesn't standardize policy data formats, it's sort of an adjacent use case. It exists on a continuum with UMA use cases. Plus, all three sets of scenarios seem to end up needing to be combinatorial at the end of the day.
Note that HL7 federated consent implies that you have a federated consent server that you can read and interpret. Consent itself is PHI (personal health information). While UMA technically doesn't require policy conditions to be stored at an AS (this is deployment-specific), it does assume policy-setting can happen at the AS; there are numerous examples in the specs throughout. And the privacy considerations in UMA FedAuthz talk about PII involved in resource registration and policy-setting only implicitly ("the authorization server may come to learn a great deal of detail about Alice's health information just so that she can control access by others to that information"). For example, if Alice tells her AS to share all her data except HIV-related data, that exposes that she may have HIV-related data. The HEART profile for OAuth/FHIR tries to protect against assumptions about existence of confidentiality/sensitivity scopes, but it's still hard not to make assumptions.
Just because you can separate the AS and RS, it doesn't mean they're necessarily in separate organizations/domains. Some privacy considerations may not apply in cases where they are run by the same organization.
Let's start drafting collaboratively. A GDoc is a great way to start, following the (Kantara-inflected) RFC style. Andi and Cigdem are willing to jump in on co-authoring with Eve. Nancy is willing to be backup after the next two weeks.
AI: Eve: Start a skeleton draft doc for next time.
AI: All: Sort through the next two batches of scenarios and work on the wording we're using in the second scenario batch in our next meeting.
2019-09-03
Attending: Eve, Andi, Domenico, Lisa, Nancy, Peter, Tim, Colin
Eve has put a new table in the Business Model Mapping Graphics deck for our perusal. We discussed ways to improve it, and moved around the arrows to make it more understandable and added use cases.
We posed the question from a few weeks ago "For the care scenarios, do we need a primary carer/super admin type of role or are all entities in RRA equal?" It's not just for "care" scenarios. When a RRA/DS has the individual capacity to grant access to another (say) individual, then they are not equal, and access that can be granted can be taken away. If the two are truly equal in their rights (such as joint tenancy or a joint bank account), it's because there are institutional factors at play such as a law granting that equality. If it's because they are married and there's a law saying spouses have totally equal rights in a bank account, and they then get divorced, it's by law that the account access gets disentangled, not just by "access management technology". So if there were two RRAs (two married bank account holders, both DS's), and we went from state 2 to state 1 when then got divorced, it was because one of them is no longer going to be a DS in future and should no longer be an RRA in future. Presumably in this case it's not automatic but manual, and the parties need to tell the system what action to take (e.g. which party wants to remain in the system, when to take action, etc.).
How complex should we get? In this new table, do we assume there's one DS? Recall that last time we discussed multi-DS scenarios and it rapidly became so complex we became uncertain about how to capture it.
What are we documenting? The value is to be able to show proof as an ASO that the correct RRA is doing the sharing. Each "design pattern" represents perhaps many use cases in many different sectors.
We posed the question from a few weeks ago "Federated authorization or not? Arguably, personas of a DS and a single DS have the same identity verification risk. If personas, then ”DS” in the state machine is replaced with “persona”. The key assumption: KYC works – if that fails, all the rest fails." See the new diagram in the Biz-Legal Mapping slides; any one resource owner/RRA is going to have a single login at an AS but could have a unique login at each RS that is federated with that AS. The single AS login could be strongly proofed, meaning that the ASO could prove strongly who that RRA is.
Eve has moved our biz-legal meeting a half-hour earlier next week as she has a partial conflict.
2019-08-06
Attending: Eve, Adrian, Cigdem, Domenico, Lisa, Nancy, Sal, Thomas, Vlad, Tim, Colin
Cigdem sent some thinking around the "multiple DS" cases:
...
There are two mechanisms of state transition (not reason, but mechanism) we might tend to see: either automatic or manual. Automatic means that you don't need consent or any other active participation by parties for the transition to occur. It times in (little Johnny grows up(), or a law now goes into effect, or a sensor reports a high enough temperature, or whatever. You might, however, need notification and other workflows. Manual is when parties do need to take action, such as consent or permission or setup (such as registration). Applications could need custom workflows in either case.
...
- Agreement that turns a service provider into an RSO (wasn't included in business model report)
- Agreement that turns a service (or app) provider into a CO (wasn't included in business model report)
- Agreement that enables a Person to act on behalf of a Data Subject [which puts them into position to act as a Resource Owner -- otherwise RO=DS]
- Agreement(s) that delegates authorization for an ASO to grant access permissions on behalf of an RO (typically Ts & Cs, privacy notice, EULA...)
- Agreement(s) that delegates authorization for an RSO to manage resources on behalf of an RO (typically Ts & Cs, privacy notice, EULA...)
- Agreement that enables a Person to act on behalf of a Requesting Party [which puts them into position to act as a Requesting Party Agent -- otherwise RqPA=RqP]
- Agreement that delegates access seeking to a CO on behalf of a Requesting Party
- Agreement that delegates permission to know and persist personal data to an ASO on behalf of a Requesting Party
Jim H has started on a CmA version of the model.
...
Arrgh, so close! Tim and Eve will try and wrap up all the remaining comments in the doc by Monday and get the e-ballot out.
2018-01-12
Attending: Eve, Colin, Tim
...