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

Stuart Low stuart at biza.io
Sat Nov 2 04:07:00 UTC 2019


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? Personally I like where
Federation is headed but OBIE (and soon Australia) have gone down the
SSA path.

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?

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
.

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?).

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?

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,

Stuart


On 22/10/19 3:19 am, Mike Jones via Openid-specs-ab wrote:
>
> Draft 09 of the OpenID Connect Federation specification has been
> published at
> https://openid.net/specs/openid-connect-federation-1_0-09.html.  Major
> changes were:
>
>   * Separated entity configuration discovery from operations provided
>     by the federation API.
>   * Defined new authentication error codes.
>
>  
>
> The authors believe that this version should become an Implementer’s
> Draft, in preparation for interop testing in the coming year.  Please
> review!
>
>  
>
>                                                        Thanks,
>
>                                                        -- Mike
>
>  
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20191102/55d61acf/attachment-0001.html>


More information about the Openid-specs-ab mailing list