UMA telecon 2019-05-23

UMA telecon 2019-05-23

Date and Time

Agenda

Minutes

Roll call

Quorum was not reached.

Approve minutes

Deferred.

IIW and EIC updates

Eve gave HEART updates at both events, and did an UMA 101 session by request at IIW, which was well-attended. There were "cross-community" discussions at IIW. Here are the IIW 28 notes. Adrian has sent some thoughts to our list. How could you accept VCs at the claims gathering (interaction) endpoint? Adrian is involved in 3-4 other projects that are trying to figure out machine-to-machine interactions in the "agent" sense. UMA and the SSI work seem complementary. George wonders if so – conceptually perhaps, but protocol-wise, perhaps no. Matt Hailstone/Nathan George/Eve had a session at IIW discussing the "policies" and "permissions" topic. Adrian observes that UMA invented an AS and SSI invented a wallet and they're 70% like each other – but George pushes back on the characterization.

UMA's design center has enabled it to apply to "today's web" and the API economy directly. And it has already been applied to uPort. Does it make sense to document (profile) how it works with specific SSI-type technologies in the places where it has touchpoints with identity, including a resource owner's identity interactions with an RS, and with an AS, and an AS's claims collection methods for the requesting side?

Eve's conversation with a rep for HL Indy yesterday revealed some clear deltas between UMA's capabilities/deficits and those of an Indy wallet. UMA doesn't do cryptographic proofs and proof requests around the permissioning model, but it enables asynchronous sharing (proactive and access approval options), sharing with autonomic third parties using clients (requesting parties), sharing of access to arbitrary resources behind APIs (such as control of devices, inserting data in, large volatile data sets, etc.)...

A DIF identity hub is apparently a cloud agent.

EIC had a lot of AI sessions this time. It's being used to detect fraud (when you're "not you"). Context is important to detecting and reducing what the user has to consent to. This perhaps connects to the "risk-based authentication" type of topic that comes up when we've discussed the Keycloak extension for fine-grained authorization. The RS passes along claims at permission request time to the AS, after having had the client attempt access to the resource. The "claims" the RS passes along could consist of observations made about the client at that time, such as apparent IP address, etc. The AS could use those as part of its later authorization assessment, e.g, comparing them to the client that shows up later at the token endpoint. That's a good chance to use "context".

IETF 105 and OAuth.XYZ/transactional authorization discussion

IETF 105 is coming up July 20-26 in Montreal. Eve is planning to go, and is planning to do an "UMA Q&A" with the OAuth WG there. Who else is attending? No one else currently on the call. Justin has submitted an I-D for his "XYZ" proposal, called "transactional authorization". He's been coordinating with Torsten Lodderstedt on it. This I-D is influenced by a lot of UMA ideas and other ideas; for example, the "transaction handle" is basically a permission ticket.

Given that this new I-D has a lot of promise and we think there's evidence of appetite in that community to work on it (we'll know a lot more by the end of July), maybe we should change our recommendation about the UMA2 contributions to say that they should be published as-is as individual I-Ds. The upside: Stability for UMA2 with something of an IETF imprimatur. The downside: It wouldn't have gotten the total IETF workup from that community.

Business model update

There's a new spreadsheet reflecting our use cases work.

Upcoming meetings

We're meeting next week. We're not meeting Jun 6.

Attendees

As of 18 Oct 2018, quorum is 5 of 8. (Domenico, Peter, Sal, Andi, Maciej, Eve, Mike, Cigdem)

  1. Domenico
  2. Eve
  3. Cigdem

Non-voting participants:

  • Adrian
  • George
  • Nancy
  • Colin

Regrets:

  • Andi