UMA telecon 2015-08-27

Owned by Eve Maler
Last updated: Aug 27, 2015
4 min read

UMA telecon 2015-08-27

Date and Time

Agenda

  • Roll call
  • Minutes approval
  • Last-minute quick hits
    • Conclude on topic: Restricting GitHub editing
    • Any interest in Kantara workshop space on December 4 in Vienna at Rainer's European Trust and Identity Workshop?
  • Issue resolution work:
    •  Links: recent commits (click on each identifier code to review changed text in context) - issues on GitHub - UMA V1.0.1 issue nominations spreadsheet - "sprint" document
    • This is intended to be our final week for considering/resolving substantive issues, so please review, and please do any outstanding spec action items!
    • Then we are set to approve our Draft Recommendations for next-stage LC approval by Sep 3 or Sep 10 (note: Eve regrets for Sep 10)
  • AOB

Minutes

Roll call

Quorum was reached.

Minutes approval

MOTION: Approve the minutes of UMA telecon 2015-08-13 and UMA telecon 2015-08-20. APPROVED by unanimous consent.

Conclude on topic: Restricting GitHub editing

Deferred.

Workshop space

No takers at the moment.

Formatting the specs

Maciej has an XSLT for turning UMA's XML2RFC source into Kantara specs. He is willing to take it the rest of the way. Let's pursue this.

Issue resolution work

#163/#168: Given the early stage of UMA implementations, and given the technical soundness of the fig-leaf logic for MAY/SHOULD/MUST, we are going to add the ticket parameter in the header, and greatly soften the need for the ticket body.

#176: Why would an RS want to indicate to a client that it's giving it a public version of the resource, but that there is a protected version, and it can't help the client seek access to it right now? Then the client could a) know that there's more, and b) choose to try later. Should the RS try again on its own later? No, because it has no relationship with the client; why would the RS take action on its behalf? The RS could, of course, respond with a non-UMA response (which gives no hint of anything wrong). So if there's any option at all to respond with "an UMA response", then there should be some reason to use it. Suggested: A new header. James suggests (from the HTTP spec):

Warning: 199 UMA Authorization Server Unreachable

The client is not allowed to take any automated action beyond displaying this text to the RqP, but that lets the RqP know that there's "more" behind the RS.

"If the RS received an XXX error from the AS, and did not receive a permission ticket, then is unable to create a WWW-Authenticate: UMA header and MUST include a header of the following form: "Warning: 199 UMA Authorization Server Unreachable"."

#172: Justin is looking for more implementation guidance, which we're thinking should really go in the UIG rather than here. Should we include a cross-reference out? Let's do it. We will stick to language that supports the RFC 2119 normative assertions in the spec.

#171: Eve SWAG'd some text guessing that we would require at least one scope to be registered in future. But no one?? is crazy about making this kind of a decision now. So let's revert it.

#164: Goes away because there are no mandated HTTP codes anymore!

#161: We are cycling on Justin's wording:

Note: When a client attempts access to a presumptively protected resource without an RPT, the resource server needs to derive the authorization server and resource set identifier associated with that resource from some other aspect of the client's request. This effectively means that the resource server’s API needs to be structured in such a way that the client's RPT-free request uniquely identifies the resource set. In practice, this information likely needs to be passed through the URI, headers, or body of the request.

Done.

#160: Looks good; we'll get review of the whole spec later. The last STRONGLY RECOMMENDED should be in active voice, not passive.

#151: We shouldn't have the AS check for URI host/scheme matching, so the second part of the third paragraph in RSR Sec 4 should come out. We don't want to add any SHOULDs.

#144: Just needs s/s/z/ in AS. (smile)

Shall we close all of the issues at this point? We're ready to close them and review the final text, once Maciej has done the final edits tonight. We may be ready to vote on progressing the candidate Draft Recommendations to the LC next Thursday.

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 21 Aug 2015, quorum is 7 of 13. (François, Domenico, Sal, Thomas, Andi, Phani, Robert, Maciej, Eve, Arlene, Irwin, Mike, Jon)

  1. Eve
  2. Thomas
  3. Mike
  4. Maciej
  5. Arlene
  6. François
  7. Jon
  8. Sal

Non-voting participants:

  • Sarah
  • Ishan
  • Mark
  • James
  • Justin
  • Dazza
  • Andi

 

Â