[Openid-specs-ab] OpenID Connect Federation updated in preparation for third Implementer’s Draft review

Pawel Kowalik pawel.kowalik at ionos.com
Wed Jun 30 06:38:59 UTC 2021

Hi David,

The purpose of RP registration in the federation context is to verify
whether the RP is legit part of the federation at all. The assumption is
that OP may decide only to accept RPs they can trust based on their
respective Entity Statements.
The Automatic Registration allows embedding all of that in one
authentication step.

Entity Statements fulfill to a big extent the same function as VCs/VPs,
just being a credential issued by federation trust anchor or intermediate
towards OPs or RPs. I think it would be worth a while taking a look whether
Federation spec would include extensibility elements to allow either ECs or
VC/VP for this purpose.

Kind Regards,

On Tue, 29 Jun 2021 at 21:43, David Chadwick via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> Hi Roland
> once SIOP is in use with user wallets, why is client registration needed?
> I ask this, because when I am using my browser I go to multiple web sites
> without knowing anything about them first. I might buy something from a RP
> that I have never visited before. No prior registration of either myself
> nor the RP is needed.
> So why cannot it work in the same way with SIOP and VCs? The only meta
> data that is needed prior to any user involvement is that the RP has to
> know the meta data of the VC Issuers that it trusts. The RP has to know the
> the VC issuer's X.509 PKC and understand the schema of the VCs it will
> issue, and then we are good to go. The user visits the RP's web site, it
> sends its claim requirements to the user's SIOP wallet, the user chooses
> VCs that match this and returns a VP to the RP. The RP then validates PoP
> and that the VCs were issued by the trusted Issuers. Can you critically
> appraise this model please.
> Kind regards
> David
> On 28/06/2021 08:49, Roland Hedberg via Openid-specs-ab wrote:
> Hi !
> Thanks Torsten for your comments. I’ll start the answer with the design
> criteria we had:
> - So far we’ve seen a small number of federation models. One-to-many
> (Google's 1 OP, many RPs or Amazon's 1 RP and many OPs) and small to fairly
> large multi lateral federations like EduGAIN (~4400 OPs and 3300 RPs). All
> of them based on centralised static registration. In order to allow multi
> lateral federations to grow in size we think that it’s necessary to move to
> decentralised dynamic registration (imaging if SIOP takes off).
> - One-to-many OIDC federations normally uses dynamic provider info
> discovery but not dynamic client registration.
> Which is not that surprising since classic OIDC client registration in
> essence is a leap of faith. There is no way you as an OP can
> verify that the client metadata is correct. We would like to make client
> registration more robust and allow OPs to verify
> the correctness of the client metadata.
> - Federation policies will change over time (like moving from SHA1 to
> SHA256) we would like to support that and to have built-in
> support for policies to change dynamically. Also, having decentralised
> entity registration we need a way to enforce federation policies.
> - OIDC and OAuth2 both have defined APIs for provider info discovery and
> client registration the federation specification should
> work equally well for both.
> - The messages pushed around in this specification should not depend on
> TLS for their protection.
> - We should when possible use functionally already present in OIDC
> libraries (like key handling, signed JWT verifications, JWKS, ..)
> - We should only touch the initial OIDC RP<->OP communication phases
> (provider info discovery and client registration).
> Now, this changed during the work of the specification so there now is one
> use case where we touch the authorization request.
> - An entity (OP or RP) should be able to belong to more the one federation.
> On 30 May 2021, at 18:38, Torsten Lodderstedt <torsten at lodderstedt.net>
> wrote:
> I think an overview describing and motivating the design concepts and
> principles would be helpful to readers.
> I would also appreciate an explanation why the federation draft design is
> better suited for the envisioned use cases than X.509 certificates.
> Deployments need to be convinced to invest into a pretty new solution with
> a lot of runtime overhead (latency and availability implications!) while
> X.509 is used for the same/similar (?) applications in the wild. I’m pretty
> sure there a good arguments ;-).
> — Roland
> Were it left to me to decide whether we should have a government
> without newspapers, or newspapers without a government, I should not
> hesitate a moment to prefer the latter. -Thomas Jefferson, third US
> president, architect, and author (1743-1826)
> _______________________________________________
> Openid-specs-ab mailing listOpenid-specs-ab at lists.openid.nethttp://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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20210630/969d4ff9/attachment-0001.html>

More information about the Openid-specs-ab mailing list