I can't imagine UMA would not take advantage of API structure standards and I dispute the thought that support for API standards is a burden as long as that support is optional. This is not a zero-sum game. Designing UMA to support API standards is a pure win.

Of the 3 requirements: (a) is argumentative. The AS MAY handle a standard API if it chooses to provide that value. (b) the AS can just take the resource as described by the RS or it can add value based on a supported standard. This is a pure win and a basis for AS to compete for the RO's business. (c) is also argumentative. Yes, every AS MUST have a minimum of functionality in order to be called UMA and any RS that labels itself UMA must work with and UMA AS but that does not force any RS to support any particular standard. An AS can still aggregate all sharing (there's only one Alice) regardless of whether the particular AS or the RS supports any API standard.

I see absolutely no downside to designing UMA to respect API standards when both the RS and the AS can independently choose which standards to support.

Adrian
 

On Sat, Jul 23, 2016 at 11:46 PM, Eve Maler <eve@xmlgrrl.com> wrote:
Totally agreed that the general idea isn't specific to HEART/FHIR. It is, rather, generic to any API that is meant to be implemented independently by multiple implementers, which in the main means standardized APIs. This is why I'd like to keep the discussion to those features/recommendations that could be applied to the general class of them, just in case HEART/FHIR-specific ideas creep up. (FHIR may have anomalous things about it.)

Regarding the AS taking on complexity, note that there is a particular distribution of authority based on AS-RS loose coupling that does not follow this pattern: In UMA, the RS is authoritative for its own API (keeping in mind that many APIs exist for "fun and profit"), so asking the AS to magically become aware of semantics that are (as you call them) "domain-specific" could be a big ask.

The list of requirements is getting very demanding: An AS has to a) be capable of handling the semantics of every standard API from every walk of life without leveraging the explicit UMA interface, b) offer the most beautiful possible way of sharing resources at a fine grain in the RO user interface, and c) be accepted by all the possible RS's out there from a trust perspective because the RO will want to aggregate all sharing from only the one AS. And this is the minimum bar for UMA ecosystem success with ROs. Did I leave anything out? :)


Eve Maler
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl


On Sat, Jul 23, 2016 at 7:58 PM, Adrian Gropper <agropper@healthurl.com> wrote:
Eve,

The question of how to handle standardized APIs in UMA is hardly specific to HEART.

My perspective is simple and completely consistent with our principles of allowing the AS to be complex and the RS simple. The main value of UMA is that it enables delegation to a separate AS. I see no reason to introduce profiles when an acceptable API standard is available.

As far as the RO's user experience, that's their problem when they choose an AS. If they choose a stupid AS that's not standards-aware, then they get fewer policy choices. That's not an UMA issue. For its part, the RS is always able to assert compliance with an API standard or not. If the RS wants to use some particular profile instead of the standard, that's their choice.

Adrian

On Sat, Jul 23, 2016 at 10:35 PM, Eve Maler <eve@xmlgrrl.com> wrote:
Below:


Eve Maler
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl


On Sat, Jul 23, 2016 at 12:47 PM, Adrian Gropper <agropper@healthurl.com> wrote:
Well, I'm not sure I understand either. Let me try an example.

Let's say an EHR exposes a standardized FHIR resource

To be really precise, I think you mean an EHR system here.
 
and I register https://ehr.example.com/patient/adrian123 with some authorization server.

Technically, the RS registers it. (I assume you mean that you are the RO here. You might possibly have told the RS that you would like to put this resource under the protection of the AS, but it's at the RS's discretion to give you that choice.)

(Does this resource, as defined by FHIR, in fact consist of a whole EHR if it's read just as you've specified it here?)
 
Everyone (AS, RS, Client) can lookup FHIR and see that .../patient/[patientID]/medications and .../patient/[patientID]/allergies are defined by the standard.

Everyone (and everything) "FHIR aware" can do that. But an AS is, as far as we know/define here in the UMA group, just an UMA-conforming AS, not a FHIR-aware or -conforming service.
 

When Bob's client shows up looking for access, can my AS grant a scope only for .../patient/[patientID]/allergies even though I registered the entire patient-level resource? 

An UMA AS is "dumb" with respect to resource set and scope semantics, other than what an RS tells it explicitly -- or other than what a profile might layer on top implicitly. Here are the options I can think of:
  • Explicit resource set registration (RSR) of a selected set of API calls that together constitute the "recognized" resource sets in the protected API. For a standard API, this could be packaged into a profile for interoperability.
  • A combination of explicit RSR of some resource(s) and implicit automatic recognition by the AS (in the role of a speciality service, not an AS per se) of the rest of the resources, to capture all the rest of the semantics of the protected API, if there's a very large number or a complex set of resources. This could similarly be done as a profile. This option starts to rely heavily on those special semantics for the RO's user experience because policy-setting and such will become tightly bound to recognition of the API.
  • Some new explicit RSR capability that doesn't exist yet in UMA that provides a more efficient way to capture the full number/complexity/relationship of API calls possible in an API such as FHIR, so that every permutation of resource is possible for the RO to share. (You could technically do this with the "flat RSR" capability now, but I don't think anyone has the stomach for that.) Note that this would potentially have an impact on the RO's user experience of policy-setting -- possibly an overwhelming number of sharing choices.
