- WG-UMA - mailman.kantarainitiative.org

Draft minutes of UMA telecon 2020-04-23
by Eve Maler 23 Apr '20

23 Apr '20

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-04-23 MinutesRoll call Quorum was reached. Approve minutes Deferred. Meet next week? Yes, let's meet next week. IIW is creating session times across the globe so people in different locations can join. IDENTOS extensions Alec's questions for the "resource definitions profile" are: What are the next steps? He hasn't prepared anything today for the "wallet profile" (they consider it as potentially an SSI wallet, doesn't have to be, but it's an OAuth client type that can evolve). The first step in determining fully if/how we want to take up the first profile is: What are the use cases we want to solve? The increasing "horizontalization" of use cases, where vertical sector use cases mix together (as in payments and health care), might encourage us to take up a profile in this area so that it can help open APIs in different sectors work. Eve showed a map of global open banking (lowercase) efforts. Alec noted that some people refer to "client-directed banking" to avoid talking about any specific jurisdiction's effort. *AI:* Alec: Propose different use cases he has seen, including in open banking. How important is it to include delegation use cases (requiring UMA) in open banking/client-directed banking from the get-go? We've had these discussions, and there has been little motivation. Typically the motivation has been to solve security and very minimal consent use cases as a base layer, and that's been the focus for the last three years. Who here is involved in open banking efforts? Mike, Eve, Alec, George keeps one eye on it. *AI:* Eve: Find and share our old UMA ecosystem design patterns document. The language around consent vs. delegation/directed sharing/(something) is coming up more and more. Eve tried for a long time to connect UMA to traditional (opt-in/opt-out) consent. "Consent directives" in healthcare is the only line that can be drawn between (e.g. proactive) asynchronous sharing and "consent". It's possible to implement traditional consent flows, a la OAuth authorize/deny, with UMA, but you get more value out of the UMA version if you are (e.g.) loosely coupling the AS and RS. UMA enables licensing on the RO's terms. We haven't defined the terms. Lisa points to the licensing spec work of IEEE P7012 <https://1drv.ms/w/s!AhLg8xmL6FALhJwvLl7Rn-Aanz1NEA?e=Gitl2W>. Mark suggests we check out a great eConsent video by Meg Doer <https://sagebionetworks.org/tools_resources/ohrp-econsent-webinar/>. Thomas notes that the word “consent” needs to be qualified, just like "trust". Intro Mike worked with Michal, who prepared the demo for Identiverse 2018 that Mike showed. Michal could be available to build a test suite. Gluu is willing to host it. Here are the top-level requirements: - Test harness in an OIDC test harness style - Hosted - Produces "red light/green light" types of answers for particular test assertions - Could be considered unofficially to be testing "self-service conformance", until we decide it's official - Tests AS interop at first, then eventually RS interop, then client interop Nancy suggests doing a connectathon. Some comments on that approach: It can tend to be expensive to participate, and the challenge is that the API chosen is specific to the industry. Colin has some ideas for building funding ("up" or "down"). Mike believes the test harness shouldn't be as bad as OIDC since there are fewer conformance profiles and options in UMA. Eve is a bit concerned about the fact that UMA sort of incorporates OAuth in a sense, but maybe we can carve out and "not do" pure OAuth testing, or alternatively entice others into covering that part. *AI:* Colin, Alec, Mike, and Eve to meet some time prior to next week's UMA WG call to do UMA interop wrangling. Attendees As of 17 Feb 2020, quorum is 5 of 8. (Domenico, Peter, Sal, Thomas, Andi, Maciej, Eve, Mike) 1. Domenico 2. Sal 3. Thomas 4. Maciej 5. Eve 6. Mike Non-voting participants: - Anik - Adrian - Scott - George - Lisa - Alec - Mark - Tim - Colin *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2020-04-23 (moved from Apr 16)
by Eve Maler 23 Apr '20

23 Apr '20

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-04-23 Date and Time - *Alternate Thursdays 6:30am PT (this meeting was moved from Apr 16)* - Screenshare and dial-in: https://global.gotomeeting.com/join/857787301 - See UMA calendar for additional details: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Should we meet next week? It's virtual IIW - IDENTOS extensions - Interop *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 1

Need to cancel tomorrow's call; may move it to next Thursday
by Eve Maler 15 Apr '20

15 Apr '20

