- WG-UMA - mailman.kantarainitiative.org

Notes from 2020-01-07 UMA business-legal framework telecon
by Eve Maler 08 Jan '20

08 Jan '20

(I've had to cancel a couple of upcoming calls due to conflicts. Please see the calendar if in doubt.) https://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+not… 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 <https://kantarainitiative.org/confluence/display/uma/Privacy+by+Design+Impl…> 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 <https://en.wikipedia.org/wiki/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 <https://protocol.jlinc.org/>. *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

SURVEY: Glossary Project
by Adrian Gropper 21 Dec '19

21 Dec '19

This survey is intended to help the Glossary Group identify the diversity of uses of key terms in the decentralized identity ecosystem. These terms and questions came out of an initial survey of the broader DIF community. The group will explore more terms in the future. https://docs.google.com/forms/d/e/1FAIpQLScN03kK-pWHzRX12RplthFKaRnJl3syAEk… This invite is being cross-posted to other lists. Feel free to share with folks that might be specifically interested or email me with suggested others as we want to avoid spamming the same lists. Thanks, -- Adrian

4 13

Draft minutes for UMA telecon 2019-12-17
by Eve Maler 19 Dec '19

19 Dec '19

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-12-19 MinutesRoll call Quorum was not 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> Deferred. Reminder: Identiverse CfP is open till Jan 10 Keep those cards and letters <https://identiverse.com/CFP> coming! Explore idea of UMA extension that reuses some portion of RAR/PAR Some handy links about RAR/PAR: - Roundup <https://oauth.net/events/2019-11-ietf106/> by Aaron Parecki of IETF 106 artifacts, including spec links - Brief discussion <https://groups.google.com/forum/#!msg/kantara-initiative-uma-wg/56_fskNknrg…> on the UMA WG list of RAR/PAR interest - Medium article <https://medium.com/oauth-2/rich-oauth-2-0-authorization-requests-87870e263e…> from Torsten L on the specs from Sep PAR <https://tools.ietf.org/html/draft-lodderstedt-oauth-par-01> is currently at rev 01. There has been a call to accept it as a work item in the OAuth group, and it's looking very likely. Justin noted that he has implemented it. The adoption call was a compound one for both PAR and RAR, but now things have gotten more separated out. Torsten has also proposed through FAPI issue #275 <https://bitbucket.org/openid/fapi/issues/275/adopt-par-rar-as-recommended-w…> to use PAR and RAR in FAPI. So our attempt at experimentation here is timely. Would this be so invasive that we'd have to reinvent a permission ticket structure to replace the resource ID and hunt around for something in XYZ to replace it (the transaction handle), and then end up accidentally discovering "how XYZ really does UMA"? We have a RqP doing the authorization request, not "the user" (the RO). The purpose of PAR is to enable the client to push fine-grained details of its need for access on the back channel so it doesn't need to send them on the front channel, but we're already doing that anyway. UMA already allows for multiple resources per RS to be requested, and differentiated scopes per resource. The introduction to RAR (which is at rev 03 <https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-03> right now says (emphasis added): "The OAuth 2.0 authorization framework [RFC6749] defines the parameter "scope" that allows OAuth clients to specify the requested scope, i.e., the permission, of an access token. This mechanism is sufficient to implement static scenarios and coarse-grained authorization requests, such as "give me read access to the resource owner's profile" but it is not sufficient to specify fine-grained authorization requirements, such as *"please let me make a payment with the amount of 45 Euros"* or *"please give me read access to folder A and write access to file X"*." Let's give names to the two use case aspects that RAR's data structure solves. The first could be called *transaction grain* and the second could be called *resource grain*. UMA already solves for resource grain. We have defined how Alice can set conditions of access for an RqP. What about Bob setting the conditions for his own access? Adrian has a diagram <https://docs.google.com/document/d/1FBfs4shirUAtqD_d_t6F6oi2NZ0Y7400MDoYSm1…> that is useful for thinking about this question. "Credentials presentation" maps to Bob having to present claims to Alice's AS (each circle is some service/software representing the entity shown) so that he can prove he's suitable against her policy. "Resource scope request" is his client's request for scoped access to some specific resource. "Data use assertion" is the new thing here: It's what he tells Alice about *how/why* he intends to use the access he was granted. The RS ("Store" here, meaning data store) has to need to know this information. If the "store" is outsourcing authorization to an AS, then indeed the AS could handle all of that. Consent receipt work with an UMA flavor seems to be coming from Mark L, so stay tuned for that. Nancy will hopefully share use case for transaction grain that we can consider next. And it's "on us" to work through some XYZ flows that meet UMA use cases (or show why it doesn't meet UMA use cases yet). Happy holidays to everyone and see you in 2020! Attendees As of 16 Jul 2019, quorum <https://kantarainitiative.org/confluence/display/uma/Participant+Roster> is 5 of 9. (Domenico, Peter, Sal, Thomas, Andi, Maciej, Eve, Mike, Cigdem) 1. Sal 2. Thomas 3. Eve 4. Cigdem Non-voting participants: - Adrian - George - Nancy - Scott - Colin *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2019-12-17
by Eve Maler 18 Dec '19

18 Dec '19

Truly last call of the year... https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-12-19 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 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> - Explore idea of UMA extension that reuses some portion of RAR/PAR - AOB *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Reminder: UMA business-legal framework telecon tomorrow is shifted a half-hour early
by Eve Maler 17 Dec '19

17 Dec '19

This is due to a conflict on my end. (Also, I'll need to drop a tad early. Hate to do it, but duty calls.) This is our last call of the year. We've been making nice progress, so let's continue doing so! *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 2

Notes from 2019-12-17 UMA business-legal framework telecon
by Eve Maler 17 Dec '19

17 Dec '19

[This was our last biz-legal meeting of the year. We do still have one more "regular" WG call this Thursday.] https://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+not… 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 <https://onedrive.live.com/view.aspx?resid=B50E88B19F3E012!68813&ithint=file…>" that is inspiring us to add a graphical version of the "typical use case" to the doc. *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Draft minutes of UMA telecon 2019-12-12
by Eve Maler 12 Dec '19

12 Dec '19

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-12-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> Deferred. Reminder: Identiverse CfP is open till Jan 10 Keep those cards and letters <https://identiverse.com/CFP> coming! Discuss RAR/PAR and UMA implications Some handy links about RAR/PAR: - Roundup <https://oauth.net/events/2019-11-ietf106/> by Aaron Parecki of IETF 106 artifacts, including spec links - Brief discussion <https://groups.google.com/forum/#!msg/kantara-initiative-uma-wg/56_fskNknrg…> on the UMA WG list of RAR/PAR interest - Medium article <https://medium.com/oauth-2/rich-oauth-2-0-authorization-requests-87870e263e…> from Torsten L on the specs from Sep - (Hyperledger Aries concepts <https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0004-agents/…> about cross-"agent" communication (everything is an "agent" in their conception)) When Eve says "RAR/PAR", she really means the data structure that seems to underlie both of them. RAR is heavier, and in talking to Justin she has learned he believes it's not really baked yet, while PAR is much lighter weight and is much more ready for prime time. RAR is sort of the "pull" version and PAR is the "push" version from the client side. In the brief discussion thread, Eve said: *"Here was my observation. RAR manages to convey, in a just-in-time/one-time way (vs. registering ahead of time in an RO context), a lot of fine-grained authorization details. Some resemble what we do or have done in the past.* *For example, it has individual resource “locations” à la our individual resources per RS that get an RO-specific resource ID. (We dropped our location uri parameter after V1.)* *Its individual resources are able to have scopes associated differentially, the way we’ve been able to do for a long time.* *Its main purpose is the one-time fine-grainedness (which we don’t do, but I’ve seen proposals for from time to time), but some of these other ideas seem sensible since, after all, we do something like them. Our version is more complicated. Is this a case of potential broader adoption of design ideas we could eventually “adopt back”, or of feedback we should provide on why the design needs more thought, or a mix, or...?"* In OAuth originally, the concept of scopes being simple strings was powerful but very coarse-grained, and too many entitlement types have gotten squished into scopes over time, which has resulted in overloading. UMA invented the concept of having different scopes per resource; because of its asynchronicity goals (Alice being able to set authorization policy at the AS separately from when Bob and his client seek access), we made resource registration happen prior to policy setting. It could be "dynamic" or "static" but must happen before that point. The consequence is that resource reg is in an RO context: the resource ID carries that context. The (common) RAR/PAR data structure goes beyond the detail of our resource reg/scope reg, but one thing that data structure and the UMA protection API's resource description <https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-federated-authz-2.0…> have in common is that resources (resource locations in RAR/PAR) can have unique scopes. Maciej notes that in some past work, he found utility in a model similar to RAR/PAR, and Eve knows of several cases of this as well. In fact, the cases she's aware of were sort of "UMA-enabled". So it seems like the time has come for some standardization of this. Eve's recollection of the work to profile/extend UMA at Identos to privacy-enhance the AS reminds her a little bit of this overlap. They had a customer that apparently wanted to eliminate the particular trust vulnerability remarked on in the FedAuthz Privacy Considerations <https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-federated-authz-2.0…> section: *"The authorization server comes to be in possession of resource details that may reveal information about the resource owner, which the authorization server's trust relationship with the resource server is assumed to accommodate. The more information about a resource that is registered, the more risk of privacy compromise there is through a less-trusted authorization server."* Of course, there could also be authentication data as well, but if the AS is an RP to some other IdP for that, then it doesn't even hold that. *AI:* Eve: Reach out to Alec at Identos and see if there are any synergies with his "enhanced UMA" and the RAR/PAR approach to per-resource scopes (or anything else in there). *AI:* Adrian (if he wishes): Put some questions/comments about capabilities models and comparisons on the list for further discussion there. Eve asks: Is it worth exploring an extension to UMA (backwards incompatible) that reuses some portion of RAR/PAR so as to consider "sedimenting" more features down into OAuth? Cigdem thinks putting in place PAR could be fairly easy, but RAR needs to mature a lot and could be more involved. (Note that authorization_details is supposed to be able to be used anywhere scope is. UMA has resource_scopes for a reason, so we'd have to deliberately make the equivalence, if it indeed can be made.) Let's continue this discussion in our final meeting of the year. Separately, Adrian asks: Is it worth the agent/wallet-y sort of approach we saw from Identos if it is more privacy-enhancing? Thomas points out that ecosystem pressures are still in play for the software used for wallets. We discussed an Amazon client app example and an example of a single-user "personal AS" service run in an environment of the RO's choice. It seems that both may only marginally improve on the "typical" situation of a web user choosing a large, powerful multi-user SaaS service to give them AS (or any other) services in terms of trust, vulnerability, level of fiduciary responsibility, etc. Attendees As of 16 Jul 2019, quorum <https://kantarainitiative.org/confluence/display/uma/Participant+Roster> is 5 of 9. (Domenico, Peter, Sal, Thomas, Andi, Maciej, Eve, Mike, Cigdem) 1. Sal 2. Thomas 3. Maciej 4. Eve 5. Mike 6. Cigdem Non-voting participants: - Scott - Adrian - Nancy *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2019-12-12
by Eve Maler 12 Dec '19

12 Dec '19

Tomorrow let’s (finally) focus down on RAR/PAR and their goals, synergies with, and lessons for resource reg. Eve (sent from my iPhone, possibly with Siri's "help": +1-425-345-6756)

1 0

Notes from 2019-12-10 business-legal framework telecon
by Eve Maler 11 Dec '19

11 Dec '19

https://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+not… 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 <https://docs.google.com/presentation/d/1I12agEsfaJK3LEiJyROrJV3PCEmhlCzCxYS…>) – 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 <https://docs.google.com/presentation/d/1I12agEsfaJK3LEiJyROrJV3PCEmhlCzCxYS…> ) - 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 <https://docs.google.com/presentation/d/1I12agEsfaJK3LEiJyROrJV3PCEmhlCzCxYS…> ) AI: Eve/Domenico: Eve to ask Domenico to create two table-oriented "state" diagrams (slides 3 and 4 here <https://docs.google.com/presentation/d/1uigCMQI_TKuFyOstQTngYuZaqs36wwbE3BB…> ): - One without arrows - One to reflect the state changes with the arrows *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 1

Reminder: UMA business-legal framework telecon 2019-12-10
by Eve Maler 09 Dec '19

09 Dec '19

We meet *8am PT* on Tuesdays at https://global.gotomeeting.com/join/857787301 -- see our calendar here <https://kantarainitiative.org/confluence/display/uma/Calendar>. Please see our notes page <https://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+not…> for previous notes and handy links. We'll continue to work through our GDoc. Lisa and I have continued to make some edits. I think we're at the point of being able to introduce States other than #1 in the next section. :-) *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0