Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Current »

UMA telecon 2017-07-13

Date and Time

Agenda

  • Roll call

  • Approve minutes of UMA telecon 2017-06-29 

  • Public Comment/IPR Review period concluded on July 12 at 11:59 UTC
  • UMA V2.0 work:
    • All GitHub issues for V2.0/Grant swimlane, FedAuthz swimlane/Release Notes/UIG/Wikipedia
    • Issues #326-#330 have been implemented
    • Please check out draft solution for #328: how client-contributed scopes are mapped to resources during authorization assessment
    • Let's briefly discuss #334: the IANA registration request for the JWT permissions claim and its constituent parts
    • Several of the items in #337 are worth discussing
    • If you want to review and weigh in on the other public-comment-period issues, please do it before the call
    • Release notes are getting more fleshed out; review (and contributions) welcome
  • Finalizing the specs
    • When will we be ready to vote on progressing specs to the LC and then to All-Member Ballot?
  • UMA2 logo ideas
  • AOB

Minutes

Roll call

Quorum was not reached.

Approve minutes

Approve minutes of UMA telecon 2017-06-29: Deferred.

UMA 2.0 work

#328: how client-contributed scopes are mapped to resources during authorization assessment: Eve's first iteration was "Treat each scope in (ClientRequested ∩ ClientRegistered) as applying to all matching resource-bound scopes in PermissionTicket." She's thinking that it would be more accurate to say something like "...all scopes associated with resources appearing in PermissionTicket", and then we could add ", with the scope matching performed as described in Section 6.2.1 of [RFC3986] (Simple String Comparison)."

Let's give this wording a try in context (published draft) and see if it makes sense there.

#334: the IANA registration request for the JWT permissions claim and its constituent parts: Justin suggests that we need to have a paragraph talking about the security and privacy considerations of putting this information into the token vs. an introspection response, because the token is exposed to the client. The permissions claim and its sub-claims give tools directly usable by those who want to use the "local validation of self-contained tokens" path.

Furthermore, the sentence in the Introduction is too modest: "Further, with the use of token introspection, authorization grants can increase and decrease at the level of individual resources and scopes." We can get rid of the italicized stuff.

We have the following options:

  1. Remove our registration request.
  2. Specify how to "validate a self-contained token locally" in a separate document, with security and privacy considerations.

Do we have enough real-world implementation experience to know what the considerations are? What is the sensitive information in the token? In a typical OAuth access token, there are typically scopes. In our permissions structure, there are resource IDs, scopes, expirations, etc. Also, there may be permissions that cross RS's. Is this sensitive wrt an individual RS too? Maybe it's trivial for an RPT that doesn't cross RS's, but not otherwise. Maybe it requires encryption per array object or something. Any considerations section would have to explicitly push responsibility onto the implementer.

Eve speaks in favor of option 2. Kathleen notes that it's good to keep solving this properly on the roadmap. Sal agrees. James agrees. We have consensus.

Editorial actions: Remove the IANA request for JWT claims, and edit the Intro sentence.

Finalizing the specs

Sample motion when the time comes: "Approve UMA 2.0 Grant and FedAuthz revs 06 as amended by the instructions of UMA telecon 2017-xx-xx as Draft Recommendations and forward them to the Kantara Leadership Council to request certification for an All-Member Ballot as Recommendations."

UMA logo ideas

tbs

Attendees

As of 7 Mar 2017, quorum is 4 of 7. (Domenico, Sal, Andi, Maciej, Eve, Mike, Cigdem)

  1. Sal
  2. Maciej
  3. Eve

Non-voting participants:

  • Justin
  • Kathleen
  • Bjorn
  • Scott F
  • John W
  • Jin
  • James
  • Robert

Regrets:

  • Domenico

 

  • No labels