...
Voorheen was het verboden te werken met refresh-tokens, nu is dit verplicht voor alle deelnemers. Als de Persoon toestemming geeft voor lange duur, dan wordt door de Dienstverlener aanbieder een access-token en een refresh-token uitgegeven. De maximale leeftijd van dit refresh-token is 6 maanden. Binnen deze periode kan de Dienstverlener persoon het refresh-token inwisselen voor een nieuw access-token en een nieuw refresh-token. Dit gebeurt op de token-interface en deze wordt in plaats van een authorization-code meegestuurd. Een refresh-token is eenmalig te gebruiken, dus bij gebruik moet de Dienstverlener aanbieder deze direct vervangen voor een nieuwe. Refresh-tokens zijn maximaal 6 maanden geldig. Na het verlopen van deze termijn moet de Persoon opnieuw inloggen en toestemming geven. Informatie over de uitwisseling van de code en de tokens is te vinden in hoofdstuk autorisatie in de Core van het afsprakenstelsel en in de beschrijvingen van de Authorization interface.
...
De Dienstverlener persoon mag de Persoon automatische uitwisseling aanbieden. De Persoon hoeft zelf de functie niet meer te starten, maar kan dit overlaten aan de Dienstverlener persoon. Idealiter wordt dit gedaan vanuit een verkregen notificatie, waarbij de functie abonneren nodig is. Omdat dit nog beperkt wordt aangeboden, is ervoor gekozen dat de Dienstverlener persoon periodiek gegevens mag ophalen. Hiervoor zijn nieuwe verantwoordelijkheden opgesteld, waardoor de Dienstverlener persoon beperkt wordt in de mogelijkheden. Deze verantwoordelijkheden zijn te vinden in het hoofdstuk gegevensuitwisseling in de Core van het afsprakenstelsel.
Automatische uitwisseling mag alleen plaatsvinden op actieve accounts. Daarom is toegevoegd dat een DVP account de status ‘inactief' moet krijgen, zodra deze een half jaar niet is gebruikt. Voor accounts met de status ‘inactief’ mag geen gebruikgemaakt worden van langdurige toestemmingen. De Dienstverleners persoon moeten voldoen aan deze nieuwe verantwoordelijkheden, zoals beschreven in het hoofdstuk Account bij de Dienstverlener persoon in de Core van het afsprakenstelsel.
5.2.2.5. Beheer van de toestemmingen
...
In het normenkader is toegevoegd dat een code review uitgevoerd moet worden door de auditor om te controleren of codes en tokens aan de uniciteitseisen voldoen. Dit betekent niet dat alle code van de deelnemers gecontroleerd moet worden, maar alleen het deel dat verantwoordelijk is voor de uitgifte van codes en tokens. De eis dat tokens en codes uniek moeten zijn, staat beschreven in verantwoordelijkheid core.autorisatie.208.
5.4. Logging-monitoring en rapporteren
...