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

Nick Roy nroy at internet2.edu
Mon Nov 4 21:19:59 UTC 2019


Also having other sectors beyond R&E care about this will make it a lot more likely that diverse implementations will be created and maintained.

Nick

On 4 Nov 2019, at 14:04, Vladimir Dzhuvinov via Openid-specs-ab 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/20191104/f4a59fe4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 512 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20191104/f4a59fe4/attachment.asc>


More information about the Openid-specs-ab mailing list