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
Approve minutes since UMA telecon 2022-06-30
FAPI and UMA next steps. OAuth compatible UMA version
AOB
NOTE: As of October 26, 2020, quorum is 5 of 8. (Michael, Domenico, Peter, Sal, Thomas, Alec, Eve, Steve)
Voting:
Alec
Sal
Non-voting participants:
Chris
Regrets:
Steve
Approve minutes of UMA telecon 2022-08-11, UMA telecon 2022-08-25, UMA telecon 2022-09-08 , UMA telecon 2022-09-15 , UMA telecon 2022-09-22 , UMA telecon 2022-09-29 , UMA telecon 2022-10-06 , UMA telecon 2022-10-13 , UMA telecon 2022-10-20
Deferred - no quorum
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:
client requests resource, gets www-authenticate with scope string
client requests token, gets need_info with options (push or gather) and scope string (maybe changed)
client requests token with claims, gets RPT (or needs_info again?)
client requests resource with RPT
Gathering Use Case
client requests resource, gets www-authenticate with scope string
client requests token, gets need_info with options (push or gather) and scope string (maybe changed)
client does authorization code flow with AS (/authorize → /callback)
client requests token with code, gets RPT
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