Interoperability: Validation of tls_client_auth_subject_dn using RFC7591
@lj-raidiam is already working on this.
Since Jul 11, 2026.
- Dominant language
- HTML
- Stars
- 3
- Forks
- 3
- PR merge metrics
- No merged PRs in 30d
Description
Originally submitted by Ralph Bragg (Ralph Bragg) on 2021-04-28
ETSI specification https://www.etsi.org/deliver/etsi_ts/119400_119499/119495/01.03.01_60/ts_119495v010301p.pdf ETSI TS 119 495 V1.3.1 which defines the certificate profile being used as oAuth 2.0 client authentication. When used as part of DCR, the metadata property tls_client_auth_subject_dn needs to be provided by TPPs and then checked by the bank that it matches the corresponding certificate used for mutual tls.
The issue is that it is ambiguous with no discovery mechanism available that describes how both parties will process non standard oids.
This basically means that TPPs have to try a couple of times to register their clients by guessing how a Bank will process their DN string. https://tools.ietf.org/html/rfc4514 describes how this should be performed.
Implementations MAY recognize other DN string representations.
However, as there is no requirement that alternative DN string
representations be recognized (and, if so, how), implementations
SHOULD only generate DN strings in accordance with of this
document.
Bitbucket status: open
Bitbucket origin: issue 404
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.