Apologies for the late notice, but I have some conflicts that have cropped up with tomorrow's WG call. In order to preserve our ability to meet as best as possible, does anyone have a big problem if I schedule us for next Thursday at the "usual time"? *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Draft minutes of UMA telecon 2020-04-02 (ad hoc)
by Eve Maler 02 Apr '20

02 Apr '20

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-04-02 MinutesWhich week to meet George points out that the "OpenID A/B" (OpenID Connect) meeting overlaps the latter half of this meeting if we meet last/next week vs. this week/2 weeks from now etc. No one attending today has a problem. Eve will investigate with others and voting participants who are not currently present and reschedule if no problem. (*UPDATE:* Sufficient positive responses established, so Eve will switch weeks in the calendar. We will start meeting Apr 16, Apr 30, etc. instead of continuing with Apr 9, Apr 23, etc.) Online notarization Tim raises the topic of the current worldwide situation and the fact that online notarization has suddenly become more important. Is this similar to remote proofing? These technologies have certainly existed for quite some time, and have been integrated to IAM stacks. But it got more notice in Okta's keynote this week, which mentioned use cases like employee onboarding. IT budgets seem overall negatively impacted in the current environment, though this is not evenly spread out. UMA and delegation use cases generally depend on identity solutions being in place, so that makes them relatively "sophisticated". On the other hand, telehealth and health data sharing are under more pressure now. IDENTOS extensions Alec provided a sequence diagram and we worked through it. To download, see the attachments <https://kantarainitiative.org/confluence/pages/viewpageattachments.action?p…> to this page. The resource IDs are static. The "RS PAT" is not RO-specific. The capability ticket is static. If you want to see a patient record with an immunization, you get a capability ticket that's sort of like a permission ticket but it doesn't change. This maps to terms of use. When a RqP authorizes the client to access resources and scopes, they review the ToS. This is Alice-to-Alice sharing right now. So the effect is Alice reviewing ToS for accessing her own stuff. What is in this ToS? It's the client's ToS for usage by the RqP, whoever it is (could be Bob in future). The client uploaded this to the AS for safekeeping, effectively. So the AS presents the ToS to the RqP on the client's behalf. Thus, instead of the possibility of the RqP having an independent relationship possible with that client outside of UMA and that AS, the RqP is assumed to use the same AS as the RO does, so it's a narrow ecosystem assumption. (See slide 36 in the UMA Legal role definitions <https://docs.google.com/presentation/d/1I12agEsfaJK3LEiJyROrJV3PCEmhlCzCxYS…> for the "RqP-CO-ASO relationship train tracks" for how it could be built up in the widest possible ecosystem.) Security-wise, is it okay for the capability ticket to be static? It's like requesting a scope, so it's okay for it to be static. So yes, it's safe. George describes the critical characteristics: If it's just an identifier, it's okay to be static. If it's a "binding agent" across multiple flows, then it needs to be rotate. Is the capability ticket similar at all to OAuth resource indicators (now RFC 8707 <https://www.rfc-editor.org/rfc/rfc8707.html>)? It's more general, but the analogy does apply. The client would use the resource definition in the URI instead of the resource server. What happens if the API gets versioned? Is there a CRUD API or something? The capability API has something like the resource registration API. IDENTOS has implemented a dynamic version along with their static version, but they're not currently using it. The *first flow* in the diagram is "standard UMA", RS first. The RS can still request a permission ticket, only using static resource IDs. The last leg is always a token endpoint call with either form of claims collection. The *second flow* is the static capability ticket flow. The client goes to the AS first and then goes straight to interactive claims gathering. The RqP (currently the same person as the RO) is then at the AS after the redirect and can authenticate etc. The *third flow* is a hybrid where the client, *not* using the static capability ticket, uses the permission endpoint as if it was the RS. This is perhaps a bit like OAuth Pushed Authorization Requests (PAR <https://tools.ietf.org/html/draft-ietf-oauth-par>). Are there any security implications to this? The client is similar to an RS in that they have registered what they can do. Since a PAT is now no longer RO-specific, the client can go ahead and use their client credentials as a "PAT-equivalent". The AS can distinguish them from an RS because they have registered as a client. After the three flow options, saying (say) that they're looking for a patient record, now the RS still has to be told which patient's resource to give out. So in introspection, the AS provides subject information explicitly in its response, along with the granted resource IDs and scopes. Or George notes that an encrypted access token could contain that information. The RPT is still used. (Last week Alec noted that it was in this step, providing the subject, that there is some potential overlap with the other extension they have defined. See his email to the list <https://kantarainitiative.org/pipermail/wg-uma/2020-March/005943.html> and the description of "step 8" for more detail.) Thank you to Alec and IDENTOS for contributing this for the WG's consideration! The "narrow ecosystem" this use case serves does seem pretty common (shared AS between the RO and RqP, oftentimes the RO == the RqP, the design patterns of the resource need interop due to open APIs or other reasons). Other questions and comments we didn't have a chance to address yet, maybe in future: - George: Could you use Dynamic Client Registration of the mobile app to help with this? That would make the client_id specific to each mobile app instance - Sal: trusted platform environment might also come into play We seem to have interest in considering work on this as a WG. More to come. Interop Deferred, but some people are working on this as a separate thread. Attendees As of 17 Feb 2020, quorum is 5 of 8. (Domenico, Peter, Sal, Thomas, Andi, Maciej, Eve, Mike) 1. Domenico 2. Sal 3. Eve 4. Mike Non-voting participants: - Cigdem - Scott - Alec - Tim - George - Colin *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2020-04-02 (ad hoc)
by Eve Maler 01 Apr '20

