UMA telecon 2016-07-21

Owned by Eve Maler
Last updated: Jul 21, 2016
3 min read

UMA telecon 2016-07-21

Date and Time

Agenda

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

Â