Attending: Eve, Andi, Thomas, Domenico, Mike, Sal, Maciej; Justin by back channel (thanks to all!) Non-editorial issues that have tentative solutions: https://github.com/KantaraInitiative/wg-uma/issues/206 We have rough consensus that one base64url encoding is enough! Anyone who thought otherwise would need to go and fix their V1.0 implementation. https://github.com/KantaraInitiative/wg-uma/issues/210 Removed the STRONGLY from RECOMMENDED — okay. Editorial issues with non-obvious solutions: https://github.com/KantaraInitiative/wg-uma/issues/144 The changes would, we feel, convince a quick reader used to OAuth spec reading that this redirection URI is something distinct! https://github.com/KantaraInitiative/wg-uma/issues/194 Discussion: Is it proper to REQUIRE default-deny? Would adding “registered” to “resource set” sufficiently tweak Justin’s wording? Since saying anything about default-deny is perpetuating a certain trust model, and doesn’t tackle technical interop. However, in a wide ecosystem use case, Alice will tend to expect default-deny, and would be very disappointed if default-allow were the behavior. So maybe this comes down to our “…all parties need to document expected behaviors” language. Mike can see some fairly likely cases of default-permit in his environment. We do want to be sure it’s a conscious decision of the deployment and not a result of poor implementation. We concluded that default-deny on the AS side really does need to be required to give UMA as many teeth as possible. Do we want to give this one example of a corner case? We have to assume there are others. Let’s shunt the entire discussion that is implementation-specific to the UIG. “The authorization server MUST use a default-deny authorization assessment model in adding authorization data to RPTs, that is, “everything that is not expressly allowed is forbidden” for resource sets that resource servers have registered. Exercise caution in implementing default-deny because corner cases can inadvertently result in default-permit behavior; see [UMA-Impl] for further discussion.” Justin would like to add the specific corner case back. Would this work, then? “The authorization server MUST use a default-deny authorization assessment model in adding authorization data to RPTs, that is, “everything that is not expressly allowed is forbidden” for resource sets that resource servers have registered. Exercise caution in implementing default-deny because corner cases can inadvertently result in default-permit behavior. For example, it is insufficient simply to assume that all resource sets have some non-zero set of claims required for access, and then accept an empty set of supplied claims as sufficient for access. See [UMA-Impl] for further discussion.” AI: Eve: Put placeholder in UIG for this discussion. Relatedly (slightly distantly), Andi notes that Section 2 says that the RS (not the AS) “MUST” limit access once the resource set has been put under protection (that is, registered). But in our new Sec 3.3.3, we have only lowercase “The resource server must not give access in the case of an invalid RPT etc.”. But maybe the latter really should be a “MUST” even though we can’t test for it. New issue: The “must not” in Sec 3.3.3 should be changed to “MUST NOT” to match the MUST in Sec 2. https://github.com/KantaraInitiative/wg-uma/issues/198 Don’t need to discuss XSLT verb rendering. https://github.com/KantaraInitiative/wg-uma/issues/223 Add the registration of “permissions” in the token introspection registry now, because it already exists. https://github.com/KantaraInitiative/wg-uma/issues/219 We should be fine in RSR with the 405 error for all unsupported methods. https://github.com/KantaraInitiative/wg-uma/issues/185 Should the RS be suspicious of the AS with respect to the user_access_policy_uri? Domenico is thinking that the RS had better trust the AS! If it can’t trust that URI, then it can’t trust the RPTs etc. either, and we’re in real trouble. :-) We’ve already required TLS. But what if the AS has gone rogue in this case? Maybe we can say something very brief about the fact that the RS must trust the AS for a lot, including this URI. What is the realistic risk? The RS, trying to do something convenient for the RO, could redirect the RO to a page that has malware in it. If the RS were to check that the URI is fully qualified and matches the known AS host and scheme, that would do a ton to mitigate the risk. At least it would be sending the RO to the same AS that it’s been dealing with all this time. https://github.com/KantaraInitiative/wg-uma/issues/86 We would love to be able to force the AS to faithfully represent elements registered by the RS that are intended for the RO’s user interface. Let’s continue to leave this for the “BL” level, not the “T” level, of specification. No action in the RSR spec for now. Domenico notes that in Italy, the parties are required to sign something. This is truly at the “agreement” level. This may relate to Adrian’s intentions around his new issue #224, and similar follow-on opportunities. There were cases in Italian civil law that relate to this requirement. (We won’t deep-dive into this for now, but #224 is about Accounting for Disclosures, which is similar to Sal’s idea of an “exception notice”. It’s not for a V1.0.1 timeframe, but we’re warm to the idea! And it relates to consent receipts nicely.) https://github.com/KantaraInitiative/wg-uma/issues/205 Since the client in the “one-down” position of having to trust the AS more than the AS trusts the client, the realistic business risk (vs. the “raw” threat) is quite low. Given that, and given the fact that if we don’t require clients to doublecheck the AS’s work they won’t do it :-), should we just keep the current spec wording? Then again, maybe the AS is just broken, and not malicious. Should we add an in-line note that the client SHOULD check that the ticket is the same? In that case, our rationale for having the AS save the client work is pointless. If we force the client to save the state, then the AS doesn’t have to do anything, and there’s nothing to get wrong! It means the client has to do a bit more work, guaranteed, but it was looking like it had to anyway. IOW, if it had to save state to check the AS’s work, which the AS did in order to save the client some work, then the client saved no work… Is there any other rationale at all for the AS returning the ticket? We don’t think so. But taking away a MUST would be backwards-incompatible. So let’s discuss this on Thursday. New issues that gathered overnight: https://github.com/KantaraInitiative/wg-uma/issues/225 Andi’s new issue suggests seating the “presumptively protected resource” note more firmly into the Sec 1.3.1 context. Eve likes it so much that she suggests doing this with each of the instances. Okay, let’s give her an editorial instruction to do so. Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com