Dit document valt onder de volgende licentie:
Creative Commons Attribution 4.0 International Public License
Het verzamelen van gegevens over actuele betalingsverplichtingen is voor burgers die in schuldhulpverlening terecht komen een grote drempel. Met het project Vorderingenoverzicht Rijk leveren we een bijdrage aan het verlagen van die drempel, zodat problemen met betalingen en schulden sneller kunnen worden opgelost of worden voorkomen. Het is daarom onze missie om burgers in staat te stellen gemakkelijk een overzicht van hun financiële verplichtingen aan overheidsorganisaties te verkrijgen, zodat zij hun eigen situatie kennen. Deze missie is samengevat in de volgende user story:
"Als burger wil ik een overzicht van mijn actuele betalingsverplichtingen aan overheidsorganisaties zien, zodat ik mijn situatie ken en op basis hiervan (direct) de noodzakelijke of gewenste acties kan ondernemen."
Op basis van een makkelijker en beter overzicht kan de burger als dat nodig is de noodzakelijke of gewenste acties ondernemen. Het overzicht vormt daarmee een belangrijk hulpmiddel voor burgers om meer grip te krijgen op hun financiële situatie en in actie te kunnen komen, eventueel samen met een hulpverlener. In andere gevallen kan het overzicht mensen het inzicht geven, dat er geen actuele risico's zijn. Het Vorderingenoverzicht is er in ieder geval voor iedereen, voor alle burgers van Nederland.
Dit is een werkversie die op elk moment kan worden gewijzigd, verwijderd of vervangen door andere documenten. Het is geen goedgekeurde consultatieversie.
Deze standaard beschrijft twee protocollen:
configurationToken voor gebruik in het tweede protocol.configurationToken uit het eerste protocol in voor de financiële informatie.Beide protocollen maken gebruik van het CreateSession protocol uit de Blauwe Knop Connect standaard voor het authenticeren van de App naar de organisatie. Beide keren levert dat een sessionToken op, en een AES sleutel voor versleuteling van het verkeer tussen de App en organisatie. De App verstuurt het sessionToken mee met zijn berichten aan de organisatie, welke deze gebruikt om de relevante sessie-informatie op te zoeken wat is vastgesteld tijdens het CreateSession protocol. Daarbij is het van belang dat hij ook controleert dat de sessie inmiddels niet verlopen is, en dat de scope parameter de verwachte waarde heeft.
Dit toepassingsprofiel beschrijft de specifieke implementatiekeuzes die zijn gemaakt voor het Vorderingenoverzicht Rijk binnen het Blauwe Knop Connect framework.
Het Vorderingenoverzicht Rijk is georganiseerd als een ketendienst waarbij meerdere overheidsorganisaties participeren om burgers inzicht te geven in hun financiële verplichtingen.
Voor het Vorderingenoverzicht Rijk treedt een aangewezen stelselbeheerder op die verantwoordelijk is voor:
Organisaties die willen deelnemen aan het Vorderingenoverzicht Rijk MOETEN:
De stelselbeheerder MOET deelname goedkeuren voordat een organisatie onderdeel wordt van het stelseldocument.
Het stelseldocument voor het Vorderingenoverzicht Rijk MOET de volgende JSON-structuur hebben:
{
"organizations": [
{
"oin": "00000001003214345000",
"name": "Organisatie Naam",
"discovery_url": "https://organisatie.nl/.well-known/bk-configuration.json",
"public_key": {
"kty": "EC",
"crv": "P-256",
"x": "...",
"y": "..."
},
"logo_url": "https://organisatie.nl/logo.png"
}
],
"app_managers": [
{
"oin": "00000001001234567000",
"name": "App Manager Naam",
"discovery_url": "https://appmanager.nl/.well-known/bk-configuration.json",
"public_key": {
"kty": "EC",
"crv": "P-256",
"x": "...",
"y": "..."
}
}
],
"document_types": [
{
"name": "REQUEST_DOCUMENT"
},
{
"name": "FINANCIAL_CLAIMS_INFORMATION_DOCUMENT"
}
]
}
Het stelseldocument MOET:
Elke deelnemende bronorganisatie MOET een vindbaarheidsconfiguratie publiceren op het pad /.well-known/bk-configuration.json met de volgende structuur:
{
"financialClaimRequestApi": {
"v4": "http://financial-claim-request-api.organisatie.nl/v4"
},
"sessionApi": {
"v2": "http://session-api.demo.bk-manager.organisatie.nl/v2"
}
}
Elke deelnemende app manager MOET een vindbaarheidsconfiguratie publiceren op het pad /.well-known/bk-connect-services met de volgende structuur:
{
"sessionApi": {
"v2": "http://session-api.appmanager.nl/v2"
},
"registrationApi": {
"v2": "http://registration-api.appmanager.nl/v2"
},
"appManagerUi": "http://app-management-ui.appmanager.nl/login"
}
v1, v2, etc.Organisaties MOGEN:
Voor het Vorderingenoverzicht Rijk wordt Logius als App Manager ingezet, waarbij:
Het toepassingsprofiel MAG in de toekomst worden uitgebreid met:
App Manager credentials MOETEN:
Voor de financiële informatie worden de volgende documenttypen gebruikt:
REQUEST_DOCUMENT: Verzoeken om financiële informatieFINANCIAL_CLAIMS_INFORMATION_DOCUMENT: Antwoorden met financiële informatieDe specifieke structuur van deze documenten is beschreven op: https://vorijk.nl/docs/financiele-verplichtingen/document_types/financial_claims_information_document/
De specifieke implementatie van de ConfigureRequest en RequestFinancialInformation protocollen wordt beschreven in de specificaties sectie van deze standaard.
Bij het gebruik van het CreateSession protocol MOET de scope parameter de waarde "nl.vorijk.oauth_scope.blauwe_knop" hebben om aan te geven dat de sessie wordt gebruikt voor het opvragen van financiële informatie.
De sectie over cryptografie uit de Blauwe Knop Connect standaard is ook van toepassing in deze standaard.
De protocollen in deze standaard faciliteren het uitwisselen van al of niet digitaal ondertekende documenten tussen de app en de organisatie. Een Document is een in deze standaard gedefinieerde datastructuur, met daarin in elk geval de volgende velden:
type (verplicht): een string die het type van dit document aanduidt, bijvoorbeeld "FINANCIAL_CLAIMS_INFORMATION_REQUEST".version (optioneel): een string met een decimaal getal erin, die de versie van de datastructuur aangeeft.body (optioneel): een datastructuur waarvan de structuur afhangt van de waarde van type.Een Document MAG ondertekend worden, wat in dat geval in de vorm van een JWS MOET zijn, met "document" als de waarde van de sub parameter. De kid parameter MAG gebruikt worden in de JWS header en MOET indien aanwezig een string zijn.
Voorbeeld van een Document JWS (met newlines enkel voor leesbaarheid):
eyJ0eXAiOiJqd3QiLCJhbGciOiJFUzI1NiIsImtpZCI6IjEifQ.eyJzdWIiOiJkb2N1bWVudCIsInR5
cGUiOiJFWEFNUExFX0RPQ1VNRU5UX1RZUEUiLCJ2ZXJzaW9uIjoiMSIsImJvZHkiOnsiZm9vIjoiYmF
yIn19.EHcxxbaDLX0MkrJvlg6kQ3ENgmV9ndEYp5eaFF6MnHcumH_9mfMVCTJtxwf9zSdqtZ2gRMnKp
n-e9OPPaeiGdA
De inhoud van deze JWS (zie ook https://jwt.io) is als volgt (zie de Cryptografie sectie in de Blauwe Knop Connect standaard voor een uitleg van de hier gebruikte notatie):
{
"typ": "jwt",
"alg": "ES256",
"kid": "1"
}
.
{
"sub": "document",
"type": "EXAMPLE_DOCUMENT_TYPE",
"version": "1",
"body": {
"foo": "bar"
}
}
Deze JWS kan geverifieerd worden met de volgende public key:
{
"kty": "EC", "crv": "P-256",
"x": "T5PP_Q1prhqQoBH5tgXkfrLGV5wrB8HuANJZezYP5m8",
"y": "dtALK0t1e3dJXGyYgiyRrqONAQhi2LjFYYh9S5GqHyg"
}
In het ConfigureRequest protocol geeft de App middels een digitaal ondertekend Document aan dat de burger financiële informatie op wil gaan vragen.
Het resulteert in een configurationToken die de organisatie aan de App verstuurt waarmee deze later de daadwerkelijke financiële informatie op kan vragen, in het RequestFinancialInformation protocol.
Het protocol kent de volgende participanten:
CitizenFinancialClaimProcess is een proces in de vorm van een HTTP server die draait bij de organisatie.
Deze ontvangt en verwerkt verzoeken van de App, en slaat resulterende informatie op in de FinancialClaimRequestService voor later.FinancialClaimRequestService is een database die draait bij de organisatie.De App en het CitizenFinancialClaimProcess maken aan het begin van het protocol gebruik van het CreateSession protocol voor het authenticeren van de App naar de organisatie en het produceren van een AES sleutel voor versleuteling van het verkeer tussen de App en organisatie.
De stappen van dit protocol worden hier niet expliciet getoond of uitgeschreven.
Het protocol ziet er in een sequence diagram als volgt uit.
ConfigureRequest protocolEr volgt een expliciete beschrijving van de protocolberichten, die refereert aan de genummerde stappen in bovenstaand sequence diagram. Alle whitespace in JSON structuren is enkel bedoeld voor de leesbaarheid van deze standaard en dient niet te worden opgenomen in implementaties.
De App gebruikt het CreateSession protocol uit de Blauwe Knop Connect standaard voor authenticatie, resulterend in een sessionToken en een AES key voor later gebruik.
De App stelt een Document JWS samen (zie de sectie over Documenten hierboven), met "FINANCIAL_CLAIMS_INFORMATION_REQUEST" als type, en zonder version en body.
Voorbeeld:
{
"typ": "jwt",
"alg": "ES256"
}
.
{
"sub": "document",
"type": "FINANCIAL_CLAIMS_INFORMATION_REQUEST"
}
De App versleutelt het Document JWS met de AES key van de sessie in de vorm van een JWE (zie de Cryptografie sectie in de Blauwe Knop Connect standaard).
De App verstuurt het versleutelde Document JWS naar de CitizenFinancialClaimsProcess middels een HTTP POST met de volgende inhoud:
Authorization: het sessionToken uit stap 1.POST body: het versleutelde Document JWS.Voorbeeld:
POST /configure_claims_request HTTP/1.1
Host: organization.example.com
Authorization: 9YryEzKheqpx5iS2JsDNRHoydCBIsAKV
eyNaIioBb2_Jhb...x5Nz-g
De CitizenFinancialClaimProcess genereert met een CSPRNG een willekeurige alfanumerieke configuration token die minimaal 22 karakters MOET zijn (zodat hij minimaal 128 bit entropie heeft).
De CitizenFinancialClaimsProcess maakt een JSON object met daarin de volgende velden:
sub: MOET de vaste waarde configuration_token hebben.iss: de URL van de CitizenFinancialClaimsProcess.configuration_token: het configuration_token uit stap 8.Voorbeeld:
{
"sub": "configuration_token",
"iss": "https://citizen-financial-claims-process.example.com/",
"configuration_token": "LarRGSbmUPYtRYO6BQ4yn8"
}
De CitizenFinancialClaimsProcess versleutelt dit JSON object met de AES key van de sessie in de vorm van een JWE (zie de Cryptografie sectie in de Blauwe Knop Connect standaard), en stuurt dat in de HTTP response behorende bij het HTTP request uit Stap 5 terug naar de app.
De App ontsleutelt de JWE met de session AES key, en valideert dat:
iss en sub de waardes zoals daar gespecificeerd.Middels het RequestFinancialInformation protocol kan de burger financiële informatie opvragen.
Het resulteert in een door de organisatie digitaal ondertekend Document met daarin de financiële informatie.
Dit protocol kan alleen worden uitgevoerd als de App en organisatie eerder het ConfigureRequest protocol hebben uitgevoerd, zodat de App beschikking heeft over een configurationToken.
Daarnaast maken ook in dit protocol (net als ConfigureRequest) de App en het CitizenFinancialClaimProcess gebruik van het CreateSession protocol voor het authenticeren van de App naar de organisatie en het produceren van een AES sleutel voor versleuteling van verder verkeer tussen de App en organisatie.
(De ConfigureRequest en RequestFinancialInformation protocollen hebben ieder een eigen authenticatiesessie nodig: dat wil zeggen, het sessionToken resulterende uit het CreateSession protocol dat werd uitgevoerd tijdens het ConfigureRequest protocol kan niet worden hergebruikt in het RequestFinancialInformation protocol.
In plaats daarvan moet CreateSession opnieuw worden uitgevoerd.)
Dit protocol kent dezelfde participanten als het ConfigureRequest protocol, en daarnaast ook de volgende participant:
SourceSystem: een systeem van de organisatie die financiële informatie van burgers beheert, en ter beschikking stelt aan andere systemen van de organisatie.Net als in het ConfigureRequest protocol wordt het sessionToken gebruikt als identifier voor de sessie.
Deze wordt niet op applicatielaag versleuteld (uiteraard wel op transportniveau middels TLS), omdat de organisatie middels het sessionToken de AES key moet opzoeken die voor versleuteling gebruikt kan worden.
Het configurationToken en al het verdere verkeer wordt echter wel op applicatielaag versleuteld opgestuurd (en daarnaast nog eens middels TLS).
Het protocol ziet er in een sequence diagram als volgt uit.
RequestFinancialInformation protocolEr volgt een expliciete beschrijving van de protocolberichten, die refereert aan de genummerde stappen in bovenstaand sequence diagram. Alle whitespace in JSON structuren is enkel bedoeld voor de leesbaarheid van deze standaard en dient niet te worden opgenomen in implementaties.
De App gebruikt het CreateSession protocol uit de Blauwe Knop Connect standaard voor authenticatie, resulterend in een sessionToken en een AES key voor later gebruik.
De App maakt een JSON object met daarin de volgende velden:
sub: MOET de vaste waarde configuration_token hebben.iss: MOET de vaste waarde bk-connect://app/ hebben.configuration_token: het configuration_token uit het ConfigureRequest protocol.Voorbeeld:
{
"sub": "configuration_token",
"iss": "bk-connect://app/",
"configuration_token": "LarRGSbmUPYtRYO6BQ4yn8"
}
Vervolgens versleutelt de App dit object met de session AES key uit het CreateSession protocol in de vorm van een JWE (zie de Cryptografie sectie in de Blauwe Knop Connect standaard).
De App verstuurt een HTTP POST naar de CitizenFinancialClaimsProcess met de volgende inhoud:
configurationToken: De JWE uit stap 2.Authorization: het sessionToken uit stap 1.Voorbeeld:
POST /request_financial_claims_information?configurationToken=eylNzToF_nyZU... HTTP/1.1
Host: organization.example.com
Authorization: 9YryEzKheqpx5iS2JsDNRHoydCBIsAKV
Het CitizenFinancialClaimsProcess ontsleutelt de JWE met de session AES key, en valideert dat:
iss en sub de waardes zoals daar gespecificeerd.Het CitizenFinancialClaimsProcess doet een HTTP POST request naar /financial_claims_information van het SourceSystem om financiële informatie op te vragen, met in de POST body een JSON object met daarin:
bsn: Het BSN in de vorm van een string.Voorbeeld:
POST /financial_claims_information HTTP/1.1
Host: sourcesystem.example.com
{
"bsn": "999991772"
}
NB: toegang tot het /financial_claims_information endpoint MOET geauthenticeerd zijn zodat enkel geauthoriseerde diensten waaronder het CitizenFinancialClaimsProcess er toegang toe hebben.
Deze authenticatie valt buiten de scope van deze standaard, maar te denken valt aan een Authorization HTTP header met daarin een voorgeconfigureerd token, of het bereikbaar maken van het endpoint enkel binnen een intern netwerk van de organisatie, of tweezijdig TLS, of een combinatie van deze maatregelen.
Het SourceSystem antwoordt met een JSON object met daarin de financiële informatie.
De CitizenFinancialClaimsProcess stelt op basis van de response van het SourceSystem die hij heeft geraadpleegd een Document JWS samen (zie de sectie over Documenten hierboven), met "FINANCIAL_CLAIMS_INFORMATION_RESPONSE" als type, en de financiële informatie in de body.
Voorbeeld:
{
"typ": "jwt",
"alg": "ES256",
"kid": "1"
}
.
{
"sub": "document",
"type": "FINANCIAL_CLAIMS_INFORMATION_RESPONSE",
"version": "2",
"body": {
// financial document as returned by the SourceSystem
}
}
De CitizenFinancialClaimsProcess versleutelt bovenstaande Document JWS met de AES key van de sessie in de vorm van een JWE (zie de Cryptografie sectie in de Blauwe Knop Connect standaard), en stuurt dat in de HTTP response behorende bij het HTTP request uit Stap 3 terug naar de app.
In het Vorderingenoverzicht Rijk stelsel moeten participanten voordat ze gegevens op een veilige manier met elkaar kunnen uitwisselen informatie over elkaar kunnen opzoeken. De Blauwe Knop Connect standaard, waarvan deze specificatie een toepassingsprofiel is, mandateert dat informatie over participanten beschikbaar wordt gesteld middels een stelseldocument. Dit stelseldocument stelt participanten in staat om elkaar te kunnen vinden en om informatie over elkaar te kunnen opzoeken.
Het stelseldocument van Vorderingenoverzicht Rijk noemen we het scheme.
Het scheme wordt beheerd, digitaal ondertekend, en online beschikbaar gesteld in de vorm van een HTTP API door de stelselbeheerder. Deze sectie specificeert de inhoud van het scheme, en hoe het gebruikt moet worden.
Om ervoor te zorgen dat gebruikers van het scheme de authenticiteit van de inhoud ervan kunnen valideren wordt, zoals vereist in de Blauwe Knop Connect standaard, het scheme digitaal ondertekend door de stelselbeheerder. Deze sectie beschrijft de werking daarvan. Op alle hier beschreven digitale handtekeningen is de corresponderende sectie uit de Blauwe Knop Connect standaard van toepassing.
Het scheme is een JSON datastructuur die ondertekend MOET worden in de vorm van een JWS.
Het scheme wordt middels de volgende keys ondertekend.
Doordat twee keys gebruikt wordt in plaats van één wordt de scheme root key slechts zeer zelden gebruikt, namelijk alleen wanneer de stelselbeheerder overgaat naar een nieuwe scheme signing key. Doordat deze key zeer weinig gebruikt wordt en ook beveiligd is opgeslagen in een HSM kan de scheme root key een lange levensduur krijgen (10 jaar).
Wanneer een app of organisatie content ophaalt vanaf het scheme, MOET deze content geverifieerd worden zoals aangegeven in onderstaand diagram. (Dit diagram is geschreven vanuit het perspectief van de app, maar voor organisaties werkt het op dezelfde manier.)
Uitgeschreven loopt het proces als volgt.
Haal de scheme signing key JWS op vanuit het scheme middels GET /fetch_scheme_signing_public_key.
Verifieer de scheme signing key JWS tegen de scheme root public key, en verifieer dat de sub in de JWS body de vaste waarde scheme-signing-key bevat.
Parse de scheme signing public key die bevat is in JWK formaat in het jwk veld van de body van de scheme signing key JWS.
Haal de gewenste content op vanuit het scheme. Deze content is in de vorm van een JWS.
Verifieer de ontvangen JWS tegen de scheme signing key JWS.
De scheme signing key JWS bevat de scheme signing public key, en is getekend door de scheme root private key. De JWS MOET de volgende velden bevatten:
sub: MOET de vaste waarde scheme-signing-key hebben.iat: Unix timestamp van het moment van creatie van deze JWS.jwk: de scheme signing public key in JWK formaat (RFC 7517).
In dit object MOET de kid van de scheme signing public key worden opgenomen.Voorbeeld:
{
"typ": "jwt",
"alg": "ES256",
"kid": "<scheme-root-key-kid>"
}.{
"sub": "scheme-signing-key",
"iat": 1749492651,
"jwk": {
"kty": "EC", "alg": "ES256", "crv": "P-256",
"kid": "<scheme-signing-key-kid>",
"x": "2xJs8w74D4glCnAF5W8Ax9EJf6XGSLCTlotBDrMbRd0",
"y": "YQtuD1-gqVB6XDWIr76jRYL2xNr7YdnV1V7hGogwHgw"
}
}
De payload van de scheme JWS is een JSON object die de volgende velden MOET bevatten.
appManagers: JSON array die App Managers bevat, welke worden gespecificeerd door JSON objecten met daarin de volgende velden:oin: het Organisatie-identificatienummer
van de App Manager.name: de naam van de App Manager.discoveryUrl: URL naar de vindbaarheidsconfiguratie van de App Manager.publicKey: JSON array welke minstens één maar mogelijk meer public keys van de App Manager bevat. Zie de "Keys in het scheme" sectie voor details.revocationPublicKey: JSON array welke minstens één maar mogelijk meer public keys bevat waarmee de App Manager eerder uitgegeven Verifiable Credentials kan terugtrekken. Zie de "Keys in het scheme" sectie voor details.organizations: JSON array die Organisaties bevat, welke worden gespecificeerd door JSON objecten met daarin de volgende velden:oin, name, discoveryUrl, publicKey: zoals hierboven.logoUrl (optioneel): URL naar een logo van de participant.documentTypes: JSON array die documenttypes bevat, bestaande uit JSON objecten met daarin de volgende velden:name: naam van het documenttype.Voorbeeld:
{
"appManagers": [ // aka Credential Issuers
{
"oin": "00000001111111110000",
"name": "Application Manager Service",
"discoveryUrl": "https://manager.example.com/discovery",
"publicKey": [
// zie hieronder
],
"revocationPublicKey": [
// zie hieronder
]
}
],
"organizations": [ // aka Verifiers
{
"oin": "00000001234567890000",
"name": "Example Organization",
"discoveryUrl": "https://api.example.org/discovery",
"publicKey": [
// zie hieronder
],
"logoUrl": "https://example.org/logo.png"
},
],
"documentTypes": [
{ "name": "FINANCIAL_CLAIMS_INFORMATION_REQUEST" },
{ "name": "FINANCIAL_CLAIMS_INFORMATION_RESPONSE" }
]
}
Elke participant in het stelsel die gebruik maakt van de Blauwe Knop Connect standaard gebruikt een public/private keypair tijdens interacties met andere partijen.
Deze keypairs spelen een centrale rol in het CreateSession protocol uit de Blauwe Knop Connect standaard, die wordt gebruikt voor authenticatie en ten grondslag ligt aan bovenstaande protocollen.
Keypairs kunnen verlopen (expiry), en kunnen teruggetrokken (gerevoked) worden.
In die gevallen moeten ze niet meer gebruikt worden.
Voor de Verifiable Credentials van Apps specificeert de Blauwe Knop Connect standaard hoe revocatie en expiry werkt. In deze sectie wordt gespecificeerd hoe revocatie en expiry van de keypairs van de andere partijen werkt.
In de "Scheme-inhoud" sectie staat beschreven dat App Managers en Organisaties worden gespecificeerd in het scheme middels JSON objecten in de appManagers en organizations arrays, respectievelijk.
De inhoud hiervan kan verschillen per type participant, maar er MOET in elk geval een publicKey veld aanwezig zijn, welke een JSON array bevat van JSON objecten met daarin de volgende parameters:
jwk: de public key van de participant in JWK formaat (RFC 7517).exp: Unix timestamp van het moment van verlopen van deze public key.revokedSince (optioneel): Unix timestamp die aangeeft vanaf welk moment deze public key teruggetrokken is.
Indien afwezig is de public key niet teruggetrokken.
Indien aanwezig geeft de waarde ervan, welke in het verleden of in de toekomst MAG liggen, aan vanaf wanneer deze public key is teruggetrokken.In het geval van App Managers MOET er ook een revocationPublicKey veld aanwezig zijn, bestaande uit een JSON array van JSON objecten zoals gespecificeerd hierboven, maar zonder revokedSince veld.
Voorbeeld:
{
"oin": "00000009876543210000",
"name": "Some Scheme Participant",
"publicKey": [
{
"jwk": {
"kty": "EC", "alg": "ES256", "crv": "P-256",
"kid": "some-scheme-participant-key-0",
"x": "2xJs8w74D4glCnAF5W8Ax9EJf6XGSLCTlotBDrMbRd0",
"y": "YQtuD1-gqVB6XDWIr76jRYL2xNr7YdnV1V7hGogwHgw"
},
"exp": 1800000000,
"revokedSince": 1755000000 // optional
}
// ... possibly more keys to facilitate key rollover
],
"revocationPublicKey": [ // only in case of Issuers
{
"jwk": {
"kty": "EC", "alg": "ES256", "crv": "P-256",
"kid": "some-scheme-revocation-key-0",
"x": "m3Q_pB4x4l9H-MlbpOIuMP2ImSuAyi6wvGOeGPk4MqI",
"y": "srjFNXeRLQMY7iwnoRO4aiR6tsaWudoHdNhvlVDr-G0",
},
"exp": 1800000000,
}
// ... possibly more keys to facilitate key rollover
]
}
Elke public key van een participant die valideert volgens onderstaande regels MAG gebruikt worden door de participant.
Voor elke key in het scheme kan gevalideerd worden dat deze geldig was op een bepaald moment als volgt.
exp veld aanwezig is, en dat deze later is dan het moment waarop de key geldig moet zijn.revokedSince veld afwezig is, of in de toekomst ligt ten opzichte van het moment van gebruik van de public key.(Merk op dat voor validatie van Issuer keys tijdens verificatie van Verifiable Credentials deze twee momenten niet hetzelfde zijn, zie de "Validatie van Issuer keys tijdens verificatie van Verifiable Credentials" sectie in de Blauwe Knop Connect specificatie.)
Als een van deze checks faalt MOET de public key NIET worden gebruikt.
Naast onderdelen die als niet normatief gemarkeerd zijn, zijn ook alle diagrammen, voorbeelden, en noten in dit document niet normatief. Verder is alles in dit document normatief.
De trefwoorden MAG, MOET, MOETEN en MOGEN in dit document moeten worden geïnterpreteerd als in BCP 14 [RFC2119] [RFC8174] als, en alleen als deze in hoofdletters zijn weergegeven, zoals hier getoond.