Service Identifier in case of Trust services
Nobody has claimed this yet.
- Dominant language
- Shell
- Stars
- 112
- Forks
- 38
- Avg merge
- 12d 19h
- Merged PRs (30d)
- 4
Description
ETSI TS 119 612 allow as Service identifier for trust services not only x509 (see section 5.5.3 of 119 612) but also URI. Means the TrustList does not necessarily only contain x509. As TS 119 612 is referenced by IA on Art. 22 eIDAS it´s mandatory and a gap between the TS and OID4VP might lead to not intended issues.
Is there any technical reason why Section 6.1.1.2 of OID4VP is limited to “The trust chain of a matching Credential MUST contain at least one X.509 Certificate that matches one of the entries of the Trusted List or its cascading Trusted Lists” (as the entry is not necessarily a x509)? Recommend to change accordingly so that also URI allowed.
Especially as EUDIW might be used to communicate not only with trust services on certficates but also other ones (see section 5.5.1.1 ETSI TS 119 612).
Recommend that OID4VP copies only the requirements from ETSI TS 119 612 for Service Identifier.
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 by reading OID4VP section 6.1.1.2 alongside ETSI TS 119 612 sections 5.5.3 and 5.5.1.1. Compare the current X.509-only wording with the broader Service Identifier possibilities described by ETSI. Done means the specification’s trust-list requirement is aligned with the applicable ETSI requirements, with the scope and interoperability impact resolved.
Written by the indexing model from the issue text.
Assessment
- Domain
- authentication, security
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100