Versions Compared

Old Version 1

changes.mady.by.user Eve Maler

Saved on

compared with

New Version Current

changes.mady.by.user Eve Maler

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

UMA telecon 2015-12-17

...

Agenda

  • Roll call
  • Note: This is the last meeting of 2015
  • Approve minutes of UMA telecon 2015-09-24 and UMA telecon 2015-11-05
  • All-Member Ballot progress
  • Roadmap and charter refresh discussions: what topics are top-of-mind beyond what we listed last week?
  • UIG
  • AOB

Minutes

...

Roll call

Quorum was reached.

Approve minutes of UMA telecon 2015-09-24 and UMA telecon 2015-11-05

MOTION: Andi moves: Approve minutes of UMA telecon 2015-09-24 and UMA telecon 2015-11-05. APPROVED by unanimous consent.

All-Member Ballot progress

We believe we're well into "passage" territory with the early numbers. This closes on December 23.

Assuming we have no "No" votes to dispose of, we think we'll wait to take on the I-D publication task until the Recommendations are published. We think we can do this towards the very end of the year or early January.

Speaking of "DRY" systems, there has been some question about rationalizing the Kantara spec publication link system.

AI: Eve: Dig up her recommendations to Kantara about how to rationalize spec links and share them with the list.

Roadmap and charter refresh discussions: what topics are top-of-mind beyond what we listed last week?

Let's enhance the list of use cases of interest that we started to collect last week (problem spaces, unprioritized for now; refer back to our design principles and requirements in trying to prioritize in January):

  • Local token introspection
    • Interesting for IoT and more
    • There's an issue about this!
  • Permission registration extension
  • Wide ecosystems and how the AAT and identity claims tie in
  • Client-to-AS-first flows to serve API security (AS-RS tight coupling)/federated authorization (AS-RS loose coupling) use cases
    • IOW, use cases where an architect would normally reach for OAuth, but there may be benefit in reaching for UMA if it satisfies additional needs not currently satisfied
    • Has interactions with local token introspection – for efficiencies and for "OAuth audience appeal"
      • Though it's desirable to dig into which kind of appeal it has: client app simplicity, security, performance, UX...
    • Perhaps we can ask the question: even in loosely coupled situations, do some UMA deployers want "smart clients" (guessing this means to AS first) and some want "dumb clients" (guessing this means to RS first)?
  • Patient right of access (as in HIPAA)
    • The concern is that some parties out there are worried about security with a new "trust framework" type of approach
    • Adrian has been introducing the notion that independent "keys" for each resource could be a solution, but we're not sure about this and want to stay at the problem space level for the moment
  • Concerns about the burden imposed by the AAT
    • Can we quantify the burdens? Maciej has, here(smile)
    • This has interactions with the need for permission tickets and the idea of permission registration extension
  • The need for permission tickets at all
    • This has interactions with the AAT burden and permission registration extension
  • Resource server putting controls around scopes being granted, vs. the resource owner (Ishan)
    • Currently, this is out of scope/band of UMA (see UMA Core Sec 3.3.3) - he's currently talking to some customers about adding "flags" to achieve this for a higher LOA
    • This sounds like something Adrian has been talking about too
    • Alice does DAC while the RS does MAC

Andrew observes: If you're in a static federation (or in a tightly coupled environment), you can do away with a lot of the artifacts, such as permission tickets. Eve points out the "extensibility profiles" in UMA Core that make this possible. But Andrew points out that even beyond the technical level, federations might want to agree to do away with some artifacts. Then the question becomes: Is what they're doing truly UMA? Should it be true UMA in future?

Adrian points out: As always, we need to design for privacy!

UIG

Andi reports: He looked again at the non-required parameters for UMA V1.0.1. Thanks, Andi! Eve will follow up on his email.

AOB

Andi announces that the CIS CfP is open! There is definitely space for UMA things (if limited...). He has tweeted, and will post, the link.

Adrian puts in a bid for more education around how "generic" vs. "semantics-dependent" an AS is on a resource server's resource set scopes.

 

Attendees

As of 15 Dec 2015, quorum is 6 of 11. (François, Domenico, Sal, Thomas, Andi, Robert, Maciej, Eve, Søren, Arlene, Mike)

  1. tbsEve
  2. Andi
  3. Arlene
  4. François
  5. Domenico
  6. Robert
  7. Mike
  8. Maciej
  9. Thomas

Non-voting participants:

...

  • Katie
  • Adrian
  • Justin
  • Colin
  • Andrew
  • Ishan