Describe the solution you'd like
Currently, the ExternalSecret CRD for IBM Secrets Manager requires that the user provide the secret ID along with secret type:

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: test-cluster-secret
spec:
  secretStoreRef:
    name: sm-secret-store
    kind: SecretStore
  target:
    name: test-app-secret
  data:
  - secretKey: .secret
    remoteRef:
      key: iam_credentials/6328b1d3-64f4-a976-0c01-d7ee7929097b

So to be transparent, it is needed that the secret name can be provided along with secret type.

What is the added value?
Secret in Secrets Manager can be referenced using Name instead of ID.

Give us examples of the outcome
The ExternalSecret CRD can have the secret_name provided for key along with secret_type in the cases where the
secret needs to be pulled by name:

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: test-cluster-secret
spec:
  secretStoreRef:
    name: sm-secret-store
    kind: SecretStore
  target:
    name: test-app-secret
  data:
  - secretKey: .secret
    remoteRef:
      key: iam_credentials/my-secret-name

In order to achieve this, ESO would evaluate the secretID provided for UUID format to determine if it is a secret ID or secret name. The assumption in this duality approach (rather then introducing new externals) is that going forward, referencing by name would be the preferred choice of users, so making the UX of this method consistent with other providers - while still providing backward compatibility for IDs (but de-focussing this use case).

Observations (Constraints, Context, etc):
The existing way of processing given secretID in UUID format is unaffected.
It involves additional ListAllSecrets to get all the secrets in order to match for secret type and secret name combination.
The results of this list call can then be cached for faster processing and reconciliation.