UMA telecon 2015-06-04

Owned by Eve Maler
Last updated: Jun 05, 2015

UMA telecon 2015-06-04

Date and Time

Agenda

  • Roll call
  • Minutes approval
  • Quick hits:
    • Virtual plenary June 23-24 (not 24-25)
    • UIG review
  • Binding Obligations
  • "Roland testing" next steps
  • AI review and AOB

Minutes

Roll call

Quorum was reached.

Minutes approval

Deferred.

Virtual plenary June 23-24

The OTTO group is officially forming. The UMA group will be presenting. Eve hopes to use the virtual plenary time to discuss liaison opportunities among the different groups, particularly the "Connected Life" ones – OTTO, UMA, CIS, IRM... There is interest in liaising on the Binding Obligations connection with Consent Receipts.

Eve will also be discussing with Joni the process of reshaping our charter to set us up for success as we head into UMA V.next. We could bring this up at the virtual plenary as well. There's a "virtual coffee break" during the plenary meant for inter-group discussion exactly such as this.

UIG review

We took a look at the UIG and "woke up" this topic. As implementation questions come up, it's a viable strategy for us to add them to each week's agenda for discussion.

For Mike S's UIG action, we were thinking of practical implications of issuing AATs to clients untouched by human hands and so on.

"Roland testing" Interop testing

There's traditional interoperability testing, which is ideally cross-matrix. There's conformance testing, which is against an acknowledged and vetted test suite that represents a reference implementation that implements the standard accurately. Until a test suite is actually itself tested, what is the testing called? Is it interop testing, just not cross-matrix interop testing? That seems right: It's interop testing against a candidate test suite.

Eve suggests a schedule as follows:

  • Roughly Q3: Test suite development
  • IIW 21: Boundary where we kick off testing
  • Roughly Q4: Implementers test the test suite

This sounds good. The IIW 19 implementers' meeting notes are here.

What about the UMA-dev list? The added confusion, spam, moderation time, etc. seem not to be worth it. We were trying to serve a need that seems to have gone away.

AI: Eve: Make the UMA-dev list go away, and remove its mentions from the wiki.

We would like to collaboratively develop one example test to the nth degree, looking at how OIDC is doing this, so that we can take action items in helping Roland flesh out test materials going forward. Eve is prepared, for example, to identify spec content and section references.

Do we want to focus on AS testing at first? Justin recommends this. In 2016 we can see what's what around testing the other entities.

Next time Roland joins us, we'll let him pick the test and we'll work on it!

Binding Obligations

The use cases we discussed last time were:

  • Alice wants a receipt for:
    • PAT issuance
    • The policies she has lodged – is this as interesting? Eve suspects this is equivalent to health "consent directives" – so yes, this would be interesting to generate receipts for
    • Authorization data getting added to an RPT
    • The access Bob has succeeded in getting – Justin thinks this is more interesting
  • Bob wants a receipt for:
    • AAT issuance
    • The claims (facts and promises) he coughs up
    • Authorization data getting added to an RPT
    • The accesses he successfully achieved (RPT being used)

There is definitely interest in discussing this further at the virtual plenary. Eve is thinking that generating receipts shouldn't be a MUST for UMA, but rather something decided on by each deployment ecosystem. What's the expectation by others here? We think we're in sync. UMA is the "T" in the BLT sandwich; only the "B" or "L" should dictate that a receipt MUST be generated. Robert suggests looking at principles coming out of the CIS group.

What we meant by the binding obligations was "baseline participant agreements". We originally meant them to be required, but it's appearing as though they should be optional. Should we revamp the document entirely? It's a framework for entering into agreements, and the document even contains the phrase "contractual framework". There are a lot of concepts and terms here; which ones do we want to hang our hat on in a document? Is it time to rework or discard the document we have?

  • Participant agreements
  • Binding obligations
  • Consent receipts
  • Trust frameworks
  • Contractual frameworks
  • Trustmarks
  • Access federations
  • Legal implications for UMA (the oldest one)

AI review and AOB

Outstanding AIs:

  • AI: Sal: Investigate IP implications of formal liaison activities with other Kantara groups with the LC, and ultimately draft an LC Note as warranted.
  • AI: Gil: Edit the UIG to add Ishan's content and excerpt it for Eve to add to the FAQ, pointing everyone to the UIG.
  • AI: Sal: Fill out IDESG form to have UMA adopted as a recommended standard for use in the IDESG framework.
  • AI: Mike: Rework UIG section on organizations as ROs and RqPs.
  • AI: Eve: Update GitHub.
  • AI: Maciej: Write as many sections for the UIG as he can.
  • AI: Justin: Write a UIG section on default-deny and race conditions.
  • AI: Eve: Send suggested Wikipedia updates to Will at Gluu for English page updating, and to Domenico for Italian page updating, and to Rainer for hoped-for German page updating, and to Riccardo Abeti for the Spanish page, and to Mark for a Dutch translation.

Attendees

As of 3 Jun 2015, quorum is 7 of 13. (Dom, Sal, Mark, Thomas, Andrew, Robert, Maciej, Eve, Mike S, Jin, Ishan, John, Chris)

  1. Eve
  2. Mike
  3. Mark
  4. Robert
  5. Jin
  6. Maciej
  7. Sal

Non-voting participants:

  • Roland
  • Justin
  • Sarah
  • Colin

Regrets:

  • George
  • Thomas

Â