01 Apr '20

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-04-02 Date and Time - *Alternate Thursdays 6:30am PT (this ad hoc meeting was added in the series specially)* - Screenshare and dial-in: https://global.gotomeeting.com/join/857787301 - See UMA calendar for additional details: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - IDENTOS extensions - Interop *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Draft minutes of UMA telecon 2020-03-26
by Eve Maler 26 Mar '20

26 Mar '20

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-03-26 MinutesInterim meeting We will hold an interim meeting on *Apr 2* to discuss the proposed extension(s) in more depth. Eve will put it on the calendar. Roll call Quorum was reached. Approve minutes - - Approve minutes of UMA telecon 2020-03-12 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-03-12> Minutes APPROVED by acclamation. AdvCIS liaison report Report from Mark/Tim on Notice & Consent project <https://kantarainitiative.org/confluence/pages/viewpage.action?pageId=12546…> and next steps. Sal is the secretary of the group. The idea is to take the Consent Receipt work (the early technical working group), and move it forward. There is representation from COEL, DIACC, now UMA, other Kantara work groups, MyData operator groups, and more. There has been outreach to Nat Sakimura regarding relevant ISO specs. The idea is to synchronize it to address interoperability so that consent receipts can be used in the same way. It's a project group of the new ISI Work Group. The old CIS Work Group has been archived. People can see the project and group structure in the table of contents off to the left of the linked project page. This first meeting mostly consisted of introductions and basics. The idea is to cycle between each spec/use case, and examine spec sections and ensure they sync up. The goal is to publish in the July timeframe. There is some history provided about the initial Consent Receipt spec, since GDPR was published, on the main Notice & Consent <https://kantarainitiative.org/confluence/pages/viewpage.action?pageId=12546…> page. A tricky part is the IPR, since the work straddles work groups. Eve points to the GA4GH Passports <https://www.ga4gh.org/news/ga4gh-passports-and-the-authorization-and-authen…> work as being relevant; perhaps Carlos Garcia, as an UMAnitarian working on this project, could be a liaison from this perspective. Our work on the "devices and artifacts" around legal relationships could drive how we attach such "machine-readable licenses" as information-sharing agreements. The IEEE research that Lisa and Eve did (webinar version here <https://www.me2balliance.org/webinars.html>, paper version here <https://ieeexplore.ieee.org/document/9031549>) proposed why consent per se – and consent to contract, as in terms of service agreements – is problematic (disempowering) legally and experientially. That's where right-to-use licensing comes in, and these information sharing agreement efforts could solve the interop half of the problem. IDENTOS Resource Definitions/AS-first flows See Alec's email <https://kantarainitiative.org/pipermail/wg-uma/2020-March/005943.html> and our discussion in the last meeting <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-03-12> . How it works: This all works because RS's, and clients, and AS's, have figured out ahead of time what RS's and clients are capable of doing and handling, respectively. There is a trust framework that applies. Think of an immunization record. It can live in a whole bunch of places. The numbers below are from Alec's email. No. 1. FHIR isn't enough in a lot of ways. It's necessary to tag the scopes to say what the different clients can have access to, for example. And the resources need to be tagged to describe what they mean. What didn't exist that needed to be created? If there are three different FHIR repositories and you have to stand up a FHIR app, there's a lot of data you have to set up. "In Ontario, we're using these codes, and we're using SNOMED..." etc. It's metadata that maps FHIR to the local profiles that are specific to that community. Nancy notes that there are a lot of profiles of FHIR. She's involved in a lot of work to harmonize FHIR profiles. For example, there are profiles within the Claims area. It sounds like Alec has done similar work in Canada. Yes: Four different provinces have harmonized their profiles. Why does the AS define these general "resource definitions" vs. RS's? Because the AS is capable of handling these multiple profiles and so it needs to be the one to harmonize across them. Nancy asks: Most data sources don't contain adequate sensitivity data tagging, so: Does this include sensitivity support? The FHIR server along can't support this, so having a gateway in front of it that understands specific scopes and can edit the data would help. There is sort of a "well-known" description of metadata. It could be standardized in some fashion. No. 2a. Any client that can handle whatever subset of these resource definitions and their scopes can be registered for it statically. In their usage of this mechanism it's static, but it doesn't preclude dynamic client registration. No. 2b. When clients are registered, it's at this time that they receive "capability tickets". This could be static or dynamic. But since the clients can only do very specific things, the tickets are specific too. No. 3. How would, say, a new FHIR version ripple through a deployment like this? RS's could be versioned and clients that only understand certain versions could interface only with the versions they understand. How interdependent is Resource Definitions extension with the other extension? They are relatively separable. See the flow provided; step 8 is where Alec addresses this a bit. He'll try and provide a sequence diagram. Eve will set up an *interim call on Apr 2* to continue diving into the details of this. Interop Deferred. Attendees As of 17 Feb 2020, quorum is 5 of 8. (Domenico, Peter, Sal, Thomas, Andi, Maciej, Eve, Mike) 1. Domenico 2. Sal 3. Andi 4. Maciej 5. Eve 6. Mike Non-voting participants: - Tim - Anik - Alec - Nancy *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2020-03-26
by Eve Maler 25 Mar '20

