As-is, the token signing certificate for an upstream IdP must be issued by a third party CA. The token signing certificate cannot be self signed.

Since the trust model ensures secure metadata exchange between upstream IdP and context handler, there's no need to enforce a trust model, where token signing certificate is issued by a third party trusted intermediary. The token signing certificate could just as well be self signed.

Using self signed certificates has some benefits:

• Many municipalities already use self signed certificates, so they wouldn't have to make any changes.
• It can reduce the frequency of certificate changes.
• It costs less.

On the other hand, there's significant political value in requiring that DanID certificates are used.

As-is, UID has to be encoded in the x509subjectname string in the SAML2 subject element. That means that (1) upstream IdP has to use string concatenation to create the x509subjectname including the mandatory uid, and (2) downstream user system must parse the text string to get the uid.

It would simplify configuration of the upstream IdP, if it could simply send a claim with the UID value.

On the other hand, it would mean sending redundant information in the token, and the subject field really is meant to send the user's unique id.

Currently, JFR have to be sent from upstream IdP to context handler encoded in an OIO BPP xml structure.

It could simplify configuration of upstream IdP if JFR could be sent as individual claims instead of being encoded in OIO BPP. Then it wouldn't be necessary to configure a custom claims transformation to generate the OIO BPP xml from JFR values on the upstream IdP.

This feature is mostly relevant to municipalities, that don't use dynamic data restrictions, and where the data restrictions are statically configured on context handler.

SSO is a problem with SAML2 scoping to upstream IdP, because the upstream IdP will only send JFR for the US the user is logging in to. When the user then get's SSO to another US, then the original token from upstream IdP will not contain JFR for the second US.

Effectively that means, that if context handler uses SSO, the the token from upstream IdP must contain all JFR.

Since the user normally has SSO with upstream IdP (e.g. municipality or NemLog-In) disabling SSO would have limited impact on the end users.

On the positive side, disabling SSO on context handler would make it possible to use scoping upstream IdP, and would reduce the memory pressure of CH, which would increase the performance. This would be most noticeable with STSI-680 because of its requirement to keep bootstrap token in memory.

As-is, data restrictions (DA) have to be sent as individual claims from upstream stream IdP. That means that the namespace of DA have global scope, and different types have to be used for each DA in each role mapping. E.g. the type of a KLE DA must be different between two role mappings.

If DA are included as part of OIO-BPP sent from upstream IdP to CH, then DA can be implicitly scoped for the JFR in the same privilege group. That means the same type can be used for a KLE DA regardless of which role mapping the DA is being used in.