Quorum was not reached.
Approve minutes of UMA telecon 2016-12-01: tbs
Regarding what to include in V2.0 work, Ishan brings up the RS's need to pass requirements for minimal authorization to the AS. This seems to be the only addition to Eve's proposed list so far for our final V2.0 work. There's support for seeking a set of WG drafts.
Set math: In the question of discretion applied by the RS during its permission request compared to discretion applied by the client during its initial access attempt: What's the motivation of the client? What's the motivation of the RS? Justin has proposed wording in the past that recommends requesting enough permissions for the request to succeed, which softens the previous requirement. Eve and Cigdem discussed the notion that this seems like "bad faith", since the (100% untrusted) client can only communicate one thing at this point: "I want resource X with Y scope" (or rather, some kind of resource among some set XX with YY scope). Eve notes that XACML expects the PEP to transmit a faithful representation of the application's access request to the PDP as an authorization request.
What are use cases for the RS to reduce the permission request vs. adding permissions and/or scopes? Should the RS be completely dumb and send no scopes at all when it requests permission? If it didn't do this, then suddenly the client's pre-registration for some scopes A, B, C and its potential dynamic addition of scopes X, Y at RPT request time become a lot more "normative".
Reminder: A "permission" is "Authorized access to a particular resource with one or more scopes." Now it's possible to request more than one permission on behalf of the client.
(The formal call ended and Robert and Eve continued discussing.)
Different APIs design their resource boundaries and scopes differently, so perhaps it's not a good idea to discriminate between what an RS can do with one vs. the other. Adrian had suggested earlier that it's good advice to say that the client should ask for as few scopes as possible, for least privilege reasons. The same is likely true for the RS requesting permissions. But is less than what the client asked for a case of least privilege?
Can we park the notion of changing things drastically for now (e.g. removing the RS's current capability of requesting scopes on permissions) and come back around to it?
What about this notion of equitable risk and responsibility distribution?
The client, representing some RqP, which are initially 100% untrusted and seek partial trust at maximum:
The RS, which outsources resource protection to the AS but has the right to apply "edge protection" (the "Adrian clause" but strengthened to apply to the beginning of the chain):
The AS, which is accountable to the resource owner and RS for resource protection:
AI: Eve: Send out note with revised set math proposal.
AI: Eve: Publish rev 10 and rev 03 for people's holiday reading pleasure.
As of 20 Dec 2016, quorum is 6 of 10. (Domenico, Sal, Nagesh, Andi, Robert, Maciej, Eve, Mike, Cigdem, Sarah)
Non-voting participants:
Regrets: