[Openid-specs-ab] OpenID Connect Federation Design

John Bradley ve7jtb at ve7jtb.com
Fri Aug 3 12:52:14 UTC 2018


The idea of being able to separate the registration service from the authentication service predates software statements.

We sort of dropped it in favor of using a software statement to dynamically register.

However in open banking and other federation type deployments we do see a desire to centrally manage clientID.

I mentioned it because we can consider these other approaches, it may turn out that software statements give us more flexibility in negotiating capabilities.

For central registration you can encode the info in the client_id or dereference it, or possibly use a hybrid approach of including the id and a reference in a signed JWT to use as the client ID to reduce size and allow updating.

To keep Leif happy I would also sign the data pointed to by the refrence and not rely completely on TLS😊

John B.

 

Sent from Mail for Windows 10

From: Nat Sakimura
Sent: Friday, August 3, 2018 2:12 AM
To: openid-specs-ab at lists.openid.net Ab
Cc: John Bradley
Subject: Re: [Openid-specs-ab] OpenID Connect Federation Design

https://datatracker.ietf.org/doc/draft-bradley-oauth-stateless-client-id/ may now get some more traction, do not you think? > John

On Fri, Aug 3, 2018 at 7:09 AM John Bradley via Openid-specs-ab <openid-specs-ab at lists.openid.net> wrote:
Anyone can join a WG call.   
 
To actively participate and post on the list you need to sign the IPR non assert for the WG.
You can do it electronically from this page. 
https://openid.net/intellectual-property/
 
Andreas raises some good points.
 
The main reason for keeping the client registration step is that is required to support the legacy of symmetric OAuth credentials. 
 
If we acknowledge that symmetric credential authentication is a bad thing that potentially allows us to move in this proposed direction.
 
The only other reason for keeping per client registration would be to negotiate specific capabilities with each AS.  I know SAML has gotten by without that, and I suspect that it is not a bad tradeoff when dealing with a federation, but it is something to keep in mind.
 
I did do a OAuth spec for stateless client_id a long time ago.
It didn’t get much interest at the time.
https://datatracker.ietf.org/doc/draft-bradley-oauth-stateless-client-id/
 
We should discuss the advantages and disadvantages of the approaches on the call.
 
John B.
 
Sent from Mail for Windows 10
 
From: Leif Johansson via Openid-specs-ab
Sent: Thursday, August 2, 2018 12:30 PM
To: openid-specs-ab at lists.openid.net
Cc: Leif Johansson
Subject: Re: [Openid-specs-ab] OpenID Connect Federation Design
 
 
 
On 2018-08-02 08:58, Andreas Åkre Solberg via Openid-specs-ab wrote:
> I wrote a new article trying to explain and compare two alternative
> designs for trust chains for OpenID Connect Federations:
> 
> https://oauth.no/trust/
> 
> I would really appreciate others comments on this. I hope there is room
> for *discussions* on these fundamental design choices, regardless of the
> /implementer’s draft/ status of the currently proposed specification.
 
I would like to have a discussion about this proposal. I am however
unfamiliar with the processes that govern the OIDF.
 
        Cheers Leif
_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs-ab
 
_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs-ab



-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

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


More information about the Openid-specs-ab mailing list