Skip to content

Conversation

@ronaldkoster
Copy link
Collaborator

In a (Delegated) Service Connection Grant an Outway can be specified based on domain name. Previously only a public key thumbprint was allowed. An Outway must have the domain name specified as a Subject Alternative Name in its certificate to be allowed to request an access token. By allowing domain names Contracts won't have to be renewed when the Outway renews its certificate and rotates its keypair.

@github-actions
Copy link

Copy link
Member

@TheBonheurs TheBonheurs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we also add relevant test cases for this functionality (in the test-suite)?

1. The Manager is provided by a Peer who has an Inway which is offering the Service specified in `grant.data.service.name`.
1. The Peer ID specified by the X.509 certificate of the client requesting the access token matches the value of the field `grant.data.outway.peer_id`.
1. The X.509 certificate provided by the client contains the same public key as specified in `grant.data.outway.public_key_fingerprint`
1. The X.509 certificate provided by the client contains a public key with the same public key thumbprint as specified in `grant.data.outway.public_key_thumbprint`. This validation should only be preformed when the value of `grant.outway.type` equals `OUTWAY_TYPE_PUBLIC_KEY_THUMBPRINT`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
1. The X.509 certificate provided by the client contains a public key with the same public key thumbprint as specified in `grant.data.outway.public_key_thumbprint`. This validation should only be preformed when the value of `grant.outway.type` equals `OUTWAY_TYPE_PUBLIC_KEY_THUMBPRINT`
1. The X.509 certificate provided by the client contains a public key with the same public key thumbprint as specified in `grant.data.outway.public_key_thumbprint`. This validation should only be performed when the value of `grant.outway.type` equals `OUTWAY_TYPE_PUBLIC_KEY_THUMBPRINT`

1. The Peer ID specified by the X.509 certificate of the client requesting the access token matches the value of the field `grant.data.outway.peer_id`.
1. The X.509 certificate provided by the client contains the same public key as specified in `grant.data.outway.public_key_fingerprint`
1. The X.509 certificate provided by the client contains a public key with the same public key thumbprint as specified in `grant.data.outway.public_key_thumbprint`. This validation should only be preformed when the value of `grant.outway.type` equals `OUTWAY_TYPE_PUBLIC_KEY_THUMBPRINT`
1. The X.509 certificate provided by the client has a Subject Alternative Name(SAN) that matches the domain name specified in `grant.data.outway.domain_name`. This validation should only be preformed when the value of `grant.outway.type` equals `OUTWAY_TYPE_DOMAIN_NAME`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
1. The X.509 certificate provided by the client has a Subject Alternative Name(SAN) that matches the domain name specified in `grant.data.outway.domain_name`. This validation should only be preformed when the value of `grant.outway.type` equals `OUTWAY_TYPE_DOMAIN_NAME`
1. The X.509 certificate provided by the client has a Subject Alternative Name (SAN) that matches the domain name specified in `grant.data.outway.domain_name`. This validation should only be preformed when the value of `grant.outway.type` equals `OUTWAY_TYPE_DOMAIN_NAME`

- peer_id
- public_key_thumbprint
outwayDomainName:
description: The details of the Outway based on a domain name for which a connection authorization was granted
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
description: The details of the Outway based on a domain name for which a connection authorization was granted
description: The details of the Outway based on a domain name for which a connection was authorized

I think this flows better but only if 'connection authorization' is not a defined term already.

@ronaldkoster ronaldkoster force-pushed the outway-domain-name branch 2 times, most recently from 377e21d to e5fb932 Compare November 4, 2025 13:29
In a (Delegated) Service Connection Grant an Outway can be specified
based on domain name. Previously only a public key thumbprint was
allowed. An Outway must have the domain name specified as a Subject
Alternative Name in its certificate to be allowed to request an access
token. By allowing domain names Contracts won't have to be renewed when
the Outway renews its certificate and rotates its keypair.
@TheBonheurs TheBonheurs added Status: Ter goedkeuring Het voorstel is uitgewerkt en wordt ter goedkeuring aangeboden. Type: Wijziging Inhoudelijke wijziging op een standaard Overleg: TO-DK Te agenderen voor het Technisch Overleg Digikoppeling Scope: Groot Grote wijziging met grote impact labels Nov 28, 2025
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

An example using a domain name is missing

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Discussed this with @ronaldkoster and concluded that adding an example is not needed. The referenced lines already show a Contract with a ServiceConnectionGrant, and there are no defined examples for OutwayIdentificationType in the standard beyond descriptive guidance. Adding such examples would also raise the question of adding examples for other types (e.g., ServiceTypes).
We'll have to discuss this in a future release.

Co-authored-by: Niels Dequeker <niels@dqkr.be>
@github-actions github-actions bot added Status: In bewerking Het voorstel is in bewerking bij de beheerorganisatie. and removed Status: Ter goedkeuring Het voorstel is uitgewerkt en wordt ter goedkeuring aangeboden. labels Jan 13, 2026
@TheBonheurs TheBonheurs merged commit e68c360 into develop Jan 13, 2026
9 checks passed
@TheBonheurs TheBonheurs deleted the outway-domain-name branch January 13, 2026 14:15
@github-project-automation github-project-automation bot moved this from Intake to Done in Digikoppeling board Jan 13, 2026
@github-actions github-actions bot added Status: Klaar voor release Het voorstel is verwerkt en klaar voor de volgende release. and removed Status: In bewerking Het voorstel is in bewerking bij de beheerorganisatie. labels Jan 13, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Overleg: TO-DK Te agenderen voor het Technisch Overleg Digikoppeling Scope: Groot Grote wijziging met grote impact Status: Klaar voor release Het voorstel is verwerkt en klaar voor de volgende release. Type: Wijziging Inhoudelijke wijziging op een standaard

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

4 participants