UMA telecon 2016-02-11

Owned by Eve Maler
Last updated: Feb 11, 2016
3 min read

UMA telecon 2016-02-11

Date and Time

Agenda

  • Roll call
  • Approve minutes of UMA telecon 2016-01-07
  • Kantara OTTO WG and how it relates to UMA (Mike)
  • Confirm initial use case prioritization (UMA Roadmap for 2016) in the whole-WG telecon series:
    1. #security
    2. #wideeco
    3. #IoT
    4. ....
  • Appoint a small contingent to look at revising our charter as required
  • Review the recommendations from our issue #239 ad hoc subgroup and decide on next steps
  • AOB

Minutes

Roll call

Quorum was not reached.

Approve minutes

Deferred.

OTTO WG

OTTO stands for "Open Trust Taxonomy for OAuth2". This proposal captures the work that is now rapidly progressing. It's a generic way for defining a registry of services, no matter what metadata might be used for the services (SAML, OAuth, other). Are any other "trust bundle" sources using dynamic methods of updating? A number of federations in the education space are straining to scale. The OTTO proposal uses json-ld, which has some interesting properties, such as canonicalization and XML Signature-like signing. Justin notes that the JOSE group explicitly avoided canonicalization because it comes with so many pitfalls. The proposal includes some UMA RS-to-AS onboarding examples.

Mike is calling for people to participating in the WG, which meets on Wednesdays 8am PT/10am CT/11am ET/4pm UK/5pm CET.

What about other systems, such as NIEF and GTRI? Are they actually comparable in terms of functionality? Unclear. Adrian mentions some past work with similar efforts that had some disappointing and privacy-invasive results.

Consent receipts and UMA

There's interest in the "shoebox endpoint" in the context of UMA. Sarah speaks in favor; she's been working on the id-events space of late. John mentions a shoebox is a kind of KeyPass or 1Password or similar user space solution. A clearly defined technical specification for consent receipts enables organizations with customer obligations around consent management to build their own tools appropriately. Adrian speaks in favor of the shoebox endpoint, but philosophically he sees it as a notice endpoint, not necessarily (just?) a repository of consent. This is related to agency law; you can't have a viable business structure around UMA unless you have a notice capability. Adrian: "At some point we are going to have to do privacy engineering around UMA." – this is not really separable from the #wideeco use case, in the sense of blinding/credential brokerage/privacy-preserving identity mechanisms.

Regarding "notice and consent", John notes that the consent receipt reflects the result of a transaction. In different jurisdictions (US vs. EU), privacy is contractual vs. human rights-based.

Prioritization

For the whole WG (for now):

  1. #security
  2. #wideeco
  3. #shoebox (the technical side)
  4. #IoT

For the legal subgroup (for now):

  1. #trust generally (which is just developing model clauses etc.)
  2. #RSctrl and #ROctrl and #shoebox (the legal side)

Charter

AI: Adrian: Take a look at the current UMA WG charter and recommend any wording changes. Andi to help as he sees fit.

Issue #239 discussion and review

Eve presented the attack and the proposal briefly. The threat is applicable only to some methods of trust elevation (not to step-up authentication, nor to pushed claims, only to interactively gathered claims at the claims-gathering endpoint), and is not applicable to any known or imminently planned UMA deployments (e.g., Gluu's current deployments use step-up authentication only). The subgroup looked at quite a few potential mitigations and rejected most. The one it recommends for now involves adding entropy to the permission ticket so that an attacker RqP can't steal away a victim RqP's already trust-elevated right to access an RO's protected resource. Any mitigation would be backwards-incompatible. We have recommended packaging the proposed mitigation in an extension spec so that only those needing it can deploy it alongside core UMA in an identifiable way. When the time is right, we can choose to slot it into core UMA, or by then, we might have designed a wholly new UMA V.next design.

Mike, Kathleen, and Adrian speak in support. Andi has some concerns that he will send in email. Mike suggests, if we go this route, putting an erratum note of some kind in the base spec. Kathleen notes that getting a mitigation out sooner is better because otherwise people just assume protocols like UMA are safe and there could be a backlash.

Would incorporating the proposed mitigation into the core spec mean we'd make a V1.1 or something? Nominally no, because we have adopted semantic versioning.

AI: Sarah: Draft a "friendly doc" describing the exploit and the proposed mitigation(s).

AI: Eve: Send Sarah the source WSD for the attack.

Let's try and get a full set of voting participants to attend soon so we can have a full discussion and decision.

Attendees

As of 20 Jan 2016, quorum is 7 of 12. (Evariste, François, Domenico, Kathleen, Sal, Thomas, Andi, Robert, Maciej, Eve, Søren, Mike)

  1. Eve
  2. Kathleen
  3. Mike
  4. Maciej
  5. Andi
  6. Domenico

Non-voting participants:

  • Sarah
  • Justin
  • John W
  • Adrian
  • George
  • James
  • Ishan
  • Jin