UMA telecon 2014-12-11

Owned by Eve Maler
Dec 11, 2014

UMA telecon 2014-12-11

Date and Time

Agenda

  • Roll call
  • Minutes approval if quorum
    • Sample motion: Approve the minutes of UMA telecons 2014-12-04 and 2014-11-20 and read into today's minutes the notes of ad hoc WG meetings held since 2014-11-20.
  • Interop testing status and meeting schedule review
    • Speed vs. completeness, and remaining V1.0 issues
  • Review of core 13 and FT-impacting issues on V1.0 docket
    • Claim token profile ideas: Domenico, Mike
    • Redirect flow: Maciej
    • 110: RSR location URI for registration of discovery info?
    • 84: UMA endpoint names vs. OAuth endpoint names: do we have to change user_endpoint to authorization_endpoint, and then do we have to change our authorization_request_endpoint to something else?
    • 94: start_at for permission validity: shall we add this?
    • 116: mentioning OIDC dyn reg too: shall we add this?
    • 115: syncing token introspection profiling to the latest draft: who is willing to take on this analysis?
    • 95: multiple AS protection over one resource set: okay to drop this for consideration in 1.0?
    • 51: JWT profile for local introspection: high enough interest to do an RPT profile for this in Core 1.0?
    • What else?
  • AOB

Minutes

Roll call

Quorum was reached.

Minutes approval if quorum

MOTION: Approve the minutes of UMA telecons 2014-12-04 and 2014-11-20 and read into today's minutes the notes of ad hoc WG meetings held since 2014-11-20. APPROVED by unanimous consent.

Interop testing status and meeting schedule review

We discussed the results of the call with Roland and the speed vs. completeness tradeoffs. Mike speaks in favor of speed. Maciej speaks moderately in favor of speed. UMA V1.x efforts are expected to happen eventually. "Done is better than perfect." "Delaying the release will hurt more than help us." Does anyone want to make the opposite case? No; we have consensus. So let's do issue triage. Issues that must be handled in V1.0:

  • Redirect callback URL handling and requesting party claims endpoint responses: currently underspecified; Maciej has action
  • Claim token profiling "interface": Eve has editing action
  • 110: discuss
  • 84: Eve has action to make a recommendation
  • 116 (probably will go along with redirect callback URL handling examples, at a minimum): Eve has eventual editing action
  • 115: Eve has action to ask Justin (and/or Roland?) to help with this quickly – our backup is Mark!
  • 117: Mark has action to propose something
  • 90: Mark has action to review and come up with a proposal for a principle as required

AIs: Eve, Mark, Maciej: See above!

Issues to leave off for V1.0:

  • 94
  • 95
  • 51 – has broader implications and needs to be use case-driven
  • 108: Marcelo has an action to research this, but he will add a note to the issue and we are agreed we'll keep it in the backlog
  • 91
  • 87
  • 65

We are definitely meeting next Monday.

Redirect callback URL handling and requesting party claims endpoint responses: currently underspecified

Maciej will propose the mechanisms required here. We hope to have text to examine by next Monday's call.

Claim token profiling "interface"

We examined Domenico's diagram and Eve's explanation of an idea to treat the URI "interface" between the claim token format in required and pushed claims as something that could have an IANA registry, with the claim profiling spec possibly going away. Mike's implementation has the IdP and the AS being the same server, so the AS can locally retrieve the claims. Eve points out that when the RqP is redirected to the AS for claims gathering, this process is opaque to UMA; only claims "pushing" is part of the UMA flow. Mark mentions that there are considerations around things like audience restrictions; claim token formats have different properties, so we should probably state something about this. Could we state these considerations generically? It sounds like we could. In fact, if we define a few, it may give the impression that we're limiting the possibilities. We should add specific language to the Core spec clarifying that any claim token formats, standard or proprietary or a hybrid of the two, could be used, and it is RECOMMENDED to formally define claim token format profiles in use. (See other spec language in Core for examples of this.)

AI: Eve: Propose claim token format considerations wording, including privacy considerations, by Monday.

AI: Eve: Create a claim token format IANA registry issue.

Domenico is interested to try and include claim "assurance" as part of our claims gathering. Eve suggests that if we can find claim token formats that supply claim assurance or other quality information, then we could provide hints in our required claims – but otherwise we may not be able to ask for information that can't be supplied. For claim token formats that do supply it, third parties can extend the hint format.

not_authorized vs. need_input

Eve wonders once again whether these could usefully be consolidated. Any interest in considering a language proposal? What is the behavior on receiving one vs. the other? Presumably not_authorized gives a true failure without recourse. Maciej argues for keeping both. Not enough interest in Eve crafting a language proposal.

Location discovery option for RSR spec

Mark summarizes his and Eve's back-channel discussion to date: Discoverability is a property of a resource that you do want to pay attention to, and it's a common problem in many resource-related standards, not specific just to UMA. His initial concerns related to discovery vs. UMA, but this is targeted to the OAuth layer in the RSR spec.

Maciej in fact already implements this feature, called x-link (as an extension) in his implementation, as part of the resource set description block as described in Section 2.2 of RSR. He recommends that we call it resource_uri.

Mark brings up a concern about "scopes"; if UMA is the spec using RSR, then UMA applies scopes to the resources in a particular way, but maybe other specs won't interpret them similarly. Let's try and suss that out for Monday's conversation.

AI: Mark: Write thoughts on resource discovery for Monday.

Attendees

As of 4 Dec 2014, quorum is 6 of 11. (Dom, Sal, Mark, Thomas, Andrew, Robert, Maciej, Eve, Mike, Jin, Yuriy)

  1. Eve
  2. Mark
  3. Sal
  4. Domenico
  5. Maciej
  6. Mike
  7. Thomas

Non-voting participants:

  • Robert
  • Zhanna
  • Marcelo
  • Adrian

Next Meetings

We will hold all-hands meetings (calling the roll) through the fall and early winter as much as possible; voting participants please attend! We are now also holding ad hoc meetings on Mondays (not listed below). You can subscribe to the UMA calendar (and ask the chair to send you an event invitation) to see the times in your local time zone. Keep in mind that when the clocks change, we experience "summertime skew"; our home time zone is Pacific so non-US meeting times may shift.

  • Thu Dec 18 (ad hoc meeting 8-9am PT followed by) quorate meeting 9-10am PT: possible to approve V1.0 drafts on this date?
  • No meeting Thu Dec 25 because of Christmas holiday
  • No meeting Thu Jan 1 because of New Year's Day holiday

Â