https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-09-19 MinutesRoll call Quorum was reached. Approve minutes - - Approve minutes of UMA telecon 2019-08-08 https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-08-08 , 2019-09-05 https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-09-05 MOTION: Approved. XYZ use cases UMA-related use cases collected last time: - *AI:* Eve: Alice-to-Alice sharing (RO-to-self) - In Justin's description https://mailarchive.ietf.org/arch/msg/oauth/v8TdkruCzwH43FMKS598IC2Sheo of the "multiple parties" use case (which is generally the "UMA use case"), he says "UMA extends this to allowing the Requesting Party to be the one using the client, but it generally doesn’t collapse cleanly into the cases where the RO *is* the party using the client since the claims gathering endpoint and the authorization endpoint aren’t quite the same in concept." - However, this doesn't seem right. What should happen is that RqP (that we happen to know, if we are outside the system, observing, that the policy happens to match Alice-again, is the RO) should be taken not to the authorization endpoint but to the claims interaction endpoint. We confirmed that Gluu's implementation, e.g., does it this way. If there is no policy whatsoever in place, then Alice-the-RqP's client might get, say, request_denied and Alice-the-RO might be given the opportunity to create a policy for the first time that *happens* to match herself. - *AI:* Eve: Reach out to Justin to discuss this use case. - *AI:* Eve: Proactive Alice-to-org sharing (RO-to-client developer, so to speak) - *AI:* Peter: Bob is assured to a certain level that Alice is who she says she is (strong Alice-to-AS binding or "CIBA-like") - Transactional and long-term management of sharing of preferences with service providers Eve had some one-on-one discussion with Justin about the intended design center of XYZ, transactions, and guessing what might be the impact on client ecosystems (e.g. reducing friction or adding friction). The big security impact is intended to be narrowing the scope and moving from bearer to sender-constrained tokens, and doing it in a simpler and consolidated way, hopefully easier for everyone, including clients. As we push the boundaries of what OAuth was intended to do, it makes sense to refactor. The rise of the Janrains and Gigyas back in the day was a response to OAuth complexity. Anything that sits in the middle that says "redirect to us" – a central session management service – is even simpler. What makes it complicated is making the client smart enough to know what profile to enact. Each profile (e.g., FAPI) has different security characteristics. A key part of the complexity is the number of specs and resulting amount of knowledge you need. This sounds a bit like the Active Directory PAC (privileged attribute certificates) structure history. Do we need one gigantic token that covers all the complexity as the solution? The way to punch out of this paper bag is to get really familiar with all the use cases and truly get experience with the solutions. - Semantics for transactional-level permissions (scope and/or resource) - This one looks covered by Justin's writeup. - *AI:* Cigdem: Disconnected RS when a "handle" for the RS can't be gotten right away - XYZ has a strawman for C-to-RS - ACE has a disconnected RS flow and doesn't use a permission ticket – the ACE model also has a "client AS" where the client itself might be offline - Liberty had a model where an offline IdP could give the client a delegatable token that would allow the client (using the PAOS profile – reverse SOAP...) to mint tokens in a disconnected manner – Thomas notes that these would be considered forwardable/proxyable tickets ACE for a time had a use case for an RS could be a proxy that could help reach an AS for a client if either the RS or client had difficulties getting online, but Hannes did a security analysis http://st.fbk.eu/sites/st.fbk.eu/files/osw2018-ace.pdf that seemed to cross that option off the list. Our model would seem to make this highly unlikely to be practical if the AS and RS were loosely coupled. If you have an entirely sender-constrained-token model such that the RS is just an SSL tunnel between the client and AS, only then would it be safe for the RS to proxy token issuance messages. But it seems the paper concludes this is just unwise at all. The last set of use cases to be documented aren't UMA conundrums at all but simply use cases UMA actually solves over and above OAuth today: - *AI:* Eve: Existing UMA use cases that are described in our Grant and FedAuthz spec introductions Next time, let's review people's use case write-ups, including Justin's existing ones. Nominations for chair and vice-chair Let's take up the actual ballot next week. Thursday meeting series Thoughts on making this a biweekly series in Q4? Some sentiment "for". Let's decide next week. Attendees As of 16 Jul 2019, quorum https://kantarainitiative.org/confluence/display/uma/Participant+Roster is 5 of 9. (Domenico, Peter, Sal, Thomas, Andi, Maciej, Eve, Mike, Cigdem) 1. Domenico 2. Peter 3. Maciej 4. Eve 5. Cigdem Non-voting participants: - George - Vlad - Thomas - Colin Regrets: - Andi - Mike *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl