Page Comparison

...

• Roll call
• Approve minutes of UMA telecon 2016-06-30, 2016-07-07
• For reference: MPD sequence diagram and generic low-level sequence diagram
• Including multiple resource sets while registering for a permission ticket
  • Review Justin's proposal (if available) on success and error responses in case of attempts at registering multiple resource sets (general idea: Boolean, single ticket)
• What is necessary to do in UMA about RSR for standard APIs?
  • Thread with Adrian
• Begin building a comprehensive model for client awareness of scopes and set math at every step
• AOB

Minutes

Roll call

tbsQuorum was not reached.

AI: Eve: Clean up the rolls.

Approve minutes

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

tbs

tbs

Attendees

As of 14 : deferred.

Multiple resource sets in permission registration

Nothing much to say beyond last week's discussion. Let's just parcel out the spec text assignment.

UMA specs wrt standardized APIs with standardized resource and scope semantics

What should an UMA AS as a value-add standardized API server do?

E.g., since the FHIR API has a really huge structure for "resources" (UMA resource sets) with a hierarchical structure, Adrian suggests that when a requesting party's client shows up and attempts to access some 'higher-level" or "containing" resource, the resource owner needs to be able to instruct the AS to give access to some subset of the resources "within" or "associated with" it, and not all of them.

On the Release of Information (ROI) form that US hospitals have patients fill out, there's a place where patients can initial that HIV information would specially be permissioned to be shared vs. not. (Is that right?)

The word "itemization" might capture the issue. If there's a special "FHIR AS" and "FHIR RS" vs. the plain ones, they wouldn't have to use the regular RSR interface to exchange information by brute force about the resource sets and scopes; it could be done implicitly based on a separate profile or something. It seems out of scope for UMA to standardize, because anyone can invent a standard API with sectoral or whatever semantics, and UMA protects that API. A URI could be pointed to that represents those semantics.

The protection API extensibility profile in UMA could be an excellent tool for enabling "implicit RSR" of these well-known FHIR semantics. Adrian is concerned that an RS that doesn't know about FHIR doesn't fail, however; thinking about graceful degradation is a good idea. If the profile is listed in the AS's discovery document (the "configuration data"), that would enable the RS to know what the AS is capable of supporting. Should we have a way of letting the AS declare hard requirements to RS's? Any one RS knows whether it supports whatever profile or not; Adrian wants there to be a way, in the case of naive AS's, for the RS to adhere to the web mantra of being strict in what it produces and generous in what it accepts.

Sal points out IoT devices with APIs could have their own profiles, and so on ("physical resources such as doors, e.g. access to public space, access to employee space, access to restricted by role space and super secret (e.g. a SCIF)").

We have consensus on this direction.

Editorial instructions:

• Write up the solution for the UIG:
  • This is an example of how a third party (e.g., the HEART WG) would leverage the protection API extensibility profile to create an out-of-UMA-band mechanism for the standardization of resource set types and their associated scopes.
  • It would involve the use of the protection API extensibility profile.
  • It would involve the definition of an extension profile because the API is standardized (meaning it is independently implemented by multiple implementers). These definitions would, we believe, involve implicit usage of the "type" field.
  • It would involve implicit registration of resource sets and their scopes, not explicit use of the RSR API endpoint, for at least some resource sets (would there be explicit RSR for a "bootstrap" resource set?).
  • Extensions and profiles are already recommended to contain security and privacy considerations sections.
  • We should recommend that HEART be our guinea pig and write tiny profiles for these and then implement them to see how it goes.

Editorial instructions for spec text work:

• Create updated swim lane contemporaneously

Client awareness of scopes and set math

We'll start with these notes next time.

Attendees

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

...

1. Domenico
2. Sal
3. Eve
4. Jeffrey Ritter – lives in Durham, NC – tech standards from the legal end – UN electronic commerce, information security, ISSA, more recently Oxford and Johns Hopkins – coined/invented "quantum law"
5. Mike
6. Sarah

Non-voting participants:

...

• Adrian
• James
• François
• Colin
• Scott S
• John
• Jin
• George

Regrets:

• tbsJustin