Page Comparison

...

• 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

Quorum: No

Meeting Minutes

...

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

Policy Descriptions

AOB

Potential Future Work Items / Meeting Topics

...