...
- Roll call
- Approve minutes of UMA telecon 2016-10-13, 2016-11-03
- Logistics for upcoming meetings (calendar) and 2016 roadmap check-in
- Next week: WG meeting on Fri Nov 18 at 9am PT after legal call instead of Thu Nov 17
- Week after: no WG or legal meeting due to US holiday
- Work on UMA.next issues – Core is up to 06 and should be up to 07 well before the meeting – 07 – please review changes ahead of time if possible
- The following changes affect syntax:
- Removed config data to declare pat and rpt profiles supported (as agreed last time)
- requesting party claims endpoint --> claims interaction endpoint (language that affects syntax in endpoint config data )
- resource set --> resource (language that affects syntax in endpoint config data and token introspection returned object format)
- New AS-to-client invalid_scope error (because a client can now ask for scopes)
- RPT token profiling has been properly removed now (means token introspection, if used, requires using the permissions structure)
- "Authorization data" flexibility can only be added, not substituted – is this OK?
- Do we need to reconsider the last bullet in Security Considerations Sec 7.1.1 re PoP/HoK?
- Set math: See 9-29 and 10-6, and the email thread – including...
- What scopes should the client ask for, and why? (E.g., least-privilege rationale.) What should the mechanism be for asking for scopes for specific protected resources?
- What permissions should the RS request on behalf of the client, and why?
- pat_grant_types_supported: My proposal was to remove it. Any further discussion?
- claim_token_profiles_supported: My proposal was to keep this profiling mechanism, but clean it up and provide two actual profiles or at least credible examples, say, for OIDC ID tokens and SAML assertions. Discussion?
- uma_profiles_supported: My proposal was to keep this profiling mechanism, but figure out seriously if the extensibility profiles are doing the right job, and include credible examples of extensions and not just extensibility profiles. Discussion?
- Is step-up auth the way it was conceived in UMA1 hunky dory according to the claims collection mechanism in UMA2?
- Is the (client) registration endpoint's name correct according to the naming pattern used in UMA, and also OAuth and OIDC?
- The following changes affect syntax:
- See the latest swimlane
- AOB
...
Roll call
Quorum was reached.
...
We're ON for Thu Nov 10 – regrets from Justin, Andi is unsure.
We need to MOVE our Thu Nov 17 meeting to 9am (usual hour) Fri Nov 18 – regrets from Cigdem, Domenico.
We're NOT MEETING Thu Nov 24 or Fri Nov 25 because of the US Thanksgiving holiday.
Approve minutes
Approve minutes of UMA telecon 2016-10-13: Deferred, 2016-11-03: APPROVED by unanimous consent.
Logistics
We ARE meeting next week, but Friday at 9am PT, not Thursday. That's right after the Legal call.
Work on UMA.next issues
"Authorization process": The definition could potentially be improved by breaking the first sentence into two. The second sentence could focus on risk management. Can we define "trust" formally somehow as managing risk? Do we need "trust elevation" anymore? This is a live thread in email. Is the equation "The RO only authorizes access within their risk appetite/tolerance"? Maybe this is where we could point off to the UMA Legal work because it's a complex equation and the RO isn't the only party with risk and liability. Robert notes that part of decision is how you make a good decision. A technical spec's job isn't to describe all of this, but it could point off to other resources that go into it.
"Authorization process: The process through which the client obtains an RPT from the authorization server in order to access a protected resource. The process has two activities, and these can iterate. One activity is assessing claims and other contextual factors against the resource owner's policy conditions. Another is is collecting claims, which can include both claims pushed from a client and interactively gathered from a requesting party.
Suggestion to Domenico for his new flowchart: Try switching input and actor bands, and adding an actor so there's always two. Let's be sure that it's "technically accurate" as much as possible, assuming developers will take it seriously. Andi suggests it will be used more "generically", so maybe we can use it more at a 50K foot level.
Regarding "token profiling goes poof": Medication/read 22354546 read
Regarding the "*supported" options in the config data: Both Justin's and Cigdem's implementations implement and ignore them! Is there any dissent to pulling pat_profiles_supported and rpt_profiles_supported?
Instructions:
- Sec 3.5.4: "The fifth error response, need_info, begins or continues..."
- Redefine "authorization process" through as two activities/states, and be sure to incorporate "client identity" and any other contextual factors (we used to call this "RqP-independent").
- Undo the "token profiling goes poof" and reconstitute the actual introspection response part; make use of 7662 mandatory.
- Remove pat_profiles_supported and rpt_profiles_supported
AI: Eve: Send separate email threads about all the other "*supported" config data fields and rationales pro and conSyntax changes as listed above are confirmed OK. The new invalid_scope error is OK. We don't have to say "protected resource" all the time, particularly in syntax.
Eve is concerned that not being able to fully replace the permissions structure in the token introspection response is a bridge too far in having removed the token profile scaffolding. OAuth has token profiling. There is a use case for just conveying RqP identity claims for achieving fine-grained authorization at the edge (along with a use case for conveying RqP identity claims on top of permissions). UMA permissions on their own only convey "scope-grained" permissions. Can we reuse the UMA profiling capability to allow third parties to replace the permissions structure if they need to? It's already possible to create these (so Gluu could consider doing this).
We have some outstanding questions around the token profiling question and the permissions structure. Eve will send an email outlining these with all the options she can think of and possibly making some proposals so we can decide by next week. (She'll include the Sec Consid point from 7.1.1.)
AI: Eve: Email about token profiling, as above.
Instructions for Core rev 08:
- Sec 3.4: The RS has the option of using cached RPT status results, so include this in the options (has swimlane implications?). This is also an AS TTL strategy thing (including revocation and disconnected RS scenarios, e.g. IoT scenarios), which we should comment on if we haven't already.
- Add companion security considerations around TTL for RPTs and permissions, since you need to measure risk and risk appetite based on the RS, the resource itself, and even the nature of the policy conditions etc. Without active revocation infrastructure, the risks are higher.
- pat_grant_types_supported: Goes away.
Attendees
As of 3 Oct 2016, quorum is 6 of 11. (Domenico, Sal, Nagesh, Andi, Robert, Maciej, Eve, Jeffrey, Mike, Cigdem, Sarah)
- Domenico
- Sal
- NageshAndi
- Robert
- MaciejEveEve
- Mike
- Cigdem
- Sarah
Non-voting participants:
- Justin
- FrancoisFrancois
- James
- Scott F
- Kathleen
...
- Arlene
- Jin
- Colin
- John W
Regrets:
- Andi