25 Mar '20

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-03-26 Date and Time - *Thursdays 6:30am PT (last "summertime skew" meeting, earlier for UK and CET)* - 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 2020-03-12 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-03-12> - AdvCIS liaison report - IDENTOS Resource Definitions/AS-first flows - Interop - AOB *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Apologies for the abrupt end to the WG call / expect new dial-in details soon
by Eve Maler 14 Mar '20

14 Mar '20

Colin researched the matter and discovered that indeed our call abutted the ISI WG call time using the same GoToMeeting line, and we got bumped. (This happened on the previous call too, as some may recall.) To fix this, we’ll switch to the Kantara “GTM2” line in future. As soon as I’ve got a proper moment on Monday, I’ll fix the calendar entry, wiki page, etc. Those who keep manual calendar entries should prepare to “make a note of it”. And in any case, we shouldn’t be letting our calls drag too long after the bottom of the hour... Eve Maler (sent from my iPad) | cell +1 425 345 6756

1 0

Draft minutes of UMA telecon 2020-03-12
by Eve Maler 12 Mar '20

12 Mar '20

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-03-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> , 2019-12-12 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-12-12> , 2019-12-19 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-12-19> , 2020-02-13 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-02-13> MOTION: 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> , 2019-12-19 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-12-19> , 2020-02-13 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-02-13>. APPROVED. Extensions Alec and Anik: About a year ago, Alec shared how they were using UMA, and particularly modifying it. They have extended and profiled it for their use cases. They are going to share those with the group to get feedback. The first is for "RS Interoperability". This is to enable RS's to have a standard API. If there are, say, five FHIR servers, there can be discovery. Alec will send an email to the WG later today. This has been getting a lot of traction in healthcare in Canada. The second is about splitting the AS. The concept of a "cascading AS" has come up previously, and also a "personal AS" and potentially with a wallet component. This is related to that. The AS in this case doesn't deal with any personal information; it is delegated to a personal authorization server component. This goes into the world of SSI and wallets. The user can bring their own wallet that they can have a stronger relationship with than a "community" AS. This can solve some compliance challenges. This might just be one use case of UMA, or could potentially have broader implications. Alec will share at least the first one. Currently, "compliant UMA" has the client going "RS-first": the first thing it does it to "hit a resource". What they are doing still supports that flow. But they have extended the flow to have the client ask for a permission ticket first. "I'm a client and I need this kind of a service." Does this solve for a "classic" resource protection use case where the RO can protect any (arbitrary) resource? It constrains to a set of well-known resources. This isn't solving for Alice-to-Bob sharing. CanImmunize is an example of an app that gets access to immunization records. They can avoid integrating with every single "RS" (host of immunization records), by integrating with the AS that knows about all the actual RS's. Bob's client goes to the AS and looks for an immunization record. It could be at four RS's. It's told "It's at hospital C, and it looks 'standard' for some definition." George comments: "This sounds a lot like a trust-framework mechanism that manages authorizations of clients and which RSs that client is authorized to access." Resources get statically registered. The user gets to choose what scopes get shared, in an asynchronous policy-based way. The client is registered at the community AS. After Alice (the RO) is in the picture, the RqP presents (SSI-style) credentials (that is, VCs) to Alice's personal authorization server ("PAS"). (In other words, Alice's PAS is a verifier and the RqP is a holder of VCs.) The PAS is an agent managing policy at the community AS. Which extension features are to achieve privacy enhancement and which are to achieve resource standardization? Let's see if we can tease that out when we see the extension details. Adrian notes that there is a prescription monitoring law that seems to overlap with these requirements. Interop ForgeRock has a new "Secure Sharing <https://www.forgerock.com/blog/forgerock-secure-sharing-ingredients-who-wha…>" open-source RS implementation out. Eve will add it to the Implementations page. This is in addition to Gluu's Gluu Gateway RS implementation. Nancy's FHIR-based UMA implementation has been engaged in the healthcare connectathons. FHIR V4 is what's been generally targeted now. HEART now profiles UMA2. It would be a very good time for us to test and demonstrate interop. AS interop is the first step. Nancy suggests that we need a plan to test all the components. A HEART client would be valuable. HEART is just a superset of SMART. It could be valuable to work with the FAST people and that connectathon community. Our previous interop discussions led to this landing page <https://kantarainitiative.org/confluence/display/uma/UMA+Interoperability+T…> (and a bunch of discussion and conclusions in previous notes). We've had offers previously to develop a test harness. Colin will research funds availability. Any reason *not* to choose a healthcare use case for a first interop? Financial services is the other obvious one. Scott notes that in the Secure Sharing implementation, the idea was to start with a generic / abstract reference environment to help communicate the UMA concepts and value proposition, then move into industry-specific requirements. it's always somewhat cumbersome have an example in one industry and having to explain it to another. The implementation provides sample resources and scopes for several industries to reduce the need to say "imagine if you will ...". Fastest route to publishing current UMA relationship material? Relevant docs: - Business-Legal Framework and Use Cases <https://docs.google.com/document/d/1Accua4AWQrl6N0trjdj4NFA0fyDpOn2B1orupCu…> (GDoc) - Mapping Graphics <https://docs.google.com/presentation/d/1uigCMQI_TKuFyOstQTngYuZaqs36wwbE3BB…> (GSlides) - Legal Role Definitions <https://docs.google.com/presentation/d/1I12agEsfaJK3LEiJyROrJV3PCEmhlCzCxYS…> (GSlides) - Definitions and Use Cases Spreadsheet <https://docs.google.com/spreadsheets/d/1QT5LR_ibpwYwpD_XLQ1tB7OLXbdaT6Oi9aj…> (GSheet) Deferred, but interest continues in these use cases and potential solutions. Attendees As of 17 Feb 2020, quorum is 5 of 8. (Domenico, Peter, Sal, Thomas, Andi, Maciej, Eve, Mike) 1. Domenico 2. Sal 3. Thomas 4. Eve 5. Mike Non-voting participants: - Nancy - Scott - Adrian - George - Alec - Colin - Tim - Anik – IDENTOS – guest expert – helping to bring some UMA extension thinking into our realm today *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2020-03-12 (note "summertime skew")
by Eve Maler 10 Mar '20

10 Mar '20

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-03-12 Date and Time - *Thursdays 6:30am PT (new time – and we are in "summertime skew" so it's one hour earlier for UK and CET)* - 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> , 2019-12-19 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-12-19> , 2020-02-13 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-02-13> - Extensions - Interop - Publishing the relationship material - AOB *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0