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

Vladimir Dzhuvinov vladimir at connect2id.com
Mon Nov 4 21:04:55 UTC 2019

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 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20191104/4418a798/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4007 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20191104/4418a798/attachment.p7s>

More information about the Openid-specs-ab mailing list