Quorum was reached.
Approve minutes of UMA telecon 2017-07-20: Deferred.
337a: RFC 7519 just says these three claims are optional. (Right now we are being inspired by the claims and not registering for JWT claims specifically.) Cigdem, along with Justin, argued for removal of an explicit statement (as we still do for exp) saying exactly what it means when the permission-level parameter is absent. If we don't say, then Eve's interpretation is that "the AS isn't claiming anything" about that semantic. It's up to the AS, presumably, what it means, but that's part of its prerogative. Mike wonders what AS wouldn't include a value. We already say what happens if it has a value at variance with the permission-level value. If we take away the exp "no-value" statement of "never", then the AS has the incentive to do the right thing in any case (vs, say, deciding on a super-secret nbf value of Jan 5, 2020 at 03:59:53). That doesn't help anyone! Consensus to remove the exp statement.
337c/d: The suggestion is to 1) make it a MUST for the AS to require public clients to register claims redirection URIs (Grant Sec something), with the rationales that it matches 6749 Sec 3.1.2.2 and it's more secure (we have consensus on this), and 2) to request registration of a metadata field to the OAuth dynamic client registration metadata registry (Grant Sec 2). Would we also want to request registration of a metadaata field to the OIDC dynamic client registration metadata registry, or is it all the same? It appears to be the former. We have consensus that adding the metadata field is sensible too, with the rationale that it gives a concrete way to register the URI and removes friction from interoperable dynamic registration. But we do want to check with Justin (who is the designated expert for this metadata registry). This would require a new section or subsection in Grant akin to the AS metadata section.
AI: Eve: Ping Justin re claims_redirect_uri metadata field.
337f: We discussed Cigdem's proposed example, which starts with a resource request of album and a permission ticket containing photo1 and photo2, which adds a level of trickiness that may be distracting for the point at hand. We think the calculation seems pretty simple regardless; the AS is "dumb" with respect to resources, even though scopes are resource-bound, so it does the calculatiion the same way regardless. Only the RS knows resource relationships. The AS does an expansive scope match on the client's behalf because the client is "dumb" with respect to resources.
AI: Eve (hopefully with Cigdem's input): Come up with a hybrid example that has two resources in the permission ticket.
Deferred.
As of 7 Mar 2017, quorum is 4 of 7. (Domenico, Sal, Andi, Maciej, Eve, Mike, Cigdem)
Non-voting participants: