UMA telecon 2015-08-13

Owned by Eve Maler
Last updated: Aug 13, 2015

UMA telecon 2015-08-13

Date and Time

Agenda

  • Roll call
  • Minutes approval
  • Last-minute quick hits
    • Trust elevation TC request
    • GitHub repo status
  • Issue resolution work (issues on GitHub) (UMA V1.0.1 issue nominations spreadsheet) ("sprint" document)
    • Are we definitely interested in putting significant breaking "upgrades" onto a major/minor release train?
      • E.g., issue 153/154
      • What would be a reasonable schedule for such an effort?
      • What type of release is it looking like? (SemVer says breaking = major...)
    • Now let's take a fresh look at the patch release
    • Can we tackle a few patch release issues today?
  • AOB

Minutes

Roll call

Quorum was reached.

Minutes approval

MOTION: Approve the minutes of UMA telecon 2015-08-06. APPROVED.

Trust Elevation TC request

Mike will follow up on Andrew H's request to write something up on UMA for the TC document. He's already on that TC.

GitHub repo status

Eve's xmlgrrl repo for UMA-Specifications is now moved over to the KI side.

Issue resolution work

We agree that a patch release is still the right thing to do. We assigned milestones afresh to all of the current issues. Eve will duplicate issues where they ultimately apply to subsequent releases.

Issue 161/162 discussion: The constraint is that the RS must be able, based on the C's access attempt with no token and no other context, to distinguish the AS and RO that match the protected resource set. In practice, this likely means that the URI needs to be unique per resource set. Let's mention this constraint in a few places. E.g., in Core Sec 1.3.1 and Core Sec 2. And we also have to put it into RSR Sec 2 and Sec 2.2.

Issue 163 discussion: 200 with a special header has been discussed. Let's align the header with the future! What do we think the V1.1/V2.0 header would be for the ticket, the RO-specific information the client would need, etc.? WWW-Authenticate: UMA parameters. So the name of this parameter would be what? We want to convey that we're not giving an error code, but we're starting a process that requires some additional action if they want to get the protected representation (ish) of the resource. We already have as_uri=as_uri and Justin would suggest that we have ticket=ticket in future. The sheer presence of the UMA header is all that is required – nothing else.

Issue 172 discussion: The feedback from the implementation process is that what's in the spec is not enough. The OAuth spec has more guidance on this type of thing. Can we be more specific without saying exactly what the lifecycle is? Can it be forever or not, e.g.?

The spreadsheet has a few more notes and champion assignments.

AI status

  • AI: Thomas: Review the charter for potential revisions in this annual cycle.
  • 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: Write SCIM protection case study to highlight client claims-based use case.
  • AI: Maciej: Write as many sections for the UIG as he can.
  • AI: Justin: Write a UIG section on default-deny and race conditions.

Attendees

As of 30 Jul 2015 (pre-meeting), quorum is 7 of 12. (François, Domenico, Sal, Thomas, Andi, Phani, Robert, Maciej, Eve, Arlene, Irwin, Mike)

  1. Eve
  2. Irwin (regrets for next three telecons)
  3. Arlene
  4. Thomas
  5. Mike
  6. Maciej
  7. Domenico
  8. Sal

Non-voting participants:

  • Adrian
  • Justin
  • Sarah
  • Nat
  • Mark
  • Jin
  • Scott

Regrets:

  • Andi
  • Robert
  • François
  • Ishan
  • James

Â