August 2019 - WG-UMA - mailman.kantarainitiative.org

Reminder: business-legal framework telecon today
by Eve Maler 20 Aug '19

20 Aug '19

...at 8am PT. I’m under the weather and won’t be joining, but Colin will open the bridge for a “DIY” call for those interested to carry on, as discussed on the Skype chat. (Let me take this opportunity to remind y’all about the Skype chat if you’d like me to add you, and if you would like to get a proper invitation to the calendar entry, I can do that too.) Eve Maler (sent from my iPad) | cell +1 425 345 6756

1 0

Draft minutes of UMA telecon 2019-08-08
by Eve Maler 08 Aug '19

08 Aug '19

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-08-08 MinutesRoll call Quorum was reached. Approve minutes - - Approve minutes of UMA telecon 2019-06-20 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-06-20> , 2019-08-01 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-08-01> MOTION: Approve minutes of UMA telecon 2019-06-20 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-06-20> , 2019-08-01 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-08-01>. APPROVED by acclamation. Decision on UMA2 IETF I-Ds - The UMAGrant <https://tools.ietf.org/html/draft-maler-oauth-umagrant> spec and FedAuthz <https://tools.ietf.org/html/draft-maler-oauth-umafedauthz> I-Ds expire on August 17 if we don't take action - We can: 1. Let the specs expire and do nothing else beyond telling the OAuth WG chairs that we rescind our previous proposal (already done), or: 2. Decide to do an independent submission and go for an informational RFC instead, presumably in the Security Area - We were leaning towards #2, but we're still open at the moment. Please review the notes of UMA telecon 2019-06-20 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-06-20> to prepare to discuss this (it also links to older notes...) There's a third option Eve forgot to list: Do what we did before, and submit I-Ds that are "empty shells" of the specs that point to the real specs and just keep refreshing them. (Here were UMA Core <https://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/> and RSR <https://datatracker.ietf.org/doc/html/draft-hardjono-oauth-resource-reg-07>.) What we did with UMA1 was *not* keep refreshing them, because we started work on UMA2. We discussed the pros and cons listed in UMA telecon 2015-10-15 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-10-15>. If we're up front about wanting the spec to serve as an "archive", then they would presumably want to avoid breaking changes. Thomas related some past experience around cryptographic cipher standardization in the informational RFC process. Option 3 pros: - We are in control of the entire process. - The IETF drafts themselves contain little that goes out of date. Cons: - We have to keep taking action every six months. - The drafts don't themselves contain any technical substance of value. - The "marketing" value is perhaps minimal since there's no IETF "blessing" involved by anyone else. What is the process of independent submission? Here is information <https://www.rfc-editor.org/about/independent/>. RFC 4846 <https://tools.ietf.org/html/rfc4846> covers the process. This <https://www.ietf.org/standards/process/informational-vs-experimental/>explains why we want this to be informational. UMA2/XYZ use case work - See last week's notes <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-08-01> for a description of what's requested. - Use GitHub? The wiki? GDocs? Point of order: The XYZ work is not UMA! Current profiles and extensions that apply to UMA2 are very welcome to be submitted to the UMA WG for standardization. We know of several of them. Let's use GitHub and markdown for our XYZ use cases. Adrian has an idea for a use case but isn't sure about how to apply the template; we can discuss his use case on the list. These use cases could include things UMA2 solves now (e.g., all the things mentioned in the introductions to the two specs), and also things UMA2 *doesn't*solve now. Nominations for chair and vice-chair - You can see the leadership team list here <https://kantarainitiative.org/confluence/display/uma/Leadership+Team>. Reminder about this. Nominations are still open. FAQ revision - Our FAQ <http://tinyurl.com/umafaq> is extremely old and out of date Do we even need this document? Or should we revise it? Take a look and weigh in. The right spec link - Please keep linking to UMA Grant Recommendation <https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html>. This will help search results point to the right file. Attendees As of 16 Jul 2019, quorum is 5 of 9. (Domenico, Peter, Sal, Thomas, Andi, Maciej, Eve, Mike, Cigdem) 1. Domenico 2. Peter 3. Thomas 4. Eve 5. Mike 6. Cigdem Non-voting participants: - Adrian - George - Colin Regrets: - Nancy *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Happy 10th UMA anniversary!
by Mark Dobrinic 06 Aug '19

06 Aug '19

Hey Uma! My agenda says that today, August 6th, is the 10th anniversary of UMA, so congratulations to you all for all the care that has been given to get UMA to where it is since all those years! Mark

3 2

