UMA telecon 2014-11-13

Owned by Eve Maler
Last updated: Nov 13, 2014

UMA telecon 2014-11-13

Date and Time

Agenda

  • Roll call
  • Minutes approval if quorum
    • Sample motion: Approve the minutes of UMA telecon 2014-10-09 and read into today's minutes the notes of UMA telecon 2014-10-16, UMA telecon 2014-10-23, and notes of ad hoc WG meetings held since 2014-10-09.
  • Interop testing status
  • Meeting schedule review
  • Review of FT-impacting issues on V1.0 docket
    • Core rev 12 and RSR rev 04 reflecting a number of newly closed issues (#111, #109, #105 (status param), #104, most of #103 not yet closed) and Monday's OIDC vs. OAuth decision related to issue #92 (trust el)
    • 108: make "protection" and "authorization" scopes able to be implicit: see Eve's proposal based on Monday's discussion: can we come to a conclusion?
    • 92: trust elevation: see Eve's proposal discussed Monday in the context of other decisions and discussions: can we come to a conclusion?
    • 110: RSR location URI for registration of discovery info? 
    • 84: UMA endpoint names vs. OAuth endpoint names
    • 94: start_at for permission validity
  • AOB

Minutes

Roll call

Quorum was reached.

Minutes approval if quorum

MOTION: Andi moves: Approve the minutes of UMA telecon 2014-10-09 and read into today's minutes the notes of UMA telecon 2014-10-16, UMA telecon 2014-10-23, and notes of ad hoc WG meetings held since 2014-10-09. APPROVED by unanimous consent.

Interop testing status

Roland had trouble getting on the call. We'll try and do more in email later.

Meeting schedule review

See below!

OAuth vs. OAuth-based protocol protection

Thomas and Eve partially implemented the ad hoc decision on this from Monday in rev 12 of Core, but it needs more work. Specifically, they didn't put in the part about: "For those use cases where an identity token is required in addition to an access token, it is RECOMMENDED that an OAuth-based authentication protocol such as OpenID Connect be used."

AI: Thomas, Eve: Add this sentence somewhere in Section 1.3.

108: scope implicitness

Marcelo's idea was actually that the config file would enable scope mapping, so that a client could dynamically discover what the relevant scope keyword would be for gaining "protection" (or "authorization") scope if the keyword weren't, in fact, the UMA-dictated URI keyword. How concrete vs. theoretical is this idea? Eve's concern is that it sounds so darned useful that it would be better to be solved at a level higher than UMA – that is, this is about mapping OAuth scopes, not an UMA-specific thing. His initial motivation for proposing the issue was "selfish", in his node.js implementation.

AI: Marcelo: Look for scope mapping best practices out there and advise.

It's for AS convenience that we'd let the scope keyword vary. The client is the one that would "suffer" in this case. We're thinking that option 2 (ish) is still the best, if we make the official scope keywords RECOMMENDED, with the knowledge that an AS needs to have its eyes open when it uses anything other than the official keywords. The reasons would be: having infrastructure around existing keywords that it wants to leverage, and being willing to provision information about nonstandard keywords in an UMA context to its clients. Think about the "Google scenario". How would you implement UMA in an existing Android scenario, where you can't change all the existing parameters? It's an ecosystem challenge. If we soften this, it's a bit of an interop challenge, but maybe worth it to encourage the ecosystem.

Is there a Binding Obs concern if we mess with the PAT and AAT definitions? It seems we're clear on this, as the Binding Obs only talk about PATs and AATs generically, without mentioning the scope keywords.

What about the following wording? This gets rid of our "vanity comments" about the form of the URI and its connection to RSR, which his nice to know but not necessary to mess up the spec with.

"It is RECOMMENDED that an AS use the scope keyword "http://docs.kantarainitiative.org/uma/scopes/prot.json" to represent protection API access. A rationale to use a different scope keyword would be that the AS has existing infrastructure surrounding a different OAuth scope keyword that is too difficult to change. An access token with at least a scope that includes protection API access is called a protection API token (PAT) and an entity with this scope is definitionally a resource server."

"It is RECOMMENDED that an AS use the scope keyword "http://docs.kantarainitiative.org/uma/scopes/authz.json" to represent authorization API access. A rationale to use a different scope keyword would be that the AS has existing infrastructure surrounding a different OAuth scope keyword that is too difficult to change. An access token with at least a scope that includes authorization API access is called an authorhization API token (AAT) and an entity with this scope is definitionally a client."

AI: Eve: Can we get https for our namespace names for the scope keyword?

AI: Thomas, Eve: Incorporate scope keyword wording into Core.

92: trust el

Right now we have need_claims as one error code. Mike had proposed need_reauthentication as an additional error code. Eve's proposal is to call the latter elevate_trust, and to allow it in combination with need_claims. Maybe the brute-force method of naming this would be "weak/insufficient AAT"!

Ad hoc meeting on Friday

Mike, Thomas, Sal, Maciej, and Eve are meeting on trust el tomorrow. We'll send an invite!

Attendees

As of 13 Nov 2014 (pre-meeting), quorum is 6 of 11.

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

Non-voting participants:

  • Roland
  • Zhanna
  • Marcelo
  • Adrian
  • Steve - new this time - "Hutch" - SSO service leader for GE
  • Ann

Regrets:

  • Yuriy
  • Ryan

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 Nov 20 (ad hoc meeting 8-9am PT followed by) quorate meeting 9-10am PT
  • No meeting Thu Nov 27 because of Thanksgiving holiday in the US
  • Thu Dec 4 (ad hoc meeting 8-9am PT followed by) quorate meeting 9-10am PT
  • Thu Dec 11 (ad hoc meeting 8-9am PT followed by) quorate meeting 9-10am PT
  • Thu Dec 18 (ad hoc meeting 8-9am PT followed by) quorate meeting 9-10am PT: possible to approve V1.0 drafts for public review in January on this date?
  • No meeting Thu Dec 25 because of Christmas holiday
  • No meeting Thu Jan 1 because of New Year's Day holiday