Add "organizationIdentifier" as alternative Issuer identification and key resolution with X.509 certificates
Nobody has claimed this yet.
- Dominant language
- Shell
- Stars
- 112
- Forks
- 38
- Avg merge
- 12d 19h
- Merged PRs (30d)
- 4
Description
An additional possibility for using X.509 certificates may be added in section 7.1 Issuer identification and key resolution to validate an issued Credential, using the organizationIdentifier (OID 2.5.4.97) in the leaf certificate, as an alternative to the dNSName SAN.
At least in the EU, the organizationIdentifier is compulsory in the subject field of eIDAS digital certificates for legal persons issued by a QTSP, as specified in ETSI EN 319 412-3 V1.2.1 (2020-07) and following Recommendation ITU-T X.520.
ETSI defines the organizationIdentifier with simple but extensible schema which currently can represent:
VATfor identification based on a national value added tax identification number.LEIfor a global Legal Entity Identifier as specified in ISO 17442.PSDfor identification based on the national authorization number of a payment service provider under Payments Services Directive (EU).NTRfor identification based on an identifier from a national trade register.
Almost every legal document in use today involving legal entities (contracts, invoices, payments ...) include one of those identifiers in the text of the document, not only in the EU but elsewhere. This makes it very easy to verify that the signer is the same legal entity identified in the document (the organizationIdentifier matches the identifier used in the document).
I suggest to have the same possibility for SD-JWT VCs:
- x.509 certificates: the SD-JWT VC contains the issuer's certificate along with a trust chain in the x5c JOSE header. If the issuer's certificate includes the organizationIdentifier (OID 2.5.4.97) attribute in the subject field, the iss value MUST be an identifier matching the issuer's organizationIdentifier. Otherwise ...
I used the word "MUST" above because IMO if the certificate already includes an organizationIdentifier it should be the preferred option, because if the certificate was issued according to some regulatory framework in some jurisdiction, that means that most probably the organizationIdentifier is the one used in the business registry of the jurisdiction (or any other source of trust) and in the powers of attorney that provides the power to the legal representative of the legal entity. Matching the iss with the organizationIdentifier increases the legal certainty associated to the verification of the SD-JWT VC.
Of course, it could be just another option and the issuer may choose.
Contributor guide
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.
Research direction
Start with section 7.1 of the linked OpenID4VC HAIP SD-JWT VC specification and review the cited ETSI EN 319 412-3 and ITU-T X.520 requirements for organizationIdentifier. Define how iss matching should work when the certificate contains this attribute and what fallback applies otherwise; done means the specification gives an unambiguous issuer-identification rule.
Written by the indexing model from the issue text.
Assessment
- Domain
- authentication, security
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100