UMA telecon 2018-10-04

Owned by Eve Maler
Last updated: Oct 04, 2018
4 min read

UMA telecon 2018-10-04

Date and Time

Agenda

  • Roll call
  • Approve minutes of UMA telecon 2018-09-20 
  • Update on PIPC/captive insurance discussions if available
  • Update on interop testing activities if available
  • Discuss Adrian's notification use cases (see last email in this thread)
  • AOB

Minutes

Roll call

Quorum was not reached.

Approve minutes

Approve minutes of UMA telecon 2018-09-20: Deferred.

Update on PIPC/captive insurance discussions if available

Next week we plan to have a meeting, or maybe multiple meetings, related to PIPC. Vermont's AG is looking at a project involving a "regulatory sandbox" (was it called "FCA"?).

Update on interop testing activities if available

Prabath is able to join the Oct 18 WG call to do a demonstration of the WSO2 UMA2 implementation. By then we should hopefully have a better idea of matrix tests and even some published blog posts from the various testers.

Does the June 2019 Identiverse timeframe make sense for thinking about an interop event? Yes, likely. Eve and Andi can discuss offline. Colin also hears of additional vendor interest.

Discuss Adrian's notification use cases

Adrian's proposed use case text is reproduced below. This is all related to notifications. Let's discuss, analyze whether they're solvable with "UMA today", and if not, what the next steps are.

1 - Alice (RO) needs to be notified by the RS that the RS has ignored or modified an AS scope. (This is the Adrian Clause)

Another way to state this (more technically stated) is that the RS receives an RPT from the client (that the AS correctly issued), determines what resource IDs and scopes are associated with it, and then chooses to act in a way contrary to the scopes listed for a specific resource ID. (Either fewer scopes – more constrained – or more scopes – less constrained.) The latter is a sort of hard form of "break-the-glass", meaning that there was never an RO policy allowing that much scope. (We discussed this in the UMA Legal subgroup with a decision-tree approach on 2016-01-15.)

You can consider the knowledge of whether the access was given to be part of the equation of "Accounting of Disclosures". This topic is most often associated with healthcare security/privacy, but also has implications for other data protection regulations such as GDPR. The RS is exclusively in a position to know whether it gave access. However, it could inform the AS (and rely on the AS to tell the RO) vs. telling the RO directly.

What are the timeliness requirements of this notification type? It doesn't seem strongly sensitive.

What are the channels by which the RS could communicate its activity to the RO?

    1. The RS presents some app to the RO for managing resources; that app is outside the scope of UMA. (E.g., a photo service/app would have to develop its own notification functionality, or a patient portal would have to develop its own notification functionality, anytime the "Adrian clause" were invoked.) The RS app would be the one to produce notifications of RS behavior upon choosing the "anomalous case" regarding giving clients access after receiving an RPT, vs. the "normal case". For that matter, notifications/log entries could be produced anytime access were granted in the normal case too. Some implications:
      1. Each RS app produces such notifications independently, rather than enabling centralization (aggregation?) of such notifications.
      2. Each RS can guarantee that it has produced a notification of its own true behavior.
    2. The AS (or the service presenting a standardized UMA protection API to RS's, that is, an AS interface) presents in addition some notification endpoint – which doesn't yet exist – to UMA RS's so that they can report details of their access-giving behavior to that endpoint. The intention is for that service to become the aggregated notification-producing service for the RO. Some implications:
      1. The notifications now come from a single service, vs. potentially multiple independent apps.
      2. Each RS now must rely on that central service to relay/make available the details of the access-giving behavior to the RO.

Did the previous implementation that Maciej has demonstrated show an RO notification flow?

2 - Alice (RO) needs to be notified by the RS that the Client presented to the RS is deemed inadequate for automated registration and Alice herself, not Alice’s AS, must acknowledge the warning by the RS in order for the Client access to proceed. (This is the current interpretation of HIPAA for patient-directed exchange)

This notification type has strong timeliness requirements.

3 - Alice (RO) needs to be notified by the AS that a RqP has presented with a query for registered resources. (This is where someone other than Alice invites the RqP to access her resources without specifying a particular resource).

See 38:00 in the Google TechTalk video for a demo of this from way back. We have additional implementations, probably with a variety of approaches: API endpoints, web hooks, etc. We may want to compare approaches and see if there's any motivation to standardize for interop.

4 - An RS or an RqP wants to notify Alice of something but they only have the service endpoint of Alice’s AS. (Alice is using the AS as a blind drop the way she might use a dating app)

To be continued.

Attendees

As of 7 Mar 2017, quorum is 4 of 7. (Domenico, Sal, Andi, Maciej, Eve, Mike, Cigdem)

  1. Domenico
  2. Andi
  3. Eve

Non-voting participants:

  • Adrian
  • Colin

Regrets:

  • Nancy
  • Maciej