(N.B.: I don't want to get into HEART work on the UMA list, so let's please focus on UMA design impacts rather than HEART-specific implications if possible. Thanks!)



Adrian

On Fri, Jul 22, 2016 at 7:21 PM, Eve Maler <eve@xmlgrrl.com> wrote:
Thank you for the correction.

...but I'm not sure I understand. Registering resources for protection doesn't imply exactly how the resources are shared or not shared from that point on; it just means that they are now in the "central protection domain of the AS" vs. totally in the "edge protection domain of the RS", if you will.

The granularity beyond what's registered is not visible at the UMA level. (As we've been talking about in HEART, there might be semantic granularity defined in an API-specific profile.)

Is there something else to what you're saying?


Eve Maler
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl


On Thu, Jul 21, 2016 at 12:27 PM, Adrian Gropper <agropper@healthurl.com> wrote:
Important nitpick: I did not say the RS registers "a whole EHR". I said the RS registers "a whole patient-level resource". This is important in the #wideeco sense where a patient (or any other entity with considered in the API standard) simply wants to delegate as much control as possible to their AS. In cases where the AS is not smart enough to handle that kind of power or the AS is not fully trusted by the RO, registering subsets of the available resources makes sense, however, the primary case should be one where full agency can be granted to an AS within the limits of the API standard.

Adrian


On Thursday, July 21, 2016, Eve Maler <eve@xmlgrrl.com> wrote:
http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-07-21

Minutes

Roll call

Quorum not reached.

Critical mass reached.

Approve minutes

Approve minutes of UMA telecon 2016-06-30, 2016-07-07: Deferred.

Review spec editing and logistics progress

Some news and decisions documented here. We have removed our generated artifacts from our source repository. They should go elsewhere, either in a KI GitHub repo or in the sort of structure they're in now.

The UMA1 language around ordering of client-AS interactions used "non-RFC2119" descriptive verbs for the flow, which seems to have had the salutary effect of allowing the client to go directly to the claims endpoint vs. having to "pass GO", that is, stop at the RPT endpoint first. This relates to the latest "Questions about MPD" thread discussion. James had raised an objection, but doesn't feel strongly enough about it.

See IETF RFC 4949 for authentication vs. login.

Spec editing instruction:

  • Replace the descriptive flow wording in "phase 2" with normative wording (e.g., from "if the X does something, then the Y does something" to "the X MUST do something...")

Including multiple resource sets while registering for a permission ticket

Proposed extension text that we created once upon a time, with the (one resource set = object, multiple resource sets = array) solution having been chosen.

Adrian asks: With a gigantic standard API like FHIR in play, what are the considerations for what the RS needs to tell the AS? There are two choices: Either the RS registers a big resource set such as "a whole EHR" and the AS has extra semantic smarts to know its innards, or the RS has to register all the component parts explicitly and the AS doesn't have to be smart about the sector-specific semantics. The latter doesn't sound very tenable.

  • The AS is supposed to bear more complexity than the RS.
  • The AS shouldn't have to peek into the structure to see what it is, but then it's supposed to bear more complexity. Also, the first character is the clue.
  • The RS shouldn't have to decide what structure to pick.
  • Then again, the RS should be able to do the simplest thing for the commonest case, which we could guess is the single-resource-set case.
  • On the third hand, the RS code would be cleaner if it could write arrays all the time.
  • And this pattern is familiar for AS developers who already deal with multi-value objects.
  • The RS data model shouldn't take the burden of all-arrays-all-the-time

Consensus on object-plus-array.

Open questions: If the resource server's request is authenticated properly but fails because one or more of the requested permissions has an invalid resource set identifier or an invalid scope, then... [TO BE DISCUSSED: What should happen? Should a partial result be registered? If so, what should be the response? Or should the whole thing fail? And do you get back one or multiple tickets?

AI: Justin: Write up a proposal for success and error responses. He says: Boolean, single ticket, keep it simple. General agreement.

Logistics

We have calls scheduled for the next two weeks, and then August 12 there's a cancellation.

Attendees

As of 14 Jul 2016 (pre-meeting), quorum is 7 of 12. (Domenico, Kathleen, Sal, Nagesh, Andi, Robert, Paul, Agus, Maciej, Eve, Mike, Sarah)

  1. Sal
  2. Maciej
  3. Eve
  4. Mike

Non-voting participants:

  • Scott
  • Justin
  • François
  • Adrian
  • James
  • John
  • Colin
  • Ishan
  • Jin
  • George

Regrets:

  • Andi
  • Domenico

Eve Maler
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl