Voor een overzicht van de notatieconventies gebruikt in de eisen zie deze pagina. Dit overzicht van conceptafspraken is ook beschikbaar als een excel sheet, klik hier om deze te downloaden.
Merk op, dit overzicht van conceptafspraken bevat enkel de afspraken van het afsprakenstelsel, en niet de context en uitleg daarvan. Voor meer informatie over de afspraken zie de gerelateerde pagina’s in het afsprakenstelsel.
Generieke afspraken
Aansprakelijkheid
Deelnemers MOETEN juridische aansprakelijkheid accepteren voor geleden schaden veroorzaakt door het handelen in strijd met de rechten en plichten geldend voor haar rol
Partijen MOETEN aansprakelijkheidsclaims beperken tot wat naar redelijkheid en billijkheid in verhouding staat tot de geleverde datadienst en de geleden schade
Deelnemers MOETEN juridische aansprakelijkheid accepteren voor geleden schaden veroorzaakt door het handelen in strijd met de rechten en plichten geldend voor haar rol
Partijen MOETEN aansprakelijkheidsclaims beperken tot wat naar redelijkheid en billijkheid in verhouding staat tot de geleverde datadienst en de geleden schade
Abonnement op een gebeurtenis
DSGO.Basis
: Als een partij een abonnement wil aanbieden in het DSGO dan MOET de partij dit mogelijk maken met een /subscriptions
endpointDSGO.Basis
: Als een partij een abonnement wil gebruiken in het DSGO dan MOET de partij notificaties kunnen ontvangen op een webhook url
API specifications
Generic API requirements
DSGO.Basis
: Parties MUST validate that all received API calls conform to the DSGO trust frameworkDSGO.Basis
: Parties MUST validate that all responses to API calls conform to the DSGO trust frameworkDSGO.Basis
: Parties MUST define the default base URL of API endpoints following the <domain-name>/<path>/resources
format, where <domain-name>
is server specific and <path>
is an optional URL pathDSGO.Basis
: Parties MUST define the default base URL of API endpoints without a trailing slash
DSGO.Basis
: Parties SHOULD limit API calls to include only a reasonably sized amount of dataDSGO.Basis
: Parties MUST NOT include HTTP bodies in GET or DELETE requests
DSGO.Basis
: Parties MAY include query options for functionalities such as filter, sort, and page in their API endpoint as defined in OData 4.01DSGO.Basis
: Parties MUST reject any requests that contain unsupported url parameters with a 501 Not Implemented
as defined in OData 4.01
DSGO.Basis
: Parties MUST make caching explicit to API usersDSGO.Basis
: Parties MUST include the following headers in the API response when it is not cacheable:cache-control: no-store
pragma: no-cache
DSGO.Basis
: Parties MUST include the following headers in the API response when it is cacheable:cache-control: max-age=31536000
Note: max-age
MAY vary
API endpoints
/brokers
The trust framework catalogue MUST provide broker evidence via the /brokers
endpoint
/capabilities
DSGO.Basis
: Parties MUST provide information about their services via the /capabilities
endpoint
GET /capabilities
DSGO.Basis
: Parties MUST support a GET call to a /capabilities
endpoint to retrieve a list of their features (as an array of capabilities_info
objects).
DSGO.Basis
: Parties MUST provide only public
features to a successful GET request to the /capabilities
endpoint, which does not include an access tokenDSGO.Basis
: Parties MUST validate that a GET request to the /capabilities
endpoint includes the Authorization
header according to RFC 6750 and contains a valid access token, when returning restricted
features
DSGO.Basis
: Parties MUST include a capabilities_token
including an array with capabilities_info
objects in a response to a successful GET call to the /capabilities
endpoint
Data service
DSGO.Basis
: Data service providers MUST expose their resources in conformance with the trust framework
DSGO.Basis
: Data service providers MUST expose their resources in conformance with the trust framework
DSGO.Basis
: Data service providers MUST require the HTTP headers as defined in the table below in a data service request if using the described mechanisms as defined in the DSGO
DSGO.Basis
: Data service providers SHOULD make use of relevant open standards in the definition of the service content of a data service
DSGO.Basis
: Data service providers MUST use the HTTP headers as defined in the table below in a data service response if using the described mechanisms as defined in the DSGO
/delegation
Autorization registers MUST provide delegation evidence via the If data entitled parties wish to provide delegation evidence, they MUST provide delegation evidence via the /delegation
endpoint/delegation
endpoint
POST /delegation
Parties MUST support a POST call to a /delegation
endpoint to retrieve delegation evidence (in a delegationEvidence
object).
Parties MUST validate that a POST call to a /delegation
endpoint includes the Authorization
header according to RFC 6750 and contains a valid access token
Parties MUST validate that a POST call to a /delegation
endpoint includes the Authorization
header according to RFC 6750 and contains a valid access token
Parties MUST validate that the HTTP body of a POST request to the /delegation
endpoint contains the parameters as defined in the table below
Parties MUST support a POST call to a /delegation
endpoint to retrieve delegation evidence (in a delegationEvidence
object).
/notifications
Parties MUST have a webhook url before obtaining a subscription If a party has a subscription, they MUST support a notification
object
Parties MUST determine a suitable authorisation policy for their webhook url
POST /notifications
Parties MUST support a POST call to their webhook url to be able to receive notifications from subscriptions
Parties MUST validate that the HTTP body of a POST request to a webhook url contains a valid notification
object
Parties MUST respond with a 200 OK to a successful POST call to a webhook url
/parties
The trust framework catalogue MUST provide information about participants via the /parties
endpoint
GET /parties
The trust framework catalogue MUST support a GET call to a /parties
endpoint to retrieve a list of DSGO participants in an array of party_info
objects as payload value of a Authenticatie JWT.
The trust framework catalogue MUST validate that a GET call to a /parties
endpoint includes the “Authorization
" header according to RFC 6750 and includes a valid access token
The trust framework catalogue MUST validate that the HTTP body of a GET request to the The trust framework catalogue MUST validate that the HTTP body of a GET request to the /parties
endpoint contains the parameters as defined in the table below/parties
endpoint contains at least a single parameter.
The trust framework catalogue MUST include a party_token
including of an array of party_info
objects as parties_info
in a response to a successful GET calls to the /parties
endpoint
POST /representation
The trust framework catalogue MUST support a POST call to a /brokers
endpoint to retrieve broker evidence (in a brokerEvidence
object).
The trust framework catalogue MUST validate that a POST call to a /brokers
endpoint includes the Authorization
header according to RFC 6750 and contains a valid access token
The trust framework catalogue MUST validate that the HTTP body of a POST request to the /brokers
endpoint contains the parameters as defined in the table below
The trust framework catalogue MUST include a broker_token
including of a brokerEvidence
object in a response to a successful GET calls to the /brokers
endpoint
/subscriptions
DSGO.Basis
: Data service providers MUST define subscriptions for events in accordance to the subscription
object, when implementing a subscriptionDSGO.Basis
: Data service providers MUST define events for their subscriptions in accordance to the events
object, when implementing a subscriptionDSGO.Basis
: Data service providers MUST expose their subscriptions in conformance with the DSGO /subscriptions
endpoint specificationsDSGO.Basis
: Data service providers MUST determine suitable authorisation policy for their /subscriptions
endpoint
GET /subscriptions
DSGO.Basis
: Data service providers MUST support a GET call to a /subscriptions
endpoint to retrieve a list of available subscriptions
DSGO.Basis
: Data service providers MUST include a list of subscription resources available for the data service consumer in a response to a successful GET calls to the /subscriptions
endpointDSGO.Basis
: Data service providers MUST provide a count of the number of subscriptions included, in the count
parameter, in the response to a successful GET calls to the /subscriptions
endpoint
POST /subscriptions
DSGO.Basis
: Data service providers MUST support a POST call to a /subscriptions
endpoint to create a new subscription
DSGO.Basis
: Data service providers MUST validate that the HTTP body of a POST request to a /subscriptions
endpoint contains the following parameters, with content as defined in the subscription
object:resource_type
start_date
(optional)end_date
(optional)event_type
webhook_url
DSGO.Basis
: Data service providers MUST validate that a POST request to /subscriptions
endpoint complies with their data service specific subscription requirements
DSGO.Basis
: Data service providers MUST respond with a 201 Created
to a successful POST call to a /subscriptions
endpoint
DSGO.Basis
: Data service providers MUST include the created subscription
object in the HTTP body of the response to a successful POST call to the /subscriptions
endpoint
DSGO.Basis
: Data service providers MUST respond with a 201 Created
to a successful POST call to a /subscriptions
endpoint
DSGO.Basis
: Data service providers MUST include the created subscription
object in the HTTP body of the response to a successful POST call to the /subscriptions
endpoint
GET /subscriptions/{id}
DSGO.Basis
: Data service providers MUST support a GET call to a /subscriptions/{id}
endpoint to get information about a specific subscription
DSGO.Basis
: Data service providers MUST validate that the {id}
of a GET request to a /subscriptions/{id}
is valid, exists and is available to the data service consumer
DSGO.Basis
: Data service providers MUST respond with a 200 OK to a successful GET call to a /subscriptions/{id}
endpointDSGO.Basis
: Data service providers MUST include the requested subscription
object in the HTTP body of the response to a successful GET call to the /subscriptions/{id}
endpoint
DSGO.Basis
: Data service providers MUST respond with a 404 Not found to a GET call to a /subscriptions/{id}
endpoint when the {id}
is not valid or available to a data service consumer
DELETE /subscriptions/{id}
DSGO.Basis
: Data service providers MUST support a DELETE call to a /subscriptions/{id}
endpoint to remove a specific subscription
DSGO.Basis
: Data service providers MUST validate that the {id}
of a DELETE request to a /subscriptions/{id}
is valid, exists and is available to the data service consumerDSGO.Basis
: Data service providers MUST validate that the subscription
object being deleted complies with their data service specific subscription requirements
DSGO.Basis
: Data service providers MUST respond with a 200 OK to a successful DELETE call to a /subscriptions/{id}
endpointDSGO.Basis
: Data service providers MUST NOT include an HTTP body in the response to a successful DELETE call to the /subscriptions/{id}
endpointDSGO.Basis
: Data service providers MUST set the “status"
of subscription/{id}
to "inactive"
in response to a successful DELETE call to the /subscriptions/{id}
endpoint
DSGO.Basis
: Data service providers MUST respond with a 404 Not found to a DELETE call to a /subscriptions/{id}
endpoint when the {id}
is not a valid or available to the data service consumer
POST /subscriptions/{id}/test
DSGO.Basis
: Data service providers MUST support a POST call to a /subscriptions/{id}/test
endpoint to send a test notification to the data service consumers supplied /notifications endpoint
DSGO.Basis
: Data service providers MUST validate that the HTTP body of a POST request to a /subscriptions/{id}/test
endpoint is emptyDSGO.Basis
: Data service providers MUST validate that the {id}
of a POST request to a /subscriptions/{id}/test
is valid, exists and is available to the data service consumer
DSGO.Basis
: Data service providers MUST respond with a 202 Accepted to a successful POST call to a /subscriptions/{id}/test
endpointDSGO.Basis
: Data service providers MUST NOT include an HTTP body in the response to a successful POST call to the /subscriptions/{id}/test
endpointDSGO.Basis
: Data service providers MUST trigger the sending of a notification
with “eventType":“Test"
to the subscription’s webhook url
in response to a successful POST call to the /subscriptions/{id}/test
endpoint
DSGO.Basis
: Data service providers MUST respond with a 404 Not found to a POST call to a /subscriptions/{id}/test
endpoint when the {id}
is not a valid or available to the data service consumer
/token
DSGO.Basis
: Parties MUST provide an access token via the /token
endpoint
DSGO.Basis
: Parties MUST provide an access token via the /token
endpoint
DSGO.Basis
: Parties MUST NOT accept GET calls to the /token
endpoint
POST /token
DSGO.Basis
: Parties MUST support a POST call to a /token
endpoint to create a new access token
DSGO.Basis
: Parties MUST NOT pre-register clients
DSGO.Basis
: Parties MUST validate that a POST request to a /token
endpoint contains the HTTP headers as described in the table below
DSGO.Basis
: Parties MUST validate that a POST request to a /token
endpoint contains the parameters as described in the table belowDSGO.Basis
: Parties MUST validate the client credentials in the client_assertion
received in a POST to a /token endpoint, by comparing the client_id
to the iss
and sub
claim in the client_assertion
and the subject_name
of the QSEAL used to sign the client_assertion
DSGO.Basis
: Parties MUST include the HTTP headers as described in the table below in a response to a POST request to a /token
endpoint
DSGO.Basis
: Parties MUST include an access token as described in the table below in the HTTP payload in a response to a successful POST request to a /token
endpoint DSGO.Basis
: Parties MUST NOT issue refresh tokens
DSGO.Basis
: Parties MUST include the parameters as described in the table below in the HTTP payload in a response to a failed POST request to a /token
endpoint
POST /token/revoke
DSGO.Basis
: Parties MUST support a POST call to a /token/revoke
endpoint to revoke an access token
DSGO.Basis
: Parties MUST validate that a POST request to a /token/revoke
endpoint contains the HTTP headers as described in the table below
DSGO.Basis
: Parties MUST validate that a POST request to a /token/revoke
endpoint contains the parameters as described in the table belowDSGO.Basis
: Parties MUST validate the client credentials in the client_assertion
received in a POST to a /token/revoke
endpoint
DSGO.Basis
: Parties MUST respond with a 200 OK
to a successful POST call to a /token/revoke
endpointDSGO.Basis
: Parties MUST respond with a 200 OK
to a POST call to a /token/revoke
endpoint containing an invalid access tokenDSGO.Basis
: Parties MUST no longer accept the revoked the access token after a 200 OK
response is responded
DSGO.Basis
: Parties MUST include the parameters as described in the table below in the HTTP payload in a response to a failed POST request to a /token/revoke
endpoint
DSGO.Basis
: Parties MAY include a Retry-After
header in the 503 response to a /token/revoke
endpoint to indicate the expected unavailability of the service
/trusted_list
The trust framework catalogue MUST provide information about trusted certificate authorities via the /trusted_list
endpoint
The trust framework catalogue MUST provide information about trusted certificate authorities via the /trusted_list
endpoint
GET /trusted_list
The trust framework catalogue MUST support a GET call to a /trusted_list
endpoint to retrieve a list of DSGO participants (in an array of ca_info
objects).
The trust framework catalogue MUST validate that a GET call to a /trusted_list
endpoint includes the Authorization
header according to RFC 6750 and contains a valid access token
The trust framework catalogue MUST include a trusted_list_token
including the trusted_list
array containing ca_info
objects in a response to a successful GET calls to the /trusted_list
endpoint
Gebruik van het DSGO merk
De Beheerorganisatie DSGO MOET het DSGO logo aanbieden aan deelnemers en gebruikers van het DSGO De Beheerorganisatie DSGO MOET zelf herkenbaar zijn door het DSGO logo te gebruiken in haar aangeboden stelselvoorzieningen, tooling en communicatie
DSGO.Basis
: Partijen MOGEN het DSGO merk, naam en logo wat past bij haar rol gebruiken om zichtbaar te maken dat ze een rol in het DSGO invullenDSGO.Basis
: Partijen MOETEN bij het gebruik van het DSGO merk, naam en logo wat past bij haar rol dit conform onderstaande richtlijnen gebruikenDSGO.Basis
: Als een Partij een interface aanbiedt voor een door een mens geïnitieerde datadienst, dan ZOU het DSGO logo wat past bij haar rol gebruikt MOETEN worden in deze interfaces
Generieke technische standaarden
RESTful API's
DSGO.Basis
: Partijen ZOUDEN RESTful architectuurprincipes MOETEN volgen voor API’s
DSGO.Basis
: Partijen MOETEN uitsluitend standaard HTTP-operaties ondersteunen (GET, PUT, POST, PATCH, DELETE)DSGO.Basis
: Partijen MOGEN NIET de state van de client bij houden
DSGO.Basis
: Partijen MOETEN data als resources beschikbaar stellen in een datadienstDSGO.Basis
: Partijen MOETEN resources een zelfstandig naamwoord in het meervoud als naam geven
HTTP(s)
DSGO.Basis
: Partijen MOETEN in de context van datadiensten communiceren via het HTTP protocol
DSGO.Basis
: Partijen MOETEN HTTP-headers van minimaal 10K lengte accepteren
DSGO.Basis
: Partijen MOETEN bij het ontvangen van een HTTP-verzoek antwoorden met (onder andere) een statuscode die het resultaat van het verzoek aangeeftDSGO.Basis
: Partijen MOETEN geschikte HTTP-statuscodes ondersteunen die passen bij de dienst. Tenminste de volgende: 2XX, 4XX en 5XXDSGO.Basis
: Partijen ZOUDEN de standaard foutmeldingen van de HTTP 400 en 500 statuscode reeksen MOETEN ondersteunen volgens RFC 9110
JSON
DSGO.Basis
: Partijen MOETEN JSON gebruiken voor het sturen van gegevens in de context van datadiensten
Timestamps
DSGO.Basis
: Partijen MOETEN alle datums en tijdstippen in de context van datadiensten formatteren volgens het UNIX timestamp
Identificatie, Authenticatie en Autorisatie
Concepten
Identificatie
DSGO.Basis
: Partijen MOETEN zich uniek identificeren wanneer ze betrokken zijn bij een datadienstDSGO.Basis
: Partijen MOETEN andere partijen die betrokken zijn bij een datadienst uniek identificeren
Authenticatie
Authenticatie op datadienstniveau
DSGO.Basis
: Datadienstaanbieders MOETEN voor haar datadienst bepalen welk type datadienstgebruiker geauthenticeerd wordt en dit vastleggen in de datadienstspecificatieDSGO.Basis
: Als datadienstaanbieders een datadienstgebruiker wil authenticeren als machine namens partij dan MOET een QSeal gebruikt worden als authenticatie-oplossingDSGO.Basis
: Als datadienstaanbieders een datadienstgebruiker wil authenticeren als mens namens partij OF mens namens zichzelf dan MOET haar keuze voor authenticatie-oplossing(en) worden vastgelegd in de datadienstspecificatie
Betrouwbaarheidsniveau (Level of assurance)
DSGO.Basis
: Als een datadienstaanbieder een menselijke datadienstgebruiker wil authenticeren MOET de datadienstaanbieder in de datadienstspecificatie vastleggen welk eHerkenning betrouwbaarheidsniveau nodig is
Autorisatie
Autorisatiebeleid opstellen
DSGO.Basis
: Datadienstaanbieders MOETEN het autorisatiebeleid bepalen voor elke datadienstDSGO.Basis
: Datadienstaanbieders MOETEN hun autorisatiebeleid vastleggen in de toegangscontroleregels van de datadienstspecificatie
Autorisatie-informatie organiseren
DSGO.Basis
: Als datadienstaanbieders gebruik maken van een access token dan MOET dit worden gedaan volgens het afsprakenstelselDSGO.Basis
: Als datadienstaanbieders gebruik maken van een access token dan MOET dit worden vastgelegd in de datadienstspecificatie
DSGO.Basis
: Datadienstaanbieders ZOUDEN het voor de datarechthebbende mogelijk MOETEN maken haar rechten over data te delegerenDSGO.Basis
: Als datadienstaanbieders het delegeren van rechten mogelijk maakt in haar datadienst dan MOET dit worden vastgelegd in de datadienstspecificatie
DSGO.Basis
: Als datadienstaanbieders gebruik maken van kwalificaties en eigenschappen dan MOET dit worden gedaan volgens het afsprakenstelsel DSGO.Basis
: Als datadienstaanbieders gebruik maken van kwalificaties en eigenschappen dan MOET dit worden vastgelegd in de datadienstspecificatie
Autorisatiebesluit nemen
Datadienstaanbieders ZOUDEN MOETEN handelen naar haar autorisatiebeleid
Oplossingen
Organisatie ID
DSGO.Basis
: Partijen MOETEN een geldig EORI-nummer of KvK-nummer gebruiken als Organisatie IDDSGO.Basis
: Partijen MOETEN een Organisatie ID gebruiken die overeenkomt met eIDAS certificaten die gebruikt worden voor authenticatie, zie Authenticatie voor meer informatie
DSGO.Basis
: Als partijen een KvK-nummer gebruiken als Organisatie ID, dan MOET deze met de prefix “NL.KVK.” worden gebruikt
DSGO.Basis
: Als partijen een EORI-nummer gebruiken als Organisatie ID, dan MOET deze met de prefix “EU.EORI.” worden gebruikt
Transport Layer Security
DSGO.Basis
: Partijen MOETEN API endpoints beveiligen met minimaal TLS v1.2DSGO.Basis
: Partijen ZOUDEN API endpoints MOETEN beveiligen met TLS v1.3DSGO.Basis
: Partijen MOETEN API verzoeken die niet beveiligd zijn met TLS v1.2 of TLS v1.3 afwijzen DSGO.Basis
: Partijen MOETEN voor alle interacties gebruik maken van one-way (server only) TLSDSGO.Basis
: Partijen MOETEN bij toepassing van het TLS protocol certificaten gebruiken met een minimale sleutellengte van 2048 bits en maximale geldigheid van twee jaarDSGO.Basis
: Partijen MOETEN QWACs als certificaat gebruiken voor het one-way (server only) TLS protocolDSGO.Basis
: Partijen MOETEN alle root certificaten voor QWACs van CAs op de EU/EEA List of Trusted Lists (LOTL) en PKIO accepterenDSGO.Basis
: Partijen MOETEN een QWAC gebruiken die overeenkomt met hun Organisatie ID (EORI of KvK-nummer). Zie Identificatie van organisaties voor meer informatie.
Access token
DSGO.Basis
: Als partijen gebruik willen maken van een access token dan, MOETEN ze deze beschikbaar stellen via een /token endpoint
DSGO.Basis
: Partijen MOETEN verifiëren dat het certificaat waarmee de Basis JWT is getekend uitgegeven en ondertekend is door een certificaatautoriteit op de vertrouwde lijst van DSGODSGO.Basis
: Partijen MOETEN verifiëren dat het certificaat waarmee Basis JWT is getekend valide is
DSGO.Basis
: Partijen MOETEN bij elk verzoek om een access token, de identiteit van de aanvrager authenticeren door de identiteit uit het certificaat te vergelijken met die uit het access token verzoek. Indien deze niet matchen met elkaar, MOET het verzoek worden afgewezen.DSGO.Basis
: Partijen MOETEN bij een access token verzoek de status van een partij binnen het DSGO verifiëren bij de stelselcatalogus
Qualified certificates for electronic seal (QSeal)
DSGO.Basis
: Partijen MOETEN QSeals gebruiken voor het tekenen van JWTsDSGO.Basis
: Partijen MOETEN alle root certificaten voor QSeals van uitgevers op de EU/EEA List of Trusted Lists (LOTL) en PKIO accepterenDSGO.Basis
: Partijen MOETEN een QSEAL gebruiken die overeenkomt met hun Organisatie ID (EORI of KvK-nummer). Zie Identificatie van organisaties voor meer informatie.
Authenticatiediensten
Authenticatiediensten MOETEN minimaal het betrouwbaarheidsniveau eH2+ ondersteunen
Delegaties
DSGO.Basis
: Als gedelegeerde datadienstgebruikers een datadienst kunnen afnemen MOETEN datadienstaanbieders in de datadienstspecificatie vaststellen waar delegaties geregistreerd mogen wordenDSGO.Basis
: Als de datarechthebbende gebruik wil maken van de mogelijkheid om haar rechten te delegeren dan MOET de datarechthebbende binnen de opties aangeboden in een datadienst bepalen waar haar delegaties geregistreerd worden
DSGO.Basis
: Datarechthebbende MOETEN deelnemer zijn van het DSGO om haar eigen delegaties te beherenDSGO.Basis
: De datarechthebbende MOET delegatie bewijs beschikbaar stellen volgens een /delegation
endpointDSGO.Basis
: Als een datadienstaanbieder de mogelijkheid biedt voor de datarechthebbende om zelf haar delegaties te beheren dan MOET de datadienstaanbieder datadienstverzoeken met HTTP header delegation_evidence
met een geldige delegationEvidence
object accepteren
DSGO.Basis
: Als een datadienstaanbieder de mogelijkheid biedt voor datarechthebbende om haar delegaties te registreren bij de datadienstaanbieder dan MOET de datadienstaanbieder dit mogelijk maken voor de datarechthebbende
DSGO.Basis
: Als een datadienstaanbieder de mogelijkheid biedt voor datarechthebbende om haar delegaties te registreren bij een autorisatieregister dan MOET dit worden gedaan volgens het afsprakenstelsel
Informatiebeveiliging
JSON Web Tokens (JWT)
DSGO.Basis
: Partijen MOETEN in Authenticatie JWTs de parameters zoals opgesteld in de onderstaande tabel gebruiken als JWT headers DSGO.Basis
: Partijen MOETEN in Onweerlegbaarheid JWTs de parameters zoals opgesteld in de onderstaande tabel gebruiken als JWT headersDSGO.Basis
: Partijen MOGEN in alle JWTs andere parameters NIET als JWT headers gebruiken
DSGO.Basis
: Partijen ZOUDEN in alle JWTs NIET andere JWT claims MOETEN definiëren en gebruiken, afhankelijk van het specifieke gebruik van de JWT
DSGO.Basis
: Partijen MOETEN in alle JWTs de JWT claims opstellen zoals beschreven in de onderstaande tabel volgens RFC7519DSGO.Basis
: Partijen MOETEN in alle JWTs alle JWT claims binnen 30 seconden laten verlopen, aantoonbaar door de combinatie van iat
en exp
claims. DSGO.Basis
: Partijen MOETEN in alle JWTs de JWT claims de iat
en exp
claims noteren in seconden en MOGEN iat
en exp
claims NIET noteren in milliseconden
De handtekening ongeldig is, Deze niet aan hen geadresseerd is, op basis van de Deze niet verlopen is, op basis van de Deze niet eerder ontvangen is, op basis van de DSGO.Basis
: Partijen MOETEN een getekende JWT maar één keer accepterenDSGO.Basis
: Partijen MOETEN een JWT niet accepteren als:aud
claim,exp
claim,jti
claim met inachtneming van de verlooptijd
DSGO.Basis
: Partijen MOGEN gebruik maken van JWE als beschreven in RFC 7516
Ondertekening van JWTs
DSGO.Basis
: Partijen MOETEN het RS256 algoritme gebruiken bij het ondertekenen van alle JWTsDSGO.Basis
: Partijen MOETEN alle JWTs ondertekenen als een JSON Web Signature (JWS) zoals beschreven in RFC 7515DSGO.Basis
: Partijen MOETEN alle getekende Onweerlegbaarheid JWTs formatteren volgens JWS Compact Serialisation
DSGO.Basis
: Partijen MOETEN voor alle Authenticatie JWTs de signing input opstellen volgens RFC 7515: ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload))
DSGO.Basis
: Partijen MOETEN voor alle Onweerlegbaarheid JWTs de Protected HTTP Headers
opstellen voor ondertekening zoals aangegeven in de sigD
JWT headerDSGO.Basis
: Partijen MOETEN voor alle Onweerlegbaarheid JWTs de signing input opstellen als: ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload)) || '.' || BASE64URL(Protected HTTP Headers))
Onweerlegbaarheid
DSGO.Basis
: Als partijen willen dat een verzoek of respons onweerlegbaar is, MOETEN ze de Digest
en client_assertion
HTTP headers toevoegen zoals beschreven in de tabel hieronder
DSGO.Basis
: Als datadienstaanbieders willen dat elke datadienstverzoek onweerlegbaar is, MOETEN ze dit vastleggen in de datadienstspecificatieDSGO.Basis
: Als datadienstaanbieders onweerlegbare datadienstresponsen aanbied, MOETEN ze dit vastleggen in de datadienstspecificatie
Risico Management
Partijen ZOUDEN een risicoanalyse uit MOETEN voeren Partijen ZOUDEN passende informatiebeveiligingsmaatregelen MOETEN nemen Partijen ZOUDEN andere partijen waarmee wordt samengewerkt MOETEN aansporen passende informatiebeveiligingsmaatregelen te nemen
Operationele processen
Change en release management
De Beheerorganisatie DSGO MOET het change en release managementproces begeleiden De Beheerorganisatie DSGO MAG een Request For Change (RFC) voorstel indienen conform het change en release managementproces De Beheerorganisatie DSGO MOET binnen 2 werkdagen na ontvangst van een RFC voorstel een ontvangstbevestiging sturen aan de indienende partij De Beheerorganisatie DSGO MOET een RFC voorstel voorbereiden en de voorgestelde aanpassing verder detaileren om de RFC voor te bereiden voor de Change Advisory Board
De Deelnemersraad MOET het advies over RFCs (ontvangen van de CAB) goed- of af keuren De Change Advisory Board MOET de Deelnemersraad adviseren over RFCs binnen het change en release management proces
Partijen MOGEN een Request For Change (RFC) voorstel indienen conform het change en release managementproces Als een partij een Request For Change (RFC) voorstel indient, dan MOET dit conform de beschikbare templates
De Beheerorganisatie DSGO MAG in het geval van spoed besluiten om af te wijken van het standaard change en release managementproces
De Beheerorganisatie DSGO MAG in het geval van een kleine wijziging, die geen impact heeft op de technische werking of juridische basis, deze uitvoeren zonder het standaard change en release managementproces te doorlopen
Managementrapportage
De Beheerorganisatie DSGO MOET haar managementinformatie in lijn met de SLAs voor de Beheerorganisatie DSGO beschikbaar stellen De Beheerorganisatie DSGO MOET zorgen dat concurrentiegevoelige informatie niet openbaar wordt gemaakt in de managementrapportage De Beheerorganisatie DSGO MOET het gehele managementrapportageproces begeleiden
Marktvoorzieningen MOETEN hun managementinformatie in lijn met de SLAs voor marktvoorzieningen aanleveren aan de Beheerorganisatie DSGO Indien de aangeleverde managementinformatie niet klopt, MOET de marktvoorziening dit binnen 5 werkdagen corrigeren
Registratie technisch conform datadienstaanbieder
Toetreding
De Beheerorganisatie DSGO MOET een toetredende partij door het gehele toetredingsproces begeleiden De Beheerorganisatie DSGO MOET een non-disclosure agreement (NDA) tekenen tijdens het toetreden als de toetredende partij hier om vraagt De Beheerorganisatie DSGO MOET de uitslag van de eerste controle voor alle toetredende partijen binnen een termijn van 5 werkdagen, gerekend vanaf ontvangst van alle benodigde informatie, communiceren met de toetredende partij De Beheerorganisatie DSGO MOET de uitslag van de rol-gerelateerde validatie voor marktvoorzieningen binnen een termijn van 30 werkdagen, gerekend vanaf ontvangst van alle benodigde informatie, communiceren met de toetredende partij De Beheerorganisatie DSGO MOET de uitslag van de rol-gerelateerde validatie voor datadienstaanbieders en technisch conform datadienstaanbieders binnen een termijn van 5 werkdagen, gerekend vanaf ontvangst van alle benodigde informatie, communiceren met de toetredende partij
Een toetredende partij MOET het toetredingsproces voor de rol die ze wil vervullen succesvol doorlopen om de door haar geselecteerde rol(len) in te vullen in het DSGO Een toetredende partij MOET de Deelnameovereenkomst voor de rol die ze wil vervullen tekenen om deelnemer te worden Een toetredende partij MOET de Overeenkomst technische conformiteit tekenen om technisch conform datadienstaanbieder te worden
Toezicht en handhaving
Incidentbeheer
De Beheerorganisatie DSGO MOET binnen een passende tijd een incidentcoördinator aanwijzen na een melding van een incident
Een betrokken partij MOET incidenten direct na ontdekking melden bij de Beheerorganisatie DSGO Een betrokken partij MOET bij melding van een incident de naam van de verondersteld veroorzakende partij met een onderbouwing van de constatering/vermoeden, datum, tijd, ingeschatte incident classificatie en impact op de datadienst melden
De incidentcoördinator MOET het incidentbeheer proces na de melding van een incident coördineren. De incidentcoördinator MOET kunnen optreden als een neutrale partij bij het incident De incidentcoördinator MOET binnen een redelijke termijn een binnengekomen melding beoordelen en een classificatie inschatting maken De incidentcoördinator MOET het incident beoordelen en legt het classificatie niveau vast
De partij die verantwoordelijk is voor het verhelpen of oplossen van incidenten MOET een incidentmanager beschikbaar stellen De incidentmanager ZOU voor alle Prioriteit 1 en Prioriteit 2 incidenten 24u per dag, 7 dagen per week beschikbaar MOETEN stellen De incidentmanager MOET voor een Prioriteit 1 incident een update delen met de incidentcoördinator binnen 2 uur van elke belangrijke update en elke 4 uur bij geen update De incidentmanager MOET voor een Prioriteit 2 incident een update delen met de incidentcoördinator binnen 2 uur van elke belangrijke update aan het einde van elke werkdag bij geen update De incidentmanager MOET voor een Prioriteit 3 incident een volledige update delen met de incidentcoördinator aan het einde van elke werkdag
Handhaving
De Beheerorganisatie DSGO MOET voordat het overgaat tot handhaven de belangen van het DSGO, de betrokken partijen en de deelnemers in overweging nemen en het doel van de maatregel afwegen tegen de gevolgen De Beheerorganisatie DSGO MOET de overtreding beoordelen en legt het classificatie niveau vast De Beheerorganisatie DSGO MAG een handhavende maatregel (waarschuwing, schorsing of uitsluiting) opleggen bij een overtreding om de vertrouwelijkheid en/of integriteit van het DSGO afsprakenstelsel te beschermen
Partijen MOETEN te allen tijde handelen in overeenstemming met het afsprakenstelsel
Versie richtlijnen
De Beheerorganisatie DSGO MOET bij een release van het afsprakenstelsel de wijziging van versienummer bepalen De Beheerorganisatie DSGO MOET releases communiceren middels de versie richtlijnen
Uittreding
De Beheerorganisatie DSGO MOET het uittredingsproces faciliteren voor een uittredende partij De Beheerorganisatie DSGO MOET binnen 5 werkdagen de intentie tot uittreding van een uittredende deelnemer bevestigen
Een partij MOET het uittredingsproces succesvol doorlopen om uit te treden uit het DSGO Een marktvoorziening die uittreedt MOET een uittredingsplan opstellen en (na goedkeuring van Beheerorganisatie DSGO) uitvoeren om uit te treden uit het DSGO
Marktvoorzieningen
Autorisatieregister
Autorisatieregisters MOETEN voldoen aan alle eisen van een Autorization Registry volgens iSHARE (v2.0)
Authenticatiedienst
Authenticatiediensten MOETEN voldoen aan alle eisen van een authenticatiedienst volgens eHerkenning AS1.23a
Certificering
Datadienstbrokers
Aansprakelijkheid bij gebruik datadienstbroker
Datadienstbrokers MOETEN met haar klant afspraken maken over aansprakelijkheid voor mogelijke geleden schade die ontstaat in de uitvoering van daar dienst namens haar klant
Bewijs van gebruik van een datadienstbroker
Datadienstgebruikers MOETEN deelnemer zijn van het DSGO om het gebruik van een datadienstbroker te registreren Datadienstgebruikers MOETEN gebruik van een datadienstbroker registeren bij het toetreden tot het DSGO
De stelselcatalogus MOET brokerbewijs beschikbaar stellen volgens een Datadienstaanbieders MOETEN datadienstverzoeken met HTTP header /brokers
endpointbroker_evidence
met een geldige brokerEvidence
object accepteren
Data minimalisatie datadienstbroker
Datadienstbrokers MOETEN enkel data die nodig is om haar diensten uit te voeren (zoals afgesproken met haar klanten) verzamelen Datadienstbrokers MOETEN enkel data die nodig is om haar diensten uit te voeren (zoals afgesproken met haar klanten) opslaan Datadienstbrokers MOETEN enkel data verwerken als nodig om haar diensten uit te voeren (zoals afgesproken met haar klanten) Datadienstbrokers MOETEN data enkel voor redelijke, en proportionele termijnen opslaan Datadienstbrokers MOETEN data van haar klanten verwijderen wanneer dit wordt aangevraagd
Service level agreements
SLAs voor de Beheerorgansiatie DSGO
De Beheerorganisatie DSGO MOET de developer portal en de stelselcatalogus binnen het openstellingsvenster van 24 uur per dag voor 365 dagen per jaar beschikbaar stellen aan gebruikers De Beheerorganisatie DSGO MOET het developer portal en de stelselcatalogus binnen het openstellingsvenster 99% van de tijd beschikbaar stellen, gepland onderhoud telt niet als onbeschikbaarheid De Beheerorganisatie DSGO MOET het onderhoudsvenster van de developer portal en de stelselcatalogus vastleggen tussen 00:00 en 04:00 De Beheerorganisatie DSGO MOET het onderhoudsvenster van de developer portal en de stelselcatalogus communiceren richting (potentiële) deelnemers en gebruikers van het DSGO De Beheerorganisatie DSGO MAG gepland onderhoud aan de developer portal en de stelselcatalogus op elke tijdstip uitvoeren als er geen uitval wordt verwacht De Beheerorganisatie DSGO MOET gepland onderhoud aan de developer portal en de stelselcatalogus communiceren aan partijen die hier hinder van kunnen ondervinden De Beheerorganisatie DSGO MOET waarborgen dat de stelselcatalogus binnen het beschikbaarheidsvenster op 95% van API verzoeken binnen 2 seconden reageert De Beheerorganisatie DSGO MOET waarborgen dat de stelselcatalogus binnen het beschikbaarheidsvenster op 99% van API verzoeken binnen 5 seconden reageert De Beheerorganisatie DSGO MOET waarborgen dat de stelselcatalogus binnen het beschikbaarheidsvenster ten minste 1000 API verzoeken gelijktijdig kan verwerken De Beheerorganisatie DSGO MOET op een passende frequentie een back-up maken van data belangrijk voor de stelselcatalogus De Beheerorganisatie DSGO MOET de back-ups van de stelselcatalogus opslaan voor een passende periode De Beheerorganisatie DSGO MOET elk kwartaal over eigen managementinformatie rapporteren De Beheerorganisatie DSGO MOET elk kwartaal een managementrapportage opstellen en verspreiden De Beheerorganisatie DSGO MOET voor ondersteuning van deelnemers en gebruikers van het DSGO bereikbaar zijn via e-mail De Beheerorganisatie DSGO MOET binnen één werkdag na ontvangst van een vraag, verzoek of klacht, aangeven dat hiervan kennis is genomen De Beheerorganisatie DSGO ZOU binnen vijf werkdagen na ontvangst van een vraag, verzoek of klacht deze MOETEN oplossen of beantwoorden met een onderbouwde reactie
SLAs voor datadienstaanbieders
Datadienstaanbieders MOETEN het openstellingsvenster van de datadienst definiëren en beschikbaar stellen aan datadienstgebruikers Datadienstaanbieders MOETEN het onderhoudsvenster van de datadienst definiëren en beschikbaar stellen aan datadienstgebruikers Datadienstaanbieders MOETEN het onderhoudsvenster plannen buiten reguliere kantooruren Datadienstaanbieders MOGEN gepland onderhoud uitvoeren op elke tijdstip, als er geen uitval wordt verwacht Datadienstaanbieders ZOUDEN datadiensten binnen het beschikbaarheidsvenster minimaal 95% van de tijd beschikbaar MOETEN stellen aan datadienstgebruikers
Datadienstaanbieders ZOUDEN op 95% van API verzoeken binnen 2 seconden MOETEN reageren binnen het beschikbaarheidsvenster Datadienstaanbieders ZOUDEN op 99% van API verzoeken binnen 5 seconden MOETEN reageren binnen het beschikbaarheidsvenster Datadienstaanbieders ZOUDEN ten minste 100 API verzoeken gelijktijdig MOETEN kunnen verwerken binnen het beschikbaarheidsvenster
Datadienstaanbieders ZOUDEN op een passende frequentie een back-up MOETEN maken van data belangrijk voor de datadienst Datadienstaanbieders ZOUDEN de back-ups MOETEN opslaan voor een passende periode
Datadienstaanbieders ZOUDEN bereikbaar MOETEN zijn voor ondersteuning via e-mail Datadienstaanbieders ZOUDEN binnen een werkdag na ontvangst van een vraag, verzoek of klacht MOETEN aangeven dat hiervan kennis is genomen Datadienstaanbieders ZOUDEN binnen vijf werkdagen na ontvangst van een vraag, verzoek of klacht deze MOETEN beantwoorden of oplossen
Datadienstaanbieders MOETEN aan alle releasebeheer eisen voldoen
SLAs voor marktvoorzieningen
Marktvoorzieningen MOETEN diensten binnen het openstellingsvenster van 24 uur per dag voor 365 dagen per jaar beschikbaar stellen aan gebruikers Marktvoorzieningen MOETEN het onderhoudsvenster van de dienst, inclusief definiëring van de datum, tijd en getroffen dienst(en), ten minste 10 werkdagen voor het onderhoud aankondigen aan de betrokken partijen Marktvoorzieningen MOETEN het onderhoudsvenster plannen op de nachten van vrijdag op zaterdag en van zaterdag op zondag, van 00:00-5.59u Marktvoorzieningen MOGEN gepland onderhoud uitvoeren op elke tijdstip, als er geen uitval wordt verwacht Marktvoorzieningen MOETEN diensten binnen het beschikbaarheidsvenster van minimaal 99% van de tijd beschikbaar stellen aan gebruikers Marktvoorzieningen MOETEN op 95% van API verzoeken binnen 2 seconden reageren binnen het beschikbaarheidsvenster Marktvoorzieningen MOETEN op 99% van API verzoeken binnen 5 seconden reageren binnen het beschikbaarheidsvenster Marktvoorzieningen MOETEN ten minste 100 API verzoeken gelijktijdig kunnen verwerken binnen het beschikbaarheidsvenster Markvoorzieningen MOETEN op een passende frequentie een back-up maken van data belangrijk voor de dienst Marktvoorzieningen MOETEN de back-ups opslaan voor een passende periode Marktvoorzieningen MOETEN bereikbaar zijn voor ondersteuning via e-mail Marktvoorzieningen MOETEN binnen één werkdag na ontvangst van een vraag, verzoek of klacht aangeven dat hiervan kennis is genomen Marktvoorzieningen MOETEN binnen vijf werkdagen na ontvangst van een vraag, verzoek of klacht deze beantwoorden of oplossen
Marktvoorzieningen MOETEN aan alle releasebeheer eisen voldoen
Marktvoorzieningen MOETEN elke maand de managementinformatie verzamelen, startend om 0.00u op de 1e dag tot 23.59u op de laatste dag van de maand
Marktvoorzieningen MOETEN elke maand de managementinformatie over de afgelopen maand aanleveren aan de Beheerorganisatie DSGO, voor 23:59u op de 5e werkdag van de lopende maand
Technische interoperabiliteit
Datadienstaanbieders MOETEN alle Technisch conforme datadienstaanbieders MOETEN alle Partijen MOGEN NIET bilaterale afspraken maken die een conflict oplevert met de DSGO.Basis
afspraken volgenDSGO.Basis
afspraken volgenDSGO.Basis
afspraken van het DSGO