Draft minutes from UMA telecon 2022-10-27

https://kantara.atlassian.net/wiki/spaces/uma/pages/97353729/UMA+telecon+202... UMA telecon 2022-10-27Date and Time - Primary-week Thursdays 06:30am PT; Secondary-week Thursdays 10:00am PT - Screenshare and dial-in: https://zoom.us/j/99487814311?pwd=dTAvZi9uN0ZmeXJReWRrc1Zycm5KZz09 - United States: +1 346 248 7799, Access Code: 994 8781 4311 - See UMA calendar for additional details: https://kantara.atlassian.net/wiki/spaces/uma/pages/4857518/Calendar <https://kantara.atlassian.net/wiki/spaces/uma/pages/4857518> Agenda - Approve minutes since UMA telecon 2022-06-30 <https://kantara.atlassian.net/wiki/spaces/uma/pages/14352423> - FAPI and UMA next steps. OAuth compatible UMA version - AOB Attendees - NOTE: As of October 26, 2020, quorum <http://kantarainitiative.org/confluence/display/uma/Participant+Roster> is 5 of 8. (Michael, Domenico, Peter, Sal, Thomas, Alec, Eve, Steve) - Voting: - Alec - Sal - Non-voting participants: - Chris - Regrets: - Steve Quorum: No Meeting Minutes Approve previous meeting minutes - Approve minutes of UMA telecon 2022-08-11 <https://kantara.atlassian.net/wiki/spaces/uma/pages/39124993>, UMA telecon 2022-08-25 <https://kantara.atlassian.net/wiki/spaces/uma/pages/45875201>, UMA telecon 2022-09-08 <https://kantara.atlassian.net/wiki/spaces/uma/pages/56459265> , UMA telecon 2022-09-15 <https://kantara.atlassian.net/wiki/spaces/uma/pages/62029825> , UMA telecon 2022-09-22 <https://kantara.atlassian.net/wiki/spaces/uma/pages/62980097> , UMA telecon 2022-09-29 <https://kantara.atlassian.net/wiki/spaces/uma/pages/74055681> , UMA telecon 2022-10-06 <https://kantara.atlassian.net/wiki/spaces/uma/pages/79101953> , UMA telecon 2022-10-13 <https://kantara.atlassian.net/wiki/spaces/uma/pages/85721089> , UMA telecon 2022-10-20 <https://kantara.atlassian.net/wiki/spaces/uma/pages/91193345> - Deferred - no quorum Topics FAPI and UMA next steps - OAuth compatible UMA version https://fapi.openid.net/ UMA isn’t just additional to OAuth, but also changes defined functionality: - request/response names (scope / ticket, claims_redirect_uri) → creates need to change oauth libraries or create uma custom tech stacks - well defines AuthZ steps, the multi-step possibilities of ticket/correlation handles makes the flows extremely variable (eg can have 3 token calls, followed by claims gathering). To address those concerns, is it possible to create an intermediary spec that is OAuth compliant? OAuth <> *OAuth compliant UMA* <> Full UMA What’s the minimum viable UMA features set: needs_info, RqP role, claims_pushing, RS first flows What could be removed: PCT, request_submitted, *ticket(!)* Token endpoint, still need a new grant type for claims pushing, maybe renamed from uma-ticket to uma or uma-claims. There is no OAuth grant_type for this today - pro: OAuth BW compatibility - pro: maintain RqP separation, needs_info and claims pushing - con: no multi-step authZ (no ticket as correlation handle) - no pushing claims in multiple steps, no pushing claims + interactive gathering - no need/ less value of PCT - could be addressed by unique transactional scope created by AS? some challenges here.. - possible: remove PCT and request_submitted. Features that are less 'used' even by UMA impls? Reduce scope for reader/implementer - neutral: client can stay ignorant of authZ details since its’ returned the scopes to ask for Pushed Claims Case: 1. client requests resource, gets www-authenticate with scope string 2. client requests token, gets need_info with options (push or gather) and scope string (maybe changed) 3. client requests token with claims, gets RPT (or needs_info again?) 4. client requests resource with RPT Gathering Use Case 1. client requests resource, gets www-authenticate with scope string 2. client requests token, gets need_info with options (push or gather) and scope string (maybe changed) 3. client does authorization code flow with AS (/authorize → /callback) 4. client requests token with code, gets RPT 5. client requests resource with RPT Next steps: - Can we see this side by side with oauth - what are the implications to UMA Fedz - Draft UMA-lite spec text
participants (1)
-
Alec Laws