FYI, I made a boneheaded error where it says "Eve speaks in favor of option
2." It should have said "1". :-) The editorial instructions were correct,
though. I've made the correction online.
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
On Thu, Jul 13, 2017 at 10:08 AM, Eve Maler
http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-07-13 MinutesRoll call
Quorum was not reached. Approve minutes
Approve minutes of UMA telecon 2017-06-29 http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-06-29: Deferred. UMA 2.0 work
*#328 https://github.com/KantaraInitiative/wg-uma/issues/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 https://github.com/KantaraInitiative/wg-uma/issues/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
*Eve Maler*Cell +1 425.345.6756 <(425)%20345-6756> | Skype: xmlgrrl | Twitter: @xmlgrrl