## Issue is relevant to 4.0 QA build and 3.1.6
I've been testing the QA build of 4.0 but the same issue exists in previous stable version.
I understand the GUI is for a general passport provider, but SAML and OIDC (or other) are totally separate use cases, while synanymous in functionality work with totally different parameters, and so perhaps the GUI should be more customized towards each.
## Clarifying key/certificate the parameters
Currently setting the parameters is confusing at best
* IDP Signing Cert --- the "cert" attribute, although bothersome to serialize the certificate into a single string Probably the most clear, although the attribute should be named or referenced as "idpSignCert" or something similar
* IDP Encryption Cert --- not supported, cannot encrypt SAML Request objects atm.
* Passport SP Signing Cert --- "signingCert" attribute, name is confusing and specific to the IDP provider (should not be)
* Passport SP Signing Key --- "privateCert" attribute, RSA PAM key string, name is confusing and specific to the IDP provider (should not be)
* Passport SP Encryption Cert --- "decryptionCert" attribute, also "SP TLS cert" field for a file which is confusing because there is no TLS involved ... better than written in plaintext string too if put directly into an options attribute
* Passport SP Encryption Key --- "decryptionPvk" attribute, also "SP TLS key" field which is confusing because there is no TLS involved ... better than written in plaintext string too if put directly into an options attribute map
Instead of listing all the Passport SP data, perhaps building a passport SP profile(s) and referencing the sp name for each to be tied to that IDP provider
## Security of keys and signatures
One of the two keys listed above for Passport SP Signing and Ecnryption are configurable in plaintext PAM format and any administrator can extract them, so both (privateCert as signing key) should be configurable the same way.
Also the passport-sp cert/key files based on your documentation are for encryption while there are no signing cert/key pair directions
Another choice that makes a lot of sense is to leverage a JKS keystore with aliases and there is a 'node-keytool' library that can help achieve that, which will help confidentiality on disk-level where security keys are not stored in plaintext.
## Importing of IDP metadata
Ideally you should be able to pre-fill the IDP settings like entityId, callbackUrl, identifiers, certificate, logout, from a metadata file, which is how the integration data is exchanged normally instead of parsing through and configuring all the pieces manually.