Grant rev 06 https://docs.kantarainitiative.org/uma/ed/oauth-uma-grant-2.0-06.html and FedAuthz rev 06 https://docs.kantarainitiative.org/uma/ed/oauth-uma-federated-authz-2.0-06.h... are now up! These contain implementations of all the agreed-to and purely editorial solutions to Public Comment (and a couple of minor post-Public Comment) issues to date. Issues #335, #337, and #339 (and various sub-issues) are worth discussing, and I'd like to do that in tomorrow's call. I've put some thoughts into the threads already to kick things off. Please feel free to respond in this thread prior to the call! In approximate order of importance: 1. 337a https://github.com/KantaraInitiative/wg-uma/issues/337: iat and nbf in the token introspection response don't say what should happen if the permission-level value is missing, while exp does https://docs.kantarainitiative.org/uma/ed/oauth-uma-federated-authz-2.0-06.h.... We started discussing this last week http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-07-20 and didn't quite come to a conclusion (it was shaping up to be "remove what we say even in exp"). Can we decide this quickly? 2. 337c https://github.com/KantaraInitiative/wg-uma/issues/337/d: It's been proposed that we register a client metadata element in the "OAuth Dynamic Client Registration Metadata Registry" so that claims_redirect_uri can be formally dynamically registered, and also to make it REQUIRED for public clients to register these URIs. Thoughts? 3. 337f https://github.com/KantaraInitiative/wg-uma/issues/337: This was a request for more set math clarification, specifically around what happens if there are multiple permissions in the permission request. To me it was obvious that "it all works the same", but skepticism was expressed. :-) Please see my example in the GitHub thread. Can we riff off that as a solution? 4. 337b https://github.com/KantaraInitiative/wg-uma/issues/337: Is my suggestion a good one to add a statement that the client MAY be confidential or public, for clarification? 5. 339 https://github.com/KantaraInitiative/wg-uma/issues/339: It seems our description of object vs array in permission requests came out somewhat ambiguous. We have an opportunity here. Should it be possible for RS's to choose which way they request a single permission, with the AS picking up the slack? 6. 335c/d https://github.com/KantaraInitiative/wg-uma/issues/335: It was suggested to break out Grant Fig 1 https://docs.kantarainitiative.org/uma/ed/oauth-uma-grant-2.0-06.html#high-l... into an RO vs RqP flow to show asynchronicity, and then also the latter to be broken out into claims push and interactive claims gathering flows. Theoretically I liked the ideas, but trying to implement them and getting some feedback, I didn't anymore. I think devs will prefer a single summary diagram with all the entities. Thoughts? 7. 337g https://github.com/KantaraInitiative/wg-uma/issues/337: I'm recommending no change regarding further protecting permission tickets as being single-use. Sound good? *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl