UMA telecon 2016-11-03

Owned by Eve Maler
Last updated: Nov 03, 2016
3 min read

UMA telecon 2016-11-03

Date and Time

Agenda

  • Roll call
  • Approve minutes of UMA telecon 2016-10-13 
  • Logistics for upcoming meetings (calendar) and 2016 roadmap check-in
  • Meta-discussion: Did anything come up at IIW that we need to discuss before/during working on UMA.next issues?
  • Work on UMA.next issues – Core is up to 06 – please review changes ahead of time! – comments in commits link directly to relevant sections in formatted spec
  • AOB

Minutes

Roll call

Quorum was reached.

Logistics

We're ON for Thu Nov 10 – regrets from Justin, Andi is unsure.

We need to MOVE our Thu Nov 17 meeting to 9am (usual hour) Fri Nov 18 – regrets from Cigdem, Domenico.

We're NOT MEETING Thu Nov 24 or Fri Nov 25 because of the US Thanksgiving holiday.

 

Approve minutes

Approve minutes of UMA telecon 2016-10-13: Deferred.

Work on UMA.next issues

"Authorization process": The definition could potentially be improved by breaking the first sentence into two. The second sentence could focus on risk management. Can we define "trust" formally somehow as managing risk? Do we need "trust elevation" anymore? This is a live thread in email. Is the equation "The RO only authorizes access within their risk appetite/tolerance"? Maybe this is where we could point off to the UMA Legal work because it's a complex equation and the RO isn't the only party with risk and liability. Robert notes that part of decision is how you make a good decision. A technical spec's job isn't to describe all of this, but it could point off to other resources that go into it.

"Authorization process: The process through which the client obtains an RPT from the authorization server in order to access a protected resource. The process has two activities, and these can iterate. One activity is assessing claims and other contextual factors against the resource owner's policy conditions. Another is is collecting claims, which can include both claims pushed from a client and interactively gathered from a requesting party. 

Suggestion to Domenico for his new flowchart: Try switching input and actor bands, and adding an actor so there's always two. Let's be sure that it's "technically accurate" as much as possible, assuming developers will take it seriously. Andi suggests it will be used more "generically", so maybe we can use it more at a 50K foot level.

Regarding "token profiling goes poof": Medication/read 22354546 read

Regarding the "*supported" options in the config data: Both Justin's and Cigdem's implementations implement and ignore them! Is there any dissent to pulling pat_profiles_supported and rpt_profiles_supported?

Instructions:

  • Sec 3.5.4: "The fifth error response, need_info, begins or continues..."
  • Redefine "authorization process" through as two activities/states, and be sure to incorporate "client identity" and any other contextual factors (we used to call this "RqP-independent").
  • Undo the "token profiling goes poof" and reconstitute the actual introspection response part; make use of 7662 mandatory.
  • Remove pat_profiles_supported and rpt_profiles_supported

AI: Eve: Send separate email threads about all the other "*supported" config data fields and rationales pro and con.

Attendees

As of 3 Oct 2016, quorum is 6 of 11. (Domenico, Sal, Nagesh, Andi, Robert, Maciej, Eve, Jeffrey, Mike, Cigdem, Sarah)

  1. Domenico
  2. Nagesh
  3. Andi
  4. Robert
  5. Maciej
  6. Eve
  7. Cigdem
  8. Sarah

Non-voting participants:

  • Justin
  • Francois
  • Kathleen

Â