[Openid-specs-ab] OpenID Connect Federation draft 09 ready for your review

Roland Hedberg roland at catalogix.se
Sat Nov 2 10:35:01 UTC 2019

> On 2 Nov 2019, at 05:07, Stuart Low via Openid-specs-ab <openid-specs-ab at lists.openid.net> wrote:
> I've been following this interest the OIDC Federation draft and found myself asking how this specification relates to the work OBIE and "open banking" communities have done with SSA's?
Quite independent! 
> Personally I like where Federation is headed but OBIE (and soon Australia) have gone down the SSA path. 
My sentiments too.
> Firstly, I might be way off the mark on the below so apologies in advance. 
> There seems to be two patterns for similar outcomes (verifying and maintaining an RPs trust using a third party).
> As I understand it, Fed is a continually revalidated X509 trust chain (with mutually designated parties) with client_id key's being kept alive via OP's established X509 trust lines which are used to revalidate RPs. These RPs may also be OPs in the other direction. Additionally, the revalidation occurs between two OPs, one that the RP provides a statement on that is endorsed (A1 - "agreement 1") and one that has accepted a registration from an RP and validated via A1 to produce A2. In essence this allows for trust lines to be established in a M:N way. Is that accurate?
I’m not sure I really understand what you’re saying here but I agree with your conclusion that trust lines can be established in M:N ways :-)
> On the OBIE SSA side, outside of MTLS certificates, the registration process is verified at client_id establishment using an SSA generated from a central registry/directory (OBIE) with all parties trusting the directory (essentially M:1). In the UK these SSA's are not rechecked (ie. only have an expiry prior to client_id registration) with status being presented via a private API (I think?!). In Australia the proposal is to have similar SSA's with RP (called "Recipients") retrieve an SSA via a service operated by a government authority which is then presented to the OP for validation. For ongoing key management there is a mandated DCR API: https://cdr-register.github.io/register/#register-a-client-using-a-cdr-register-issued-software-statement-assertion <https://cdr-register.github.io/register/#register-a-client-using-a-cdr-register-issued-software-statement-assertion> .
> I guess where I'm headed with all this is that OIDC Federation seems to be being developed/deployed within one environment (academic) while the OB method is a few years down implementation, has "corporate" adoption but isn't currently part of an OpenID standard (I think?).
OIDC federation has strong roots in the academic community because to my knowledge there is no other place where you have multi lateral federations of the same size.
> In many respects the trust establishment for Federation seems like SSA's by a different name but the consideration for chains of trusted parties seems particularly useful when looking at diversifying the central authority. An example of this might be if the Australian government was to decide a different sector (ie. energy & telco versus banking) will be handled by a different government department.
> Considering the name of the spec is OIDC Federation I wonder if there should be consideration to consider coverage in both environments?
The name is partly a function of the environment it has been developed in (OIDF).
There is for instance no reason why you couldn’t for instance build OAuth2 federations using the federation draft.
> Personal opinion, I like SSA's from an "existing software availability" perspective but architecturally I prefer Federation because it looks like a crossover to a distributed trust chain (eg. a "blockchain") in the, perhaps distant future, could be quite elegant.
> Thanks for your time,

Thanks for your !

— Roland

The higher up you go, the more mistakes you are allowed. Right at the top, if you make enough of them, it's considered to be your style. 
-Fred Astaire, dancer, actor, singer, musician, and choreographer (10 May 1899-1987)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20191102/58bc10eb/attachment.html>

More information about the Openid-specs-ab mailing list