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

Tom Jones thomasclinganjones at gmail.com
Tue Nov 5 16:42:36 UTC 2019

US Healthcare is headed in the direction of a "Capabilities Statement"
which meets AFAIK the meaning of an SSA.
Roland and Nick excluded the concerns of federation in this class of
application at the start of the federation doc, so we look at the doc as
advisory only. It is not strictly usable as written. I doubt that Nat will
allow this doc to be posted to the group.
Peace ..tom

On Mon, Nov 4, 2019 at 1:12 PM Vladimir Dzhuvinov via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> Hi Stuart,
> You raise a valid and interesting point.
> OBIE / Open Banking's current take at "federation" could put the scheme at
> some point in future in a situation where it's cut off from possibilities
> to evolve its institution trust model, grow into new unforeseen areas,
> allow the implementation of new financial services, etc.
> If federation is a first-class concept in Open Banking, orthogonal and
> permitting the full set of possible trust relationships (m:n as Roland
> explained), Open Banking will then be better prepared to meet unexpected
> future developments.
> I wonder what can be reasonably done at this point.
> Vladimir
> --
> Vladimir Dzhuvinov
> On 02/11/2019 06:07, Stuart Low via Openid-specs-ab 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? 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/20191105/e7b8ed18/attachment-0001.html>

More information about the Openid-specs-ab mailing list