Quorum was reached.
Approve minutes of UMA telecon 2017-02-23: APPROVED.
Eve can do anytime Monday morning PT. Mike and Justin can as well. Let's make it 8:30-10am PT.
AI: Eve: Put the ad hoc on the calendar.
#277: Conceptually, should we make it possible to register multiple resources at once so as to align the capabilities of registering resources and requesting permissions? Otherwise, an RS might have to register three resources in three calls, and then it would get to request permissions "in bulk" once. Per the discussion about resource registration timing in the UIG, in some use cases, the two steps could be very close together. Gluu actually has already implemented bulk registration as a kind of extension, based on the logic of calling them "resource sets" and there being a many:many relationship between resources and policies through scopes.
George points out that the answer really depends on the use case (a la the UIG). For use cases for #1, where the RS is using wildcards the AS doesn't understand, the RS only registers one resource. For use cases for #2, for a Share button there would be only one resource, but for "relationship-driven graph DB sharing" you could have many many resources. For use cases for #3, it might be a finite low-ish number as we anticipate for FHIR. (E.g., each of the use cases in the GDoc imagining RS permission requests for various APIs gives us a way of imagining finite numbers.)
Given that there could be a lot of RReg API work in cases of "what do we do about rollback if some of the bulk registrations don't work but the rest do?", acknowledge the fact that we've left this unoptimized for now, and give ourselves room to add a batch registration endpoint later.
This is an explicit question we could ask during "last call".
AI: Eve: Start a "last call" question list, including the RReg optimization question and the RReg applicability to OAuth and OIDC question. Add this to the UIG.
AI: Eve: Extend the discussion in the UIG of resource registration timing with the above discussion.
#271 and #272: First of all, we need some security considerations around sanitizing all such text (including the existing human-readable text fields), to ensure there's no active scripting in there. We don't currently have that; we only have it for the icon URIs. What does sanitizing mean? It seems ill-defined in the case of natural-language text being displayed.
AI: Eve: Insert language about "sanitizing", pointing to a non-normative example of such action, such as this (from George); Jin points to this as the vuln.
Next challenge: Resource description documents have an RO context, and the RS is basically responsible for doing any L10N before the human-readable strings get to the AS; not our problem for I18N. But the human-readable strings involved in a scope description do have this problem. Do we want to suggest the OIDC-style "hash trick"? We discussed this in the email around #269. Justin likes the normative language in RFC 7591better. George suggests making this being a "developer-readable" mechanism only.
We agree that it's the right pattern to have both the name and the description fields for both. We prefer the dynamic client registration definition of the I18N/L10N mechanism, and will point to its mechanism by reference for both the resource and scope name and description fields. 7591 already covers the circumstance of "any human-facing fields", so we don't have to add that.
#276: What's already in the spec shows that this can be closed.
#269: Note that OIDC's discovery doc already has scopes_supported, which, if filled with URIs, enables static discovery of an UMA scope description document if you want it to. So a closed ecosystem of the sort James mentioned in the #269 thread could be handled this way. (And in the decision just above, we already have an I18N mechanism.)
So option 4 from the email thread is the current best option on the table: "Change even more to say that scope description metadata is possible to standardize, publicize, and reference through a URI, but there is no expectation of run-time resolution by the AS; rather any customization of policy condition setting interfaces with respect to scopes is, um, out of scope." So far, most implementations are only handling the simple strings, while one implementation is drawing the relevant text at run time. Since there's a way to do it statically but machine-readably, let's drop the MUST. Clear consensus on this.
#273: There is a shallow way to treat this issue, and a deep way, and maybe a medium way.
Eve and Mike aren't crazy about #4 because it's invasive and really lengthens Core, and it isn't proven yet that RReg as it stands isn't relevant to all three of the technologies or others yet to come.
AI: Eve: Send out dedicated emails about #273 and #31.
As of 19 Jan 2017 (post-meeting), quorum is 5 of 8. (Domenico, Sal, Andi, Maciej, Eve, Mike, Cigdem, Sarah)
Non-voting participants:
Regrets: