- WG-UMA - mailman.kantarainitiative.org

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 11 Dec '19

11 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

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

05 Dec '19

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-12-05 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> Deferred. Reminder: Identiverse CfP is open till Jan 10 Keep those cards and letters coming! Discuss recent next-gen authz news Adrian relates news from a symposium at which Thomas was presenting, where bots and swarms have roles to play, blockchain enables consensus on swarm activities, and there is a payment model for bots. Shades of (George's?) Device-Managed Access model and Ray Bradbury's Night Call, Collect <https://spilledthejillybeans.blogspot.com/2012/01/bradbury-friday-night-cal…>! And what if an intelligent machine ultimately infringes on an existing patent? The second decentralized identity meeting is tomorrow at 1pm ET. The minutes from the first meeting are here <https://docs.google.com/document/d/1wbaBx8p9Xe35IT4Lk4MnXAqzZ_ja68-9w7N8zkr…>. Planning for all this is happening on the DIF Slack workspace and also the W3C groups (there are at least three relevant ones; the most relevant is the Credentials Community Group <https://w3c-ccg.github.io/>). WGs are slightly more "closed". The calendar invitation is here <https://calendar.google.com/calendar/r/eventedit/copy/MjJmdHNucjQwYjJvYzlyb…>. Adrian's take: There are some people convinced and some not so convinced about Linked Data as a way to move forward. People representing (many) startups don't want to wait and want to press forward in Hyperledger Aries and(/or?) DIF. These two organizations seem friendly towards each other and MSFT is taking two steps back. Though Kantara has been mentioned and it hasn't been dismissed, it's unlikely. Adrian believes it's possible to accommodate a two-org track that continues with the W3C effort as well, e.g. with DIDcomm. Justin sees a challenge with the hard work of blocking and tackling of standards integration now needed. Adrian and others brought up UMA as a relevant technology/standard in the first meeting. A question of "IP" came up; apparently this has to do with the desire to build the decentralized web independent of TLS and basic lack of familiarity with Kantara and the existing standards world. Justin attended the side meetings on OAuth 2.1 (which weren't available for meetecho remote participation). If you have a 2.1 client talking to a 2.0 server with the right extensions, then everything should work fine; it adheres to semantic versioning (even though the WG hasn't made a formal commitment to semantic versioning overall). 2.1 is just a collection *and branding* of certain features like mandating auth code+PKCE etc. But it doesn't include extensions like RAR. He believes PAR is sufficiently baked to use, but RAR needs a lot more work. 2.1 could talk about dynamic client registration (DCR) but point off to sources. How do you deal with the need to constantly update security advice? Eventually you do issue a BCP for 2.1 if it's necessary. RAR/PAR is what has a few elements of UMA-relevant features. All along we've had a goal of "sedimenting" UMA features into OAuth itself, and been happy when this has happen, e.g., DCR. George sees the value of RAR as more than OAuth2. It's a JSON structure for dealing with internal microservice authorization issues. Eve had picked up on the fact that RAR enables resource-specific scopes in UMA-like fashion without requiring pre-registration of resources (as UMA does) in a specific resource owner context. UMA's protection API has the AS issue a resource ID that basically carries resource owner personal data because of that context. She believes Identos had created an UMA extension specifically to undo this bit of implication so as to privacy-enhance AS interactions – is that so? Adrian asks about a RAR/PAR relationship to ZCAP <https://w3c-ccg.github.io/zcap-ld/> (the Linked Data spec at W3C); Justin believes they're not related. Maybe we can drill down into the topic of DCRs and different types of wide ecosystem a bit more. 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. Domenico 2. Andi 3. Eve 4. Mike Non-voting participants: - Adrian - George - Scott - Bjorn - Justin Regrets: - Maciej *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

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

04 Dec '19

(In keeping with recent tradition, this agenda is a bit informal.) Let’s continue the discussion of “XYZ/RAR/PAR” by catching up on IETF 106 Singapore goings-on, and also the decentralized identity meeting(s?). Eve Maler (sent from my iPad) | cell +1 425 345 6756

1 0

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

03 Dec '19

Great session, thanks everyone! https://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+not… 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" [image: (smile)]. - 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. *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Paper "Beyond Consent: A Right-to-Use License for Mutual Agency"
by Lisa LeVasseur 03 Dec '19

03 Dec '19

Hi folks, Here's the latest version of the paper Eve mentioned today. Lisa

1 0

Reminder: UMA business-legal telecon 2019-12-03
by Eve Maler 02 Dec '19

02 Dec '19

(December already??) We meet 8am PT on Tuesdays at https://global.gotomeeting.com/join/857787301 -- see our calendar here. Please see our notes page for previous notes and handy links. We'll continue to work through our GDoc. Eve Maler (sent from my iPad) | cell +1 425 345 6756

1 0

Just posted a new implementation on our Implementations page!
by Eve Maler 23 Nov '19

23 Nov '19

Nancy sent me news of an UMA implementation her company has done -- you can read about it here: https://kantarainitiative.org/confluence/display/uma/UMA+Implementations#UM… @UMAWG is spreading the news and it's also on our wiki home page. Will you help out? Thanks in advance! https://twitter.com/UMAWG/status/1198015446475296768 (BTW, happy Thanksgiving to everyone who is celebrating it next week.) *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 1