DKIM signed Delegation of Authority Email stored in a jwt/token claim
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
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
+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
Hi Eve, Hi Adrian, Thanks for pointing me in the right direction. I finally identified a security triumvirate – the arrangement of Identity Provider, UMA Provider and Claims Provider. Now I know that we need a decentralized Claims Provider system to create a wide UMA-compliant ecosystem. I designed a decentralized OAuth2-based Claims Provider system, which uses verifiable DKIM signatures without user involvement. This is related to UMA, so when the first draft is ready may I post it here? Regards -Igor On Thu, Apr 8, 2021 at 4:37 PM Adrian Gropper <agropper@healthurl.com> wrote:
+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
Works for me. :) Eve Maler | mobile +1 425 345 6756
On Apr 13, 2021, at 2:07 PM, Igor Zboran <izboran@gmail.com> wrote:
Hi Eve, Hi Adrian, Thanks for pointing me in the right direction. I finally identified a security triumvirate – the arrangement of Identity Provider, UMA Provider and Claims Provider. Now I know that we need a decentralized Claims Provider system to create a wide UMA-compliant ecosystem.
I designed a decentralized OAuth2-based Claims Provider system, which uses verifiable DKIM signatures without user involvement. This is related to UMA, so when the first draft is ready may I post it here?
Regards -Igor
On Thu, Apr 8, 2021 at 4:37 PM Adrian Gropper <agropper@healthurl.com> wrote: +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
participants (3)
-
Adrian Gropper -
Eve Maler -
Igor Zboran