+1 Eve. There's no federation needed when the resource owner and the AS are effectively the same entity. The RO is their own federation / root of trust. Hence the name HIE of One. Once you adopt that framing a lot of things get clearer. As with public blockchains (BTC, ETH), building on the HIE of One model does not eliminate the need for governance across the various entities. It just shifts the BLT priorities to where the Technical foundation is removed from governance and business constraints and they need to be added later, based on context. Adrian On Thu, Apr 8, 2021 at 9:36 AM Eve Maler <eve@xmlgrrl.com> wrote:
Hi Igor, UMA doesn’t prevent the choice of using independent “sources of identity” for the RO and RqP. Communication about identity is technically restricted only to claims collection, for satisfying policy conditions. But of course a typical deployment topology is for these two entities to share an IdP, which is one species of what we’ve been calling a “narrow ecosystem”. Even in wider ecosystems, policies would more typically be stated in terms of unique identities vs. grab-bags of non-unique (verifiable?!) claims.
But some here have hooked up their UMA implementations to decentralized identity sources. Adrian’s HIE of One can use uPort on (at least?) the RqP side, so claims are fed to the AS in that form.
Eve Maler | mobile +1 425 345 6756
On Apr 8, 2021, at 8:12 AM, Igor Zboran <izboran@gmail.com> wrote:
Hi UMAnitarians,
I once mistakenly thought that a decentralized system with the UMA protocol could be built in combination with the OIDC authentication system. Of course, this is not possible because the OIDC provider has to be common to both the RO and the RqP, or at least has to be federated / centralized in some way. If the RO and RqP can use mutually independent OIDC providers it will be possible to build decentralized systems such as AEMS, chat or file sharing services. So I tried to adapt the OAuth2 Authorization Code Grant for UMA Authorization Code Grant. I completely lost my thread on this point. My apologies for any inconvenience this non-umanitarian approach may have caused.
After some thought and experimentation, I discarded the previous concept and replaced it with another one – this time UMA-compliant. At the core of this new idea is the use of a DKIM signed Delegation Of Authority Email stored in a jwt/token claim. I need some time to refine this idea, hope it turns out well this time.
Regards -Igor _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org https://kantarainitiative.org/mailman/listinfo/wg-uma
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org https://kantarainitiative.org/mailman/listinfo/wg-uma