oidc extension design question - oidc relying party

[Cantor, Scott]

> Until now we have used in shib oidc extension saml2 entity id value also as
> oidc issuer value. That is a shortcut that will not work for all deployments,
> specially if you are not creating a new deployment having possiblity to
> choose the entity id to match oidc issuer value.

I imagine that might happen but is it likely to be common? We already allow overriding of the entityID, particularly if it's a static sort of override to a fixed value, so I'm not sure this is a big problem really.

> What I did to solve this was to define a new relying party service for oidc,
> https://github.com/CSCfi/shibboleth-idp-oidc-
> extension/blob/master/roles/oidc-extension/templates/oidc-relying-party-
> system.xml, taking the responder id from a new idp.properties property
> idp.oidc.issuer. As a result we also then have a new relying party
> configuration also for the user to configure,
> https://github.com/CSCfi/shibboleth-idp-oidc-
> extension/blob/master/roles/oidc-extension/templates/oidc-relying-
> party.xml. So no single line of code, just new service and some new wiring.

No, don't do that. Just add an RP override with that profile enabled and supply a responderId bean property for that configuration.

I think this is not likely to be a very common need.

> I am yet to decide  myself if this was a good idea or if there was a better
> solution that I have missed. Afterall, the original target was just to make it
> possible to have different  oidc issuer value from saml2 entity id value. The
> obvious downside I am saying to myself is having the separate oidc-relying-
> party.xml and loosing the possibility to configure it all in the relying-party.xml
> instead. On the other hand, as this is an extension, having separate files
> might make it easier to install the extension.

No, that's much worse.

-- Scott