Scope of Current Extension Effort

[aleclaws]

We've been have a lot of discussion around the proposed/possible extensions. This issue attempts to list those and shortly define what they are trying to accomplish

1. Policy Manager "The AS exposes an API to allow the RO to manage policy over registered resources" (there is an editors draft already)
2. Relationship Manager (name?) "The RS exposes and API to allow the RO to manage resource registration/policy at an AS" (parts of this exist on the mailing list)
3. Trusted Claims(Cascading AS in the diagram) "The AS delegates authentication (and maybe claims gathering) to a second AS (UMA or OIDC?)"
4. Fallback AS "During Resource Registration, The RO can direct the RS to one (or more?) AS"

I've also includes some other possible extensions
5. Resource Definitions "The AS defines general resource registration so that specific RO resources may not need explicit registration, enables AS-first request flows"
6. VC/DID claims profiles "UMA loosly defines IDToken based claims pushing, is there value in a VC claims profile"

For the above the questions/consideration:

• keep independent or make sense to merge some of this? (how many extensions are there?)
• what are the use-cases that support these extensions efforts?
• whats the overlap/intersection with other WGs (HEART,FAPI,GNAP,UDAP?)

[xmlgrrl]

I've made my best attempt to try and interpret our opportunities to address new use cases (for a new presentation), and thought I'd provide the attempt here.

[aleclaws]

Option 3 is the issue: #260
Option 4 is an implementation consideration, not for specification

[xmlgrrl]

Yes, as reconfirmed in UMA telecon 2020-10-01.