Notes from 2019-08-06 UMA business-legal telecon
by Eve Maler 06 Aug '19

06 Aug '19

2019-08-06 Attending: Eve, Adrian, Cigdem, Domenico, Lisa, Nancy, Sal, Thomas, Vlad, Tim, Colin Cigdem sent some thinking around the "multiple DS" cases: *Regarding multiple DS’es the table would look like this.* *The Multiple DS case may not occur often, but is present in the case of a shared bank account between partners.* *When a couple opens a bank account, they may start at State 5, when one of the couple goes under care, they transition to State 6,* *When one of them dies, the end state is State 1 if the other partner is the sole beneficiary, or if there is another person, it may go back to State 5, or State 7 etc.* *Not sure how to represent this technically – it seems to work for DS=2; not sure it extends to a larger number.* *Do we have cases where DS is greater than 2. * *DS>1 | Rep>0 | Carer>0 | State* * F | F | F | State 1: Self-management (Single DS)* * F | F | T | State 2: Management under care (Single DS)* * F | T | F | State 3: Co-management (Single DS)* * F | T | T | State 4: Co-management under care (Single DS)* * T | F | F | State 5: Self-management (Multiple DSes)* * T | F | T | State 6: Some/All DSes under care (Multiple DSes)* * T | T | F | State 7: Some/All DSes co-manage with Reps (Multiple DSes)* * T | T | T | State 8: Some or all DSes under care and co-managed (Multiple DSes)* If we're in State 5, but I decide to co-manage my bank account with another party, what does my partner get to say about the situation given that they are a DS too? What if the two partners have different accountants; does the second partner get to/have to consent to the first partner's sharing with a chosen accountant? Divorced parents may have different custody rights and agendas – but this may fall under the single-DS case. Joint bank accounts and DNA data seem to fall under the "multiple-DS" case. What use cases are truly realistic around the RRA and sharing breakdowns beyond that? If there are whole state machine branches that are truly not realistic, let's not map them. Are trusts another example of potentially multi-DS and multi-RRA? It seems so. Trusts generally are for administering physical assets, but if they could be used for virtual assets as well, then what we're doing here could provide real added value. The ASO/AS role provides value in terms of the actual permissions as they change. Right now we're focusing on the RRA/RO role changes, which are at the "head" of UMA-technical. Is there another service/party needed, something like a "relationship manager", to manage the state transition stuff? In identity management, there are some solutions that do things like this under the heading of identity lifecycle management, relationship management, and essentially "multi-identity lifecycle management". Thinking out loud: Three siblings open a shared account, A, B, and C. They appoint an account manager, D, as an RRA. So each is in state 6. Brother B decides he wants to self-manage the account, so he may need to get permission from the others before transitioning to state 1. Sal and Mark at OpenConsent have been doing some work on policy states and state transitions; we will hope for a demonstration soon. We think it's complementary. Some concrete scenarios: This PC Magazine article <https://www.pcmag.com/article/331910/how-to-delete-your-facebook-account> explains a) how to delete your Facebook account, and also b) how to request removal of accounts for someone who is medically incapacitated and c) how to get an account memorialized when someone dies. The latter two seem RUFADAA-like and have very close analogues in our Cradle to Grave use cases. For example, in use case (b), the party making the request has to prove they have the right to be the RRA (a Rep). In use case (c), the RRA role is self-asserted but they have to prove the DS has died. Should we think of multiple state machines, one for every DS, and not maintain States 5-8 as formal constructs? Does the "relationship manager" center on resources first (e.g. the bank account) and then look up the relevant current DS(es) and RRA(s)? Relationships tend to be graph-like, without a single "head of the hierarchy" in reality, even if the RM isn't using graphDB technology to manage them. 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. Next steps: Apply the three FB use cases and Nancy's healthcare use cases to UMA and our state machine and try to make them "work" visually and in writing. *We don't have a formal meeting next week.* Cigdem will inform whether she can hold an ad hoc meeting at either our regular time or another time. We do have a meeting on *Aug 20*. *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Notes from 2019-07-30 UMA business-legal telecon
by Eve Maler 06 Aug '19

06 Aug '19

