https://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note... 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 https://docs.google.com/presentation/d/1uigCMQI_TKuFyOstQTngYuZaqs36wwbE3BBj... 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. *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl