[Openid-specs-ab] OpenID Connect Federation Design

[Andreas Åkre Solberg]

A few more comments:

In the current OpenID Connect Federation spec 5.2 describes the process of using dynamic relying party registration
https://openid.net/specs/openid-connect-federation-1_0.html#rfc.section.5.2
Because the client does not have a key pair, it needs to get its superior to sign a statement for the client to use. This signed registration request is not restricted to a specific provider. The signed request becomes some sort of credential itself. An accepted provider within a federation may reuse the signed registration request to get client_id secret pairs to all other providers in the federation. The criticality of this depends, and can be discussed, but in my opinion this needs a fix. I cannot find any other secure way protect the client registration request, other than using asymetric crypto.

I see that the metadata flattening process is not specified normatively. I think it should (it also says so in Appendix C. Open Issues). I think the proposed model for this is a good model. Still it needs more evaluation and discussion. There is at least one issue that needs to be dealt with, which is language specific attributes such as client_name#ja-Jpan-JP.


Andreas Åkre Solberg
Senior Technical Architect
UNINETT – https://uninett.no
https://www.linkedin.com/in/andreassolberg/





2. aug. 2018 kl. 08:58 skrev Andreas Åkre Solberg via Openid-specs-ab <openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>>:

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.

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