(Sorry for the delay! Hmm, the table contents don't seem to be showing here, so please follow the link to see them.) https://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+not… 2019-07-30 Attending: Eve, Andi, Cigdem, Nancy, Vladimir Prihodko (works at Lush Group, has implemented UMA1 there), Domenico, Colin, Tim; regrets from Lisa We examined the outputs of the ad hoc meeting of last week (in slides <https://kantarainitiative.org/confluence/download/attachments/77300164/UMA_…> form). The use cases drive the state machine. So you enter it at whatever point depending on the real-world circumstances. There's a question about which system you're interacting with in each use case. E.g., an employee system is an RS that holds hours worked, paid time off, etc., and personal data management is divided up between RS's. We may have to try this with use cases from different industries and see how it comes out. But presumably any single "run" of the UMA protocol only involves a single cohesive system that interoperates. If you're operating at the technical layer, by definition it sort of all "works out" because the protocol defines how things work, but at the policy layer, questions creep in: having multiple ROs (RRAs) is like science fiction (the multiple-worlds hypothesis [image: (smile)] ). If multiple RRAs can set policy, does one's policy override another's, or do they combine, or do they get "shares" in the policy in aggregate, or what? These could all be different use cases. We know of some common ones, like where the parents (or set of guardians) for a child have to all agree to release the medical records of a child. But we don't have to figure out how to implement this, just acknowledge that ASOs need to be free to meet the needs of their users. We could leverage a table as well for describing the states. That might be a useful way to discuss those two factors in common for a lot of the scenarios. We're not sure if there is a third dimension. Could any one resource have RRAs that have to "split" along these lines? E.g., *Joe* and *Jane* have a joint bank account. *Joe* is competent to self-manage it, but *Jane* becomes ill and wants to designate a third party, not *Joe* but her attorney *Jim*, to manage the account for her. And *then* something happens to *Jim*... It's delegation turtles all the way down. How realistic are some of these? There are legal constraints on continuing to add further and further delegates. But at some level, US laws such as RUFADAA (which is more widely adopted than ever – later Tim provided adoption status in email <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/vDl5Q3czO…>) could provide a basis for at least the first layer – or maybe as far as two layers? – of delegation to be handled at a "policy layer expressed by technical means" with UMA's help. Is "policy layer" the right name? The overall generic name has been "business-legal" but that may be too awkward. Let's continue this topic. Would it be possible to define the policies themselves to make them interoperable? To be discussed. Questions we still need to discuss as outlined in the slides: For the care scenarios, do we need a primary carer/super admin type of role or are all entities in RRA equal? 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. *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 1

Reminder: UMA business-legal telecon tomorrow
by Eve Maler 05 Aug '19

05 Aug '19

We meet 8am PT on Tuesday at https://global.gotomeeting.com/join/857787301 -- see our calendar here <https://kantarainitiative.org/confluence/display/uma/Calendar>. Previous notes are here <https://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+not…>. Our spreadsheet is here <https://docs.google.com/spreadsheets/d/1QT5LR_ibpwYwpD_XLQ1tB7OLXbdaT6Oi9aj…>. Trying to access this link will send me a notification to share it with you with your preferred ID, if I haven't already given you access. Agenda items: - Continuing to answer the state machine questions collected during the ad hoc meeting two weeks ago (see last week's notes and the linked slides) - Seeing if we can apply the state machine model to the requesting side in similar fashion to the RRA/RO side *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

UMA2 I-Ds: for discussion and decision
by Eve Maler 05 Aug '19

05 Aug '19

Our UMA2 Internet-Drafts are expiring on August 17th: https://tools.ietf.org/html/draft-maler-oauth-umagrant https://tools.ietf.org/html/draft-maler-oauth-umafedauthz These drafts expire on August 17th, and while we decided not to pursue their direct adoption in the OAuth WG as work items, we still haven't decided on other next steps. In our 2019-06-20 telecon <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-06-20> we did pretty much narrow down the options to two: 1. Let the specs expire and do nothing else (beyond telling the OAuth WG chairs that we rescind our previous proposal [already done]) 2. Decide to do an independent submission and go for an informational RFC instead in the Security Area We were leaning towards #2, but we're still open at the moment. *Please review those meeting notes* in preparation for our call -- and feel free to weigh in on this thread (particularly if you can't join on Thursday). *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Draft minutes of UMA telecon 2019-08-01
by Eve Maler 01 Aug '19

01 Aug '19

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-08-01 MinutesRoll call Quorum was not reached. Approve minutes - - Approve minutes of UMA telecon 2019-06-20 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-06-20> Deferred. IETF 105 recap and next steps - Especially valuable to have (potential) profile and extension authors here to discuss Here is the message to the OAuth list <https://mailarchive.ietf.org/arch/msg/oauth/t-hnVfYlVJUJF_A4vKCd9pT5c8g> with links to the two sets of meeting minutes. Video recordings are also coming out. You can read about OAuth.XYZ <https://oauth.xyz/> here, and its applicability to UMA use cases here <https://oauth.xyz/examples/>. The official IETF I-D is here <https://tools.ietf.org/html/draft-richer-transactional-authz-02>. Questions about XYZ: Is it meant to be profilable to help it fit into a larger ecosystem? UMA is meant for a multi-party environment. We'd want to be sure that the rechartering effort accommodates actual UMA use cases. Aaron P has proposed how to "add identity to XYZ <https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz>" (iow, layering OIDC functionality into it), but discussion with Justin so far shows that there's an intent to incorporate UMA use cases directly; maybe OIDC use cases would become part of it as well. Justin says all of the UMA functionality is intended to be baked into the core protocol. Aaron P is also considering doing a profile for IndieAuth. XYZ shouldn't have to be profilable in the same way as OAuth2 because it doesn't have the same model of grant types – there's not nearly as much need because there aren't as many options. Swimlanes are coming to show how it would be used for different purposes. Some of the technical design basis is sourced from current UMA: transactional handles are like permission tickets, the user interaction approach/endpoint works the same, and the ticket given in user interactions is like a PCT. XYZ has a C-to-AS first flow as today's OAuth does, but there is interest among some in the OAuth group already in a C-to-RS first flow like UMA has, and Eve and Justin have discussed how to achieve this in a robust fashion. You would need to have the RS make a call to the transaction endpoint and get a resource handle back to hand to the client. Sometime in August the rechartering discussion will be picked up. It would help to have specific UMA use cases and flows documented, within the bounds of XYZ. "This is a use case that core OAuth2 can't handle. UMA2 can (or even UMA2 can't), but XYZ would bring these benefits because of these reasons: x, y, z..." Justin mentions the single-user case (Alice-to-Alice sharing). If the client can be shown to avoid jumping through a lot of hoops, that's a win. Things UMA2 doesn't currently handle: Strong assurance to Bob that Alice is who she says she is (the "CIBA" case with UMA sharing benefits). Also fully disconnected sharing. The set of use cases would ideally be provided in the next couple of weeks (self-imposed deadline). Justin needs four sections: a) the use case itself (be short and to the point), b) why vanilla OAuth has limitations around it, c) what you can achieve with extensions to OAuth (including UMA), and d) an in-depth description of how you'd solve the use case with XYZ, ideally with swimlanes. Roman will be picking things up again in late August, and concrete write-ups will help keep the momentum up. Justin's Identiverse talk <https://www.youtube.com/watch?v=U9i7YaN8v9c&feature=youtu.be&list=PLpKq7xRi…> will help people understand his spec in greater detail. Eve will ask key people to help generate these use case write-ups. OAuth.net/2 <http://oauth.net/2> needs UMA revision - Anyone willing to do a quick pull request on this page to point to the final UMA2 recommendation or our wiki home page? Justin has done this, thanks! - Speaking of which, our FAQ <http://tinyurl.com/umafaq> is extremely old and out of date... Business-legal framework update Please read the meeting notes from this week <https://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+not…>, sent in email – we now have an emerging state machine, thanks to the work of Cigdem, Lisa, and Nancy! Nominations for chair and vice-chair Nominations are open for these positions. Please send your nominations (self or other) to Eve. She is willing to stand for chair again and Maciej is willing to stand for vice-chair again. We'll keep these nominations open for a while more, even though we're a bit late with the elections. You can see the leadership team list here <https://kantarainitiative.org/confluence/display/uma/Leadership+Team>. The right spec link The right spec link is UMA Grant Recommendation <https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html>. In addition to their having removed all the wrong robots.txt entries, we also need to ask KI staff to link more frequently to the correct spec! This will help search results point to the right file, which nobody is able to find. Attendees As of 16 Jul 2019, quorum is 5 of 9. (Domenico, Peter, Sal, Thomas, Andi, Maciej, Eve, Mike, Cigdem) 1. Domenico 2. Sal 3. Maciej 4. Eve Non-voting participants: - Scott - Alec - Cigdem - Nancy - Tim - Colin - Vlad - Lisa - Justin - Adrian Regrets: - Peter - Mike - Maciej *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2019-08-01
by Eve Maler 01 Aug '19

01 Aug '19

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-08-01 Date and Time - *Thursdays 6am PT* - 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 2019-06-20 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-06-20> - IETF 105 recap and next steps - OAuth.net/2 <https://oauth.net/2/> needs UMA revision - Business-legal framework update - Nominations for chair and vice-chair - AOB *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

3 2