This issue relates to ensuring extensibility with AuthZ. Having IdP to issue signed JWT as DPoP-bound access tokens, which client uses with any number of resource servers, can limit possibility for parties other than IdP to stay responsible for authorization.
Previous Draft by @dmitrizagidulin had IdP issue Identity Verifiable Credential which client would present to RS. In authorization panel we discussed possibility where client would need to present Capability Credential as well, which could even be obtained from party different than IdP. I see pattern where specialized party issues specific credential to the client as elegant and providing solid foundation for extensibility.
UMA2.0 has aspect of Interactive Claims-Gathering. In Solid Identity VC, Capability VC, Membership VC etc. could act as standard claims which client could use while requesting access. I think we should take into consideration what @zenomt proposes #12 . In a way I read the general idea behind it, client could go through claims (credentials) gathering step with RS associated AS and obtain access_token to use with that RS. Having IdP to issue global access tokens would close that possibility, or even mentioned possibility of obtaining additional credentials from other parties. IdP issuing Identityt Verifiable Credential seems like a clear way of encapsulating its responsibility without limiting other parties in taking on their responsibilities.
This issue relates to ensuring extensibility with AuthZ. Having IdP to issue signed JWT as DPoP-bound access tokens, which client uses with any number of resource servers, can limit possibility for parties other than IdP to stay responsible for authorization.
Previous Draft by @dmitrizagidulin had IdP issue Identity Verifiable Credential which client would present to RS. In authorization panel we discussed possibility where client would need to present Capability Credential as well, which could even be obtained from party different than IdP. I see pattern where specialized party issues specific credential to the client as elegant and providing solid foundation for extensibility.
UMA2.0 has aspect of Interactive Claims-Gathering. In Solid Identity VC, Capability VC, Membership VC etc. could act as standard claims which client could use while requesting access. I think we should take into consideration what @zenomt proposes #12 . In a way I read the general idea behind it, client could go through claims (credentials) gathering step with RS associated AS and obtain access_token to use with that RS. Having IdP to issue global access tokens would close that possibility, or even mentioned possibility of obtaining additional credentials from other parties. IdP issuing Identityt Verifiable Credential seems like a clear way of encapsulating its responsibility without limiting other parties in taking on their responsibilities.