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?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-21Minutes
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)
- Sal
- Maciej
- Eve
- Mike
Non-voting participants:
- Scott
- Justin
- François
- Adrian
- James
- John
- Colin
- Ishan
- Jin
- George
Regrets:
- Andi
- Domenico