You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
dmitrizagidulin
changed the title
Consider IdP to issue Identity Verifiable Credeantial rather than global access token
Consider IdP to issue Identity Verifiable Credential rather than global access token
Jul 20, 2020
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.
The text was updated successfully, but these errors were encountered: