3. Prérequis et détails techniques

3.1. Enregistrement des acteurs

Les acteurs PSD2 doivent être enregistrés par une autorité d'enregistrement. Les informations collectées doivent être accessibles aux autres acteurs afin d'assurer confiance et interopérabilité.

Un acteur non enregistré ne peut pas interagir avec un autre acteur.

Chaque acteur doit disposer d'au moins un certificat eIDAS (QWAC), pour TLS 1.2, délivré par un prestataire de services de confiance qualifié (QTSP) enregistré.

La liste des QTSP de la Commission européenne peut être consultée à l'URL suivante :

https://esignature.ec.europa.eu/efda/tl-browser/#/screen/home

3.2. Authentification croisée et chiffrement des données

L'API STET PSD2 repose sur le protocole TLS 1.2 afin d'obtenir une authentification croisée entre acteurs. De plus, ce protocole assure également la confidentialité des données lors de leur transport sur le réseau.

Chaque fois qu'un TPP se connecte en tant que client à un service d'API d'un ASPSP, il vérifie le certificat serveur de l'ASPSP (QWAC) et présente son propre certificat eIDAS (QWAC) en respectant la spécification technique ETSI/TS119495.

L'identification de l'organisation (Organizational Identification) au sein du Subject Distinguished Name du certificat doit en réalité être considérée comme un numéro d'autorisation (Authorization Number) qui respectera les règles de format suivantes :

« PSD » comme référence de type d'identité de personne morale sur 3 caractères ;
code pays ISO 3166 [7] sur 2 caractères représentant le pays de la NCA ;
trait d'union « - » (0x2D (ASCII), U+002D (UTF-8)) ; et
identifiant de NCA sur 2 à 8 caractères (A-Z majuscules uniquement, sans séparateur) ;
trait d'union « - » (0x2D (ASCII), U+002D (UTF-8)) ; et
identifiant du PSP (numéro d'autorisation tel que spécifié par la NCA).

En cas d'échec d'authentification, d'un côté ou de l'autre, la connexion doit être fermée.

Aucune fonction supplémentaire de chiffrement ou d'authentification n'est requise.

3.3. Approches d'authentification du client

Trois approches différentes peuvent être utilisées par un TPP pour permettre l'authentification du PSU par l'ASPSP. Ces approches reposent sur une identification du PSU qui doit être pertinente pour l'ASPSP (identifiant national ou identifiant client de la banque).

Ces approches sont mises en œuvre de différentes manières, selon le cas d'usage concerné :

soit pendant le processus d'autorisation (cf. §3.4.2), principalement pour les cas d'usage AISP et CBPII,
soit pendant le processus de confirmation du consentement, par exemple dans le cas d'un PISP soumettant une demande de paiement (cf. § 3.4.2).

3.3.1. Approche par redirection (Redirect)

Avec l'approche par redirection, le processus d'authentification du PSU est entièrement traité par l'ASPSP.

Pour cela, le TPP doit rediriger le PSU vers le service d'authentification de l'ASPSP, ce qui signifie que le PSU quittera temporairement l'interface du TPP pour s'authentifier vers l'interface de l'ASPSP.

Le TPP peut avoir déjà capturé un identifiant de PSU exploitable par l'ASPSP pour reconnaître sans ambiguïté le PSU. Dans ce cas, cet identifiant peut être transmis via la redirection, lorsque le protocole de redirection autorise la transmission de cet identifiant.

Après finalisation de l'authentification, l'ASPSP redirige le PSU vers l'interface du TPP.

3.3.2. Approche découplée (Decoupled)

Avec l'approche découplée, le processus d'authentification du PSU est entièrement traité par l'ASPSP.

Pour cela, le TPP doit capturer un identifiant de PSU exploitable par l'ASPSP pour reconnaître sans ambiguïté le PSU, et transmettre cet identifiant à l'ASPSP.

Sur la base de cet identifiant, l'ASPSP déclenchera une authentification via un dispositif ou une application découplé(e), ce qui signifie que le PSU ne quittera pas l'interface du TPP pendant le processus d'authentification.

3.3.3. Exemptions à l'authentification forte du client

Les exemptions à l'authentification forte du client sont spécifiées par les RTS de l'EBA sur la SCA, en particulier pour les services d'initiation de paiement.

Dans ce contexte, l'API permet au PISP de transmettre à l'ASPSP toute information utile.

De plus, le PISP peut également suggérer à l'ASPSP si la demande de paiement concernée pourrait ou non faire l'objet d'une exemption.

En fin de compte, l'ASPSP conserve la décision finale d'appliquer ou non cette exemption.

3.4. Autorisation

3.4.1. Niveaux d'autorisation

Les niveaux d'autorisation suivants peuvent être vérifiés et combinés afin de calculer les droits effectifs accordés au TPP :

NIVEAU D' AUTORISATION	DESCRIPTION
Autorisation par rôle du TPP	Une fois que le TPP a été enregistré pour un rôle donné, il peut appeler n'importe quelle fonctionnalité PSD2 fournie par un ASPSP via l'API STET PSD2 pour ce rôle.
Autorisation par accord TPP-ASPSP	Le TPP peut appeler n'importe quelle fonctionnalité supplémentaire (non PSD2) fournie par un ASPSP via l'API STET PSD2, à condition qu'un accord bilatéral existe pour utiliser ces fonctionnalités.
Autorisation par accord TPP-PSU	Si le PSU a contracté avec un TPP, il doit - donner la liste des ASPSP auxquels il autorise le TPP à accéder - réaliser une authentification auprès de chacun de ces ASPSP concernés, ce qui permettra ensuite au TPP d'accéder aux données du PSU.
Autorisation par contexte PSU	Le PSU est en mesure de spécifier son contexte PSU en détaillant, pour chacun de ses comptes concernés : - si ce compte sera accessible ou non par le TPP - quelles fonctionnalités peuvent être utilisées par le TPP Le PSU peut modifier à tout moment son contexte PSU.

3.4.2. Bases techniques

Le TPP est autorisé à accéder à l'API de l'ASPSP via un jeton d'accès (access token) qui peut être

obtenu via le cadre d'autorisation OAuth2 (https://tools.ietf.org/html/rfc6749).

Différentes autorisations (grants) peuvent être utilisées, selon le rôle du TPP et le cas d'usage à appliquer.

Le TPP peut avoir besoin de gérer plusieurs jetons OAuth2 fournis par un ASPSP donné pour le compte d'un PSU donné. En effet, la demande d'un nouveau jeton OAuth2 ne doit pas impliquer la révocation d'un jeton précédent.

3.4.2.1. Correspondance d'identité du TPP

Le protocole OAuth2 est renforcé en vérifiant l'identité du TPP durant les procédures OAuth2 via le certificat eIDAS du TPP, sur la base de MTLS (https://datatracker.ietf.org/doc/rfc8705/).

Ce renforcement est obtenu par le renseignement obligatoire, par le TPP, d'un champ [client_id] dans toutes les requêtes OAuth2. Ce [client_id] doit correspondre, directement ou non, au numéro d'autorisation situé dans le certificat eIDAS du TPP, et cette correspondance doit être vérifiée par l'ASPSP pour chaque requête OAuth2.

Comme MTLS est utilisé, l'usage du [client_secret] n'est pas très utile mais peut néanmoins être exigé par certains serveurs d'autorisation. Toute implémentation exigeant l'usage d'un [client_secret] doit mettre à jour sa documentation sur ce sujet.

Correspondance directe

La correspondance peut évidemment être directe lorsque le [client_id] est égal au numéro d'autorisation.

Dans ce cas, l'API MANAGER de l'ASPSP peut être en mesure de vérifier et d'accepter « à la volée » la requête OAuth2.

Correspondance indirecte

Cependant, dans certains cas, en particulier lorsque l'API MANAGER ne peut pas traiter un enregistrement « à la volée », une configuration technique OAuth2 doit intervenir avant toute demande de jeton OAuth2. Cette configuration aboutira au renseignement d'une valeur de [client_id] par l'ASPSP au TPP.

Le renseignement de plusieurs valeurs de [client_id] pouvant être utilisées pour différents cas d'usage par le TPP est possible en rejouant la configuration.
De plus, la configuration permet l'échange de données opérationnelles entre le TPP et l'ASPSP pour usage ultérieur : logos, numéros de téléphone, adresses e-mail, certificats…

À terme, cette configuration peut être automatisée.

3.4.2.2. Configuration technique OAuth2 automatisée

Principes

Bien que la plupart des API managers fournissent une interface de configuration en ligne, cette configuration peut aussi être automatisée.

La RFC 7591 spécifie un protocole dynamique interactif qui permet à un client de renseigner certaines métadonnées de contexte et d'obtenir une valeur de [client_id]. Il n'existe aucune restriction à fournir plusieurs valeurs de [client_id] pour les mêmes métadonnées de client et de contexte. Néanmoins, le nombre de [client_id] demandés par un même client doit rester raisonnable et motivé par un besoin réel. En complément, la RFC 7592 spécifie comment récupérer, modifier ou supprimer un contexte précédemment posté.

Si plusieurs contextes d'usage sont nécessaires pour un client d'API donné, ce client devra réitérer le processus complet pour obtenir autant de valeurs de [client_id] que nécessaire.

En effet, certains TPP peuvent être client d'une API pour le compte d'un agent (Article 4-38 de la PSD2). Chaque agent doit être considéré comme un contexte d'usage spécifique.

Comme ce protocole n'est pas obligatoire, chaque implémentation d'API devra préciser s'il est ou non implémenté.

Métadonnées de contexte

Les éléments de métadonnées pertinents à fournir sont listés ci-dessous :

NOM DE LA MÉTADONNÉE CLIENT	DESCRIPTION DE LA MÉTADONNÉE	EXIGENCE	CONTRÔLEUR DU CHANGEMENT	RÉFÉRENCE
redirect_uris	Tableau d'URIs de redirection à utiliser dans les flux par redirection	Obligatoire	IESG	[RFC7591]
software_statement	JSON Web Token (JWT) qui asserte des valeurs de métadonnées sur le logiciel client sous forme de bundle	Optionnel	IETF	[RFC7591]
token_endpoint_auth_method	Méthode d'authentification demandée pour le token endpoint.	Obligatoire Selon la RFC8705 (cf. § 2.1.1), la valeur à utiliser sera « tls_client_auth » dès que le draft sera promu en RFC.	IESG IETF	[RFC7591] [RFC8705]

NOM DE LA MÉTADONNÉE CLIENT	DESCRIPTION DE LA MÉTADONNÉE	EXIGENCE	CONTRÔLEUR DU CHANGEMENT	RÉFÉRENCE
tls_client_auth_subject_dn	Indique la valeur du subject du certificat que le serveur d'autorisation doit attendre lors de l' authentification du client concerné.	Obligatoire Une représentation sous forme de chaîne [RFC4514] du subject distinguished name attendu du certificat, que le client OAuth utilisera dans l'authentification mutual-TLS.	IETF	[RFC8705]
grant_types	Tableau des grant types OAuth 2.0 que le client peut utiliser	Obligatoire Les valeurs autorisées sont : - « authorization_code » - « ciba » - « client_credentials » - « refresh_token »	IESG	[RFC7591]
response_types	Tableau des response types OAuth 2.0 que le client peut utiliser	Optionnel « code » est la seule valeur autorisée	IESG	[RFC7591]
client_name	Nom lisible par un humain du client à présenter à l' utilisateur	Obligatoire Doit spécifier le nom de l' agent ou par défaut le nom de du TPP.	IESG	[RFC7591]
client_uri	URL d'une page web fournissant des informations sur le client	Optionnel	IESG	[RFC7591]
logo_uri	URL qui référence un logo pour le client	Optionnel	IESG	[RFC7591]
scope	Liste séparée par des espaces de valeurs de scope OAuth 2.0	Optionnel	IESG	[RFC7591]
contacts	Tableau de chaînes représentant les moyens de contacter les personnes responsables de ce client, typiquement des adresses e-mail	Obligatoire Au moins un contact doit être fourni.	IESG	[RFC7591]
tos_uri	URL pointant vers des conditions générales de service lisibles par un humain pour le client	Optionnel	IESG	[RFC7591]
policy_uri	URL pointant vers une politique lisible par un humain pour le client	Optionnel	IESG	[RFC7591]
provider_legal_id	Numéro d'autorisation du TPP selon la spécification ETSI sur les certificats eIDAS pour la PSD2	Obligatoire	STET (à enregistrer)

NOM DE LA MÉTADONNÉE CLIENT	DESCRIPTION DE LA MÉTADONNÉE	EXIGENCE	CONTRÔLEUR DU CHANGEMENT	RÉFÉRENCE
client_legal_id	Numéro d'autorisation de l'agent (voir ci-dessous)	Obligatoire en cas d'un agent distinct du TPP	STET (à enregistrer)
logo	valeur encodée en base64 du logo	Optionnel	STET (à enregistrer)
jwks	Valeur du document JSON Web Key Set [RFC7517] du client, qui contient les clés publiques du client.	Optionnel La valeur de ce champ DOIT être un objet JSON contenant un JWK Set valide. Ces clés peuvent être utilisées par des protocoles de niveau supérieur qui utilisent la signature ou le chiffrement.	IESG	[RFC7591]

De manière similaire à la spécification ETSI sur le numéro d'autorisation des TPP, le numéro

d'autorisation de l'agent doit respecter le format suivant :

« AGT » comme référence de type d'identité de personne morale sur 3 caractères ;
code pays ISO 3166 sur 2 caractères représentant le pays de la NCA ;
- trait d'union « - » (0x2D (ASCII), U+002D (UTF-8)) ; et
identifiant de NCA sur 2 à 8 caractères (A-Z majuscules uniquement, sans séparateur) ;
trait d'union « - » (0x2D (ASCII), U+002D (UTF-8)) ; et
identifiant de l'agent (numéro d'enregistrement tel que spécifié par la NCA).
Interactions

Le TPP soumet ses métadonnées de contexte via un

POST /register

En réponse, il obtient ces métadonnées de contexte complétées par

le [client_id] concerné
un [client_secret] optionnel qui n'est pas vraiment utile puisque l'authentification du client est déjà réalisée via MTLS.
le [registration_client_uri] comme endpoint de configuration du client
le [registration_access_token] à utiliser pour accéder à la configuration du client.
son horodatage d'émission.

La RFC7591 permet au serveur de mettre à jour certaines métadonnées de contexte si nécessaire.

À tout moment, le TPP peut récupérer les métadonnées de contexte via un

GET /register/{client_id}

La mise à jour des métadonnées de contexte peut se faire via un

PUT /register/{client_id}

Et la suppression des métadonnées de contexte est possible via un

DELETE /register/{client_id}

3.4.2.3. OAuth2 Authorization Code Grant

Le processus d'autorisation peut reposer sur une séquence OAuth2 pour obtenir un jeton Authorization Code Grant (cf. https://tools.ietf.org/html/rfc6749#section-4.1) et implémente l'approche par REDIRECTION.

Ce type de jeton, selon l'implémentation de l'ASPSP :

peut être utilisé pour tous les cas d'usage AISP ;
peut être utilisé pour le cas d'usage CBPII ;
peut être utilisé pour le cas d'usage de confirmation PISP.

Le processus peut se résumer par les étapes suivantes.

Tout d'abord, le PSU doit spécifier au TPP l'identité de l'un de ses ASPSP.

Code verifier et challenge optionnels

Certains serveurs d'autorisation peuvent demander l'implémentation de la RFC7636 (PKCE : Proof Key for Code Exchange) afin de renforcer l'OAuth2 Authorization Code grant.

Par conséquent, le client doit, en première étape, créer un code verifier et un code challenge.

Authorization Request

Le TPP initie la séquence OAuth2 en redirigeant le PSU vers l'infrastructure d'autorisation de l'ASPSP concerné, via le motif d'URL et les paramètres suivants

Comme cela se fait par une redirection du PSU, le certificat eIDAS du TPP ne peut pas être présenté à ce stade.

GET /authorize?response_type=code&client_id=&redirect_uri=&scope=[&state=]

NOM		DONNÉE	TYPE ET CONTRAINTES
response_type	[1..1]	Type de jeton attendu	String[10] Doit être valorisé avec « code »
client_id	[1..1]	Identification du TPP	String[36] doit être égal ou lié à l' OrganizationIdentifi er du Distinguished Name du certificat eIDAS, selon la spécification ETSI
redirect_uri	[0..1]	URL de call-back du TPP	String[140]
scope	[0..1]	Spécifie les accréditations génériques que le PSU et le TPP ont convenues : - Pour AISP `o` aisp `o` extended_transaction_history - pour CBPII `o` cbpii - pour PISP `o` pisp	String[140] Liste de rôles séparée par des espaces. Obligatoire
state	[0..1]	État interne pouvant être utilisé par le TPP pour la gestion de contexte.	String[1024] Recommandé
code_challenge	[0..1]	Code challenge calculé par le TPP selon la RFC 7636	String[140] Requis si l' implémentation de la RFC7636 est imposée par le serveur d'autorisation
code_challenge_meth od	[0..1]	Méthode de code challenge utilisée par le TPP pour calculer le code challenge	« S256 » ou « plain » La valeur par défaut est « plain »

Remarque : la RFC 6749 ne spécifie pas que l'Authorization Code Grant prenne en charge la transmission du nom d'utilisateur du Resource Owner (PSU) ou de ses préférences de langue.

Toutefois, certaines fonctionnalités OpenID Connect peuvent être utilisées à ces fins, même si la spécification OpenID Connect n'est pas entièrement appliquée (cf. § 3.4.2.4).

De plus, cette spécification suggère une implémentation de Token Introspection (cf. § 3.4.2.7) dont les paramètres pourraient être utiles pour déterminer l'identité et le contexte d'usage du PSU.

Ces paramètres supplémentaires sont résumés dans le tableau suivant.

NOM	DONNÉE	TYPE ET CONTRAINTES
login_hint_token	Un jeton contenant des informations identifiant l'utilisateur final pour qui le jeton a été émis. Ces informations peuvent aussi inclure le contexte d'usage spécifique si nécessaire. Les détails particuliers et les exigences de sécurité de cet élément ainsi que la manière dont l'utilisateur final est identifié par son contenu sont spécifiques à chaque ASPSP implémentant cette fonctionnalité. Ce jeton aurait été récupéré via une requête de token introspection (cf.§ 3.4.2.7)	String [2048]
ui_locales	Langues et scripts préférés de l'utilisateur final pour l'interface utilisateur.	String [140] Langues et scripts préférés de l'utilisateur final pour l'interface utilisateur, représentés sous forme de liste séparée par des espaces [RFC 5646]
login_hint	Indication au serveur d'autorisation sur l'identifiant de connexion que l'utilisateur final pourrait utiliser pour se connecter (si nécessaire).	String[36]

L'ASPSP

Identifie et authentifie le PSU
Calcule les vérifications pertinentes sur le TPP (rôles, validité, non-révocation…)
Vérifie le [redirect_uri] par rapport à ceux qui ont pu être déclarés durant la configuration technique OAuth2 automatisée (cf. § 3.4.2.2). Le [redirect_uri] fourni doit correspondre exactement à l'un de ceux qui ont été enregistrés.
Enregistre les [code_challenge] et [code_challenge_method] avec la demande de code lorsque l'implémentation de la RFC 7636 est imposée.

Authorization Response

Ensuite, l'ASPSP redirige le PSU vers le TPP, en utilisant l'URL de call-back précédemment fournie (redirect_uri) et les paramètres suivants :

NOM		DONNÉE		TYPE ET CONTRAINTES
code	[1..1]	Code à courte durée de vie à utiliser pour obtenir le jeton d'accès	String[36]
state	[0..1]	État interne s'il a été fourni par le TPP	String[1024] Recommandé

La durée de vie recommandée du code d'autorisation telle que spécifiée par la RFC 6749 est de 10 minutes, mais il appartient au serveur d'autorisation de fixer sa propre valeur de durée de vie.

Access Token Request

Afin d'obtenir le jeton d'accès, le TPP est maintenant en mesure d'appeler, via une requête POST, l'infrastructure d'autorisation de l'ASPSP avec les paramètres suivants.

POST /token HTTP/1.1 Host: server.example.com grant_type=authorization_code &code= &redirect_uri= &client_id=

NOM		DONNÉE
grant_type	[1..1]	Type d'autorisation demandé	String[36] Doit être valorisé avec « authorization_code »
code	[1..1]	Code à courte durée de vie précédemment fourni par l'ASPSP	String[36]
redirect_uri	[0..1]	URL de call-back du TPP	String[140] Doit être égal à celui fourni durant la demande de code d'autorisation
client_id	[1..1]	Identification du TPP.	String[36] doit être égal ou lié à l' OrganizationIdentifier du Distinguished Name du certificat eIDAS, selon la spécification ETSI
client_secret	[0..1]	Le secret client	Comme l'authentification du TPP client est fournie via MTLS, ce paramètre n'est pas très utile.
code_verifier	[0..1]	Code verifier RFC7636 initialement fixé par le TPP	Requis lorsque l'implémentation de la RFC7636 est imposée par le serveur d'autorisation

L'ASPSP
- Identifie et authentifie le TPP via le certificat eIDAS présenté (QWAC)
- Vérifie la correspondance directe ou indirecte entre le numéro d'autorisation du certificat eIDAS et la valeur de [client_id].
- Calcule les vérifications pertinentes sur le TPP (rôles, validité, non-révocation…)
- Vérifie la valeur du [code_verifier] en recalculant le [code_challenge].

Access Token Response

L'ASPSP répond via une réponse HTTP200 (OK) qui embarque les données suivantes.

NOM		DONNÉE	TYPE ET CONTRAINTES
access_token	[1..1]	Jeton d'accès fourni par l'ASPSP au TPP.	String[140]
token_type	[1..1]	Type du jeton d'accès fourni (« Bearer » ou « MAC »)	String[10] Doit être valorisé avec « Bearer »
expires_in	[0..1]	Durée de vie du jeton, en secondes. Le jeton peut être utilisé plusieurs fois tant qu'il n'est pas expiré.	Numeric
refresh_token	[0..1]	Refresh token pouvant être utilisé pour une future demande de renouvellement de jeton.	String[140]

3.4.2.4. Extension OpenID Connect de l'OAuth2 Authorization Code Grant

« En tant que fonctionnalité optionnelle, un serveur d'autorisation peut implémenter la spécification OpenID Connect Core 1.0 » au-dessus du flux OAuth2 « Authorization Code ».

Le protocole OpenID Connect permet au client de l'API (TPP) d'obtenir du serveur de l'API (ASPSP) un IdToken qui certifiera l'identité du PSU, une fois ce PSU authentifié par l'ASPSP.

Requête d'authentification simple

L'Open Id Connect Authentication Request repose sur l'OAuth2 « Authorization Code » Authorization Request avec quelques paramètres supplémentaires, indiqués en gras dans le schéma suivant.

s :

NOM		DONNÉE	TYPE ET CONTRAINTES
response_type	[1..1]	Type de jeton attendu	String[10] Doit être valorisé avec « code »
client_id	[1..1]	Identification du TPP	String[36] doit être égal ou lié à l' OrganizationIdentifier du Distinguished Name du certificat eIDAS, selon la spécification ETSI
redirect_uri	[0..1]	URL de call-back du TPP	String[140]
Scope	[0..1]	Spécifie les accréditations génériques que le PSU et le TPP ont convenues : - Pour AISP `o` aisp `o` extended_transaction_history - pour CBPII `o` cbpii. - Dans tous les cas `o` openid `o` offline_access	String[140] Liste de rôles séparée par des espaces. des scopes supplémentaires sont requis -openid pour spécifier l' usage d'OpenID Connect -offline_access pour permettre la récupération d'un refresh token dans le contexte OpenID.
State	[0..1]	État interne pouvant être utilisé par le TPP pour la gestion de contexte.	String[1024]
Nonce	[0..1]	Association d'une session client à un Id token utilisée pour atténuer les attaques par rejeu	String[36]
max-age	[0..1]	Âge maximal d'authentification (en secondes)	String[15]

NOM		DONNÉE	TYPE ET CONTRAINTES
ui_locales	[1..1]	Langues et scripts préférés de l'utilisateur final pour l'interface utilisateur.	String [140] Langues et scripts préférés de l'utilisateur final pour l'interface utilisateur, représentés sous forme de liste séparée par des espaces [RFC 5646] Requis par l' API
id_token_hint	[0..1]	dernier IdToken connu pour l'utilisateur final (PSU), le cas échéant.	String [2048]
login_hint	[0..1]	Indication au serveur d'autorisation sur l' identifiant de connexion que l'utilisateur final pourrait utiliser pour se connecter (si nécessaire).	String[36]
Login_hint_token	[0..1]	Un jeton contenant des informations identifiant l' utilisateur final pour qui le jeton a été émis. Ces informations peuvent aussi inclure le contexte d'usage spécifique si nécessaire. Les détails particuliers et les exigences de sécurité de cet élément ainsi que la manière dont l'utilisateur final est identifié par son contenu sont spécifiques à chaque ASPSP implémentant cette fonctionnalité. Ce jeton aurait été récupéré via une requête de token introspection (cf.§ 3.4.2.7)	String [2048]

Le paramètre [id_token_hint] est très utile pour faciliter le renouvellement d'une demande d'authentification du PSU en transmettant son identification déjà connue. Pour une première demande d'authentification, le paramètre [login_hint] peut être utilisé par le TPP pour transmettre l'identification du PSU, telle que connue de l'ASPSP.

Comme l'OpenID Connect Authentication Request est basée sur l'OAuth2 Authorization Request, cette dernière est enrichie de la manière suivante :

GET /authorize? response_type=code &client_id=s6BhdRkqt3 &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb &scope= openid%20%offline_access%20% aisp & nonce=n-0S6_WzA2Mj & state=af0ifjsldkj HTTP/1.1 Host: server.example.com

Requête d'authentification signée

L'OpenID Connect Authentication Request peut également être passée comme un Signed Request Object si le serveur d'autorisation l'autorise.

La structure de ce Signed Request Object est un Json Web Token (JWT) dont les données incluent :

les paramètres de requête habituels tels que spécifiés ci-dessus
certains paramètres supplémentaires relatifs à la signature (voir https://openid.net/specs/openid-connect-core-1_0.html#RequestObject pour les détails)

Il faut noter que, bien que le Signed Request Object prévale sur les paramètres de requête habituels, ces derniers peuvent aussi être passés en parallèle.

Authentication Response

En cas de traitement réussi de la requête, le serveur renverra un code d'autorisation via la redirection du PSU vers le TPP.

HTTP/1.1 302 Found Location: https://client.example.org/cb ? code=SplxlOBeZQQYbYS6WxSbIA &state=af0ifjsldkj

Token request

Le TPP demande l'échange du code d'autorisation contre un jeton OAuth2.

POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb

NB : l'en-tête « Authorization » est inutile puisque l'authentification est fournie via MTLS, sur la base du certificat eIDAS du TPP (https://datatracker.ietf.org/doc/rfc8705/).

Token response

Le serveur d'autorisation répond avec :

un jeton d'accès OAuth2
un refresh token OAuth2
un IdToken

HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store

Pragma: no-cache

{ "access_token": "SlAV32hkKG", "token_type": "Bearer", "refresh_token": "8xLOxBtZp8", "expires_in": 3600, "id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjFlOWdkazcifQ.ewogImlzc yI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwKICJzdWIiOiAiMjQ4Mjg5 NzYxMDAxIiwKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiAibi0wUzZ fV3pBMk1qIiwKICJleHAiOiAxMzExMjgxOTcwLAogImlhdCI6IDEzMTEyODA5Nz AKfQ.ggW8hZ1EuVLuxNuuIJKX_V8a_OMXzR0EHR9R6jgdqrOOF4daGU96Sr_P6q Jp6IcmD3HP99Obi1PRs-cwh3LO-p146waJ8IhehcwL7F09JdijmBqkvPeB2T9CJ NqeGpe-gccMg4vfKjkM8FcGvnzZUN4_KSP0aAp1tOJ1zZwgjxqGByKHiOtX7Tpd QyHE5lcMiKPXfEIQILVq0pc_E2DzL7emopWoaoZTF_m0_N0YzFC6g6EJbOEoRoS K5hoDalrcvRYLSrQAZZKflyuVCyixEoV9GfNQC3_osjzw2PAithfubEEBLuVVk4 XUVrWOLrLl0nx7RkKU8NXNHq-rvKMzqg" }

Structure de l'IdToken

La structure de l'IdToken est un Json Web Token (JWT).

Dans l'exemple précédent, les données suivantes sont incluses :

{ alg: "RS256", kid: "1e9gdk7" }. { iss: " "http://server.example.com" ", sub: "248289761001", aud: "s6BhdRkqt3", nonce: "n-0S6_WzA2Mj", exp: 1311281970, iat: 1311280970 }. [signature]

Les éléments de données possibles sont décrits dans le tableau suivant :

FIELD	EXIGENCE	DESCRIPTION
iss	Obligatoire	Identifiant du fournisseur du jeton
sub	Obligatoire	Identifiant du sujet du jeton
aud	Obligatoire	Destinataire du jeton [client_id]
nonce	Conditionnel	Récupération obligatoire du paramètre [nonce] s'il est présent dans l'Authentication Request initiale
exp	Obligatoire	Date d'expiration de l'IdToken [RFC3339]
iat	Obligatoire	Date de création de l'IdToken [RFC3339]
auth_time	Conditionnel	Date et heure d'authentification de l'utilisateur final (PSU) ["https://tools.ietf.org/html/rfc3339"] lorsque le paramètre [max_age] est présent dans l' Authentication Request initiale

3.4.2.5. Client Initiated Backchannel Authentication Grant

Ce processus d'enregistrement est basé sur le flux OpenID FAPI Connect CIBA et implémente l'approche DÉCOUPLÉE. (https://openid.net/specs/openid-client-initiated-backchannelauthentication-core-1_0.html)

Toutefois, afin d'éviter toute étape de préenregistrement, ce grant est censé utiliser le mode polling comme seul moyen d'obtenir le jeton demandé.

Ce type de jeton, selon l'implémentation de l'ASPSP :

peut être utilisé pour tous les cas d'usage AISP ;
peut être utilisé pour le cas d'usage CBPII ;

Authorization Request

Afin d'obtenir le jeton d'accès, le TPP appelle, via une requête POST, l'infrastructure

d'autorisation de l'ASPSP avec les paramètres suivants.

POST /bc_authorize HTTP/1.1 Host: as.example.com client_id= &scope= &login_hint_token= &id_token_hint= &login_hint= &binding_message= &ui_locales=

NOM		DONNÉE	TYPE ET CONTRAINTES
client_id	[1..1]	Identification du TPP	String[36] doit être égal ou lié à l' OrganizationIdentifier du Distinguished Name du certificat eIDAS, selon la spécification ETSI
scope	[1..1]	Spécifie les accréditations génériques que le PSU et le TPP ont convenues : - Pour AISP `o` aisp `o` extended_transaction_history - pour CBPII `o` cbpii	String[140] Liste de rôles séparée par des espaces. Obligatoire
login_hint_token	[0..1]	Un jeton contenant des informations identifiant l'utilisateur final pour qui le jeton a été émis. Ces informations peuvent aussi inclure le contexte d'usage spécifique si nécessaire. Les détails particuliers et les exigences de sécurité de cet élément ainsi que la manière dont l'utilisateur final est identifié par son contenu sont spécifiques à chaque ASPSP implémentant cette fonctionnalité. Ce jeton aurait été récupéré via une requête de token introspection (cf.§ 3.4.2.7)	String [2048]
id_token_hint	[0..1]	Un ID token précédemment émis au client au cas où l'ASPSP a implémenté l'extension OpenID connect à l'OAuth2.	String[36]
login_hint	[0..1]	Indication au serveur d'autorisation sur l'identifiant de connexion que l'utilisateur final pourrait utiliser pour se connecter (si nécessaire).	String[36]
binding_message	[0..1]	Un identifiant ou message lisible par un humain destiné à être affiché à l'utilisateur final.	String [140]
ui_locales	[0..1]	Langues et scripts préférés de l'utilisateur final pour l' interface utilisateur.	String [140] Langues et scripts préférés de l'utilisateur final pour l'interface utilisateur, représentés sous forme de liste séparée par des espaces [RFC 5646]

L'ASPSP

Identifie et authentifie le TPP via le certificat eIDAS présenté (QWAC)
- Vérifie la correspondance directe ou indirecte entre le numéro d'autorisation du certificat eIDAS et la valeur de [client_id] fournie par le JWT
Calcule les vérifications pertinentes sur le TPP (rôles, validité, non-révocation…)
Identifie le PSU et vérifie si un canal découplé peut être utilisé

Authorization Response

En cas de validation réussie de la requête, l'ASPSP répond au TPP via une réponse HTTP200 (OK) qui embarque les données suivantes.

NOM		DONNÉE
auth_req_id	[1..1]	Identifiant unique de la demande d'autorisation.	String[36]
expires_in	[1..1]	Durée d'expiration en secondes de l'identifiant de la demande d'autorisation	Number
interval	[0..1]	Délai minimal en secondes que le TPP doit attendre entre deux requêtes de polling.	Number

Pendant ce temps, l'ASPSP contacte le PSU sur le canal découplé concerné, affiche le contenu de la demande d'autorisation et demande une confirmation via une authentification.

Access Token Request

Le TPP peut alors interroger (poll) le token endpoint avec l'intervalle fourni par l'authorization response.

POST /token HTTP/1.1 Host: as.example.com client_id= &grant_type= &auth_req_id=

NOM		DONNÉE	TYPE ET CONTRAINTES
client_id	[1..1]	Identification du TPP	String[36] doit être égal ou lié à l'OrganizationIdentifier du Distinguished Name du certificat eIDAS, selon la spécification ETSI
client_secret	[0..1]	Le secret client	Comme l'authentification du TPP client est fournie via MTLS, ce paramètre n'est pas très utile.
grant_type	[1..1]	Type de grant	Doit être égal à « urn:openid:params:grant-type:ciba »
auth_req_id	[1..1]	Identifiant unique de la demande d'autorisation tel que fourni via l' Authorization response	String [36]

Réponse de jeton réussie

L'ASPSP répond via une réponse HTTP200 (OK) qui embarque les données suivantes.

NOM		DONNÉE	TYPE ET CONTRAINTES
access_token	[1..1]	Jeton d'accès fourni par l'ASPSP au TPP.	String[140]
token_type	[1..1]	Type du jeton d'accès fourni (« Bearer » ou « MAC »)	String[10] Doit être valorisé avec « Bearer »

NOM		DONNÉE	TYPE ET CONTRAINTES
expires_in	[0..1]	Durée de vie du jeton, en secondes. Le jeton peut être utilisé plusieurs fois tant qu'il n'est pas expiré.	Numeric
refresh_token	[0..1]	Refresh token pouvant être utilisé pour une future demande de renouvellement de jeton.	String[140]

Réponse de jeton en échec

En plus des codes d'erreur déjà spécifiés par la RFC6749, les valeurs suivantes peuvent aussi être utilisées dans le contexte d'une réponse HTTP400.

CODE D'ERREUR	DESCRIPTION
authorization_pending	La demande d'autorisation est toujours en attente car l'utilisateur final (PSU) n'a pas encore été authentifié. Dans le respect de l' intervalle de polling spécifié, le TPP devra rejouer la requête de jeton.
slow_down	La demande d'autorisation est toujours en attente car l'utilisateur final (PSU) n'a pas encore été authentifié et le TPP devra rejouer la requête de jeton. Toutefois, l'intervalle de polling doit être augmenté d'au moins 5 secondes pour cette prochaine requête et toutes les suivantes.
expired_token	L'identifiant de la demande d'autorisation a expiré. Le TPP devra faire une nouvelle demande d'autorisation
access_denied	l'utilisateur final (PSU) a refusé la demande d'autorisation

3.4.2.6. OAuth2 Client Credentials Flow

L'enregistrement du TPP par l'ASPSP repose sur une séquence OAuth2 pour obtenir un jeton Client Credential grant (cf. https://tools.ietf.org/html/rfc6749#section-4.4).

Ce type de jeton, selon l'implémentation de l'ASPSP :

peut être utilisé pour le cas d'usage CBPII ;
peut être utilisé pour le cas d'usage de confirmation PISP (approche REDIRECT de base) ;
- doit être utilisé pour tous les autres cas d'usage PISP.

Cette procédure peut se résumer par les étapes suivantes.

Access Token Request

Le TPP envoie directement, via une requête POST, sa demande de jeton d'accès à l'infrastructure d'autorisation de l'ASPSP avec le motif d'URL et les paramètres suivants

POST /token Host: authorization-server.com grant_type=client_credentials &scope= &client_id=

NOM		DONNÉE	DONNÉE	TYPE ET CONTRAINTES
grant_type	[1..1]	Type d'autorisation demandé		String[36] Doit être valorisé avec « client_credentials »
scope	[0..1]	Spécifie les accréditations génériques que le PSU et le TPP ont convenues : PISP.	String[140] Liste de rôles séparée par des espaces. La valeur par défaut est « pisp »
client_id	[1..1]	Identification du TPP	String[36] doit être égal ou lié à l' OrganizationIdentifier du Distinguished Name du certificat eIDAS, selon la spécification ETSI
client_secret	[0..1]	Le secret client	Comme l'authentification du TPP client est fournie via MTLS, ce paramètre n'est pas très utile.

L'ASPSP

Identifie et authentifie le TPP via le certificat eIDAS présenté (QWAC)
Vérifie la correspondance, directe ou indirecte, entre le numéro d'autorisation du certificat eIDAS et la valeur de [client_id].
Calcule les vérifications pertinentes sur le TPP (rôles, validité, non-révocation…)

Access Token Response

L'ASPSP répond via une réponse HTTP200 (OK) qui embarque les données suivantes.

NOM		DONNÉE
access_token	[1..1]	Jeton d'accès fourni par l' ASPSP au TPP.	String[140]
token_type	[1..1]	Type du jeton d'accès fourni (« Bearer » ou « MAC »)	String[10] Doit être valorisé avec « Bearer »
expires_in	[0..1]	Durée de vie du jeton, en secondes. Le jeton peut être utilisé plusieurs fois tant qu'il n'est pas expiré.	Numeric

3.4.2.7. OAuth2 Token introspection

La RFC 7662 (cf. https://tools.ietf.org/html/rfc7662) spécifie comment fournir des méta-informations sur un jeton donné.

Il appartient à chaque ASPSP d'implémenter cette fonctionnalité si nécessaire.

Introspection Request

Afin d'obtenir les méta-informations sur un jeton donné, le TPP appellera, via une requête POST utilisant son certificat eIDAS, l'infrastructure d'autorisation de l'ASPSP avec les paramètres suivants.

POST /introspect HTTP/1.1 Host: server.example.com token= &token_type_hint=

NOM		DONNÉE	TYPE ET CONTRAINTES
Token	[1..1]	Valeur chaîne du jeton	String[144]
token_type_hint	[0..1]	Type du jeton tel que défini	Doit être valorisé avec « refresh_token » ou avec « access_token »
client_id	[1..1]	Identification du TPP	String[36] doit être égal ou lié à l'OrganizationIdentifier du Distinguished Name du certificat eIDAS, selon la spécification ETSI
client_secret	[0..1]	Le secret client	Comme l'authentification du client TPP est fournie via MTLS, ce paramètre n'est pas très utile.

L'ASPSP
- Identifie et authentifie le TPP via le certificat eIDAS présenté (QWAC)

Vérifie la correspondance directe ou indirecte de la valeur de [token] avec le numéro d'autorisation situé dans le certificat eIDAS du TPP (QWAC).
obtient le jeton concerné et ses méta-informations afin de construire la réponse.

Introspection Response

L'ASPSP répond par un objet JSON avec les éléments suivants suggérés tels que spécifiés par la RFC :

NOM		DONNÉE	TYPE ET CONTRAINTES
Active	[1..1]	Indicateur booléen indiquant si le jeton présenté est actuellement actif ou non.	« true » ou « false »
Scope	[0..1]	Liste séparée par des espaces des scopes associés à ce jeton	String[140] Liste de rôles séparée par des espaces.
client_id	[0..1]	Identifiant client du client OAuth 2.0 qui a demandé ce jeton.	String[36] doit être égal ou lié à l' OrganizationIdentifier du Distinguished Name du certificat eIDAS, selon la spécification ETSI
token_type	[0..1]	Type du jeton d'accès fourni (« Bearer » ou « MAC »)	String[10] Doit être valorisé avec « Bearer » pour les jetons d'accès. La valeur est indifférente pour les refresh tokens.
Exp	[0..1]	Timestamp entier, mesuré en nombre de secondes depuis le 1er janvier 1970 UTC, indiquant quand ce jeton expirera.	Integer Ce champ DOIT être fourni
Iat	[0..1]	Timestamp entier, mesuré en nombre de secondes depuis le 1er janvier 1970 UTC, indiquant quand ce jeton a été initialement émis	Integer Ce champ peut être fourni

La spécification de l'API STET suggère la fourniture d'un autre élément spécifique défini comme suit :

NOM	DONNÉE	TYPE ET CONTRAINTES
login_hint_token	Un jeton contenant des informations identifiant l'utilisateur final pour qui le jeton a été émis. Ces informations peuvent aussi inclure le contexte d'usage spécifique si nécessaire. Les détails particuliers et les exigences de sécurité de cet élément ainsi que la manière dont l'utilisateur final est identifié par son contenu sont spécifiques à chaque ASPSP implémentant cette fonctionnalité.	String [2048]

Le [login_hint_token] peut ensuite être utilisé par le TPP afin de redonner une indication sur l'identité et le contexte d'usage du PSU, en particulier :

lors d'un nouveau OAuth2 Authorisation Code Grant (cf. § 3.4.2.3) ou de son équivalent OpenID connect (cf. § 3.4.2.4)
lors d'une nouvelle Client Initiated Backchannel Authentication (cf. § 3.4.2.5)
lors de la soumission d'une demande de paiement (via les données supplémentaires du payload).

3.4.2.8. Utilisation du jeton d'accès

Le jeton d'accès doit être utilisé dans chaque requête au sein de l'en-tête « Authorization », préfixé par le type de jeton « Bearer ».

Le [client_id] lié au jeton d'accès doit correspondre directement ou indirectement au

numéro d'autorisation situé dans le certificat eIDAS du TPP (QWAC).

Si le jeton d'accès est expiré, la requête sera rejetée avec un HTTP401 et une erreur égale à

« invalid_token » et la requête pourra être rejouée une fois le jeton d'accès rafraîchi.

Si le scope du jeton d'accès ne peut pas couvrir la requête (cas d'une demande d'historique de transactions étendu par exemple) :

la requête sera rejetée avec un HTTP403 et une erreur égale à « insufficient_scope »
le refresh token sera révoqué afin que la requête puisse être rejouée une fois qu'un nouveau jeton, ayant le bon scope, aura été demandé et fourni.

3.4.2.9. Rafraîchissement du jeton d'accès

Le rafraîchissement du jeton d'accès n'est possible que lorsque le jeton d'accès a été accordé via un OAuth2 « Authorization Code », OpenID Connect ou « Client Initiated Backchannel Authentication » Grants.

Selon la RFC 6749 (cf. https://tools.ietf.org/html/rfc6749#section-6), le Refresh Token peut être utilisé par le TPP afin d'obtenir un jeton d'accès rafraîchi via la requête suivante.

POST /token HTTP/1.1

Host: server.example.com grant_type=refresh_token &client_id= &refresh_token=tGzv3JOkF0XG5Qx2TlKWIA &scope=

NOM		DONNÉE	TYPE ET CONTRAINTES
grant_type	[1..1]		Doit être valorisé avec « refresh_token »
refresh_token	[1..1]	Valeur du refresh token fourni
client_id	[1..1]	Identification du TPP	String[36] doit être égal ou lié à l'OrganizationIdentifier du Distinguished Name du certificat eIDAS, selon la spécification ETSI
client_secret	[0..1]	Le secret client	Comme l'authentification du client TPP est fournie via MTLS, ce paramètre n'est pas très utile.
scope	[0..1]	Spécifie les accréditations génériques que le PSU et le TPP ont convenues : « aisp » ou « cbpii ». « extended_transaction_history » n'est pas autorisé dans ce cas.	String[140] Liste de rôles séparée par des espaces.

L'ASPSP
- Identifie et authentifie le TPP via le certificat eIDAS présenté (QWAC)
- Vérifie la correspondance directe ou indirecte entre le numéro d'autorisation du certificat eIDAS et la valeur de [client_id].
L'ASPSP répond via une réponse HTTP200 (OK) qui embarque les données suivantes.

NOM		DONNÉE
access_token	[1..1]	Jeton d'accès fourni par l' ASPSP au TPP.	String[140]
token_type	[1..1]	Type du jeton d'accès fourni (« Bearer » ou « MAC »)	String[10] Doit être valorisé avec « Bearer »
expires_in	[0..1]	Durée de vie du jeton, en secondes. Le jeton peut être utilisé plusieurs fois tant qu'il n'est pas expiré.	Numeric
refresh_token	[0..1]	Refresh token pouvant remplacer le précédent refresh token.	String[140]

Si le refresh token a été révoqué, la requête sera rejetée avec un HTTP400 et une erreur égale à « invalid grant ».

3.4.2.10. Révocation du refresh token

Le refresh token fourni à un AISP est de facto révoqué par l'ASPSP

Après expiration du délai légal spécifié entre deux SCA.
Après expiration du délai spécifié par l'ASPSP sur la base de règles internes, le cas échéant.
Après rejet d'une requête pour scope insuffisant afin de permettre à l'AISP de demander un autre jeton avec le scope souhaité.
À la demande d'un PSU souhaitant révoquer l'accès du TPP aux données de son compte.

Le TPP est également en mesure de demander la révocation du refresh token, selon la RFC 7009 (cf.

https://tools.ietf.org/html/rfc7009) via la requête suivante.

POST /revoke HTTP/1.1 Host: server.example.com token=45ghiukldjahdnhzdauz &token_type_hint=refresh_token &client_id=

NOM		DONNÉE	TYPE ET CONTRAINTES
token	[1..1]	Jeton à révoquer par l'ASPSP.	String[140]
token_type_hint	[0..1]	Information sur le type de jeton à révoquer	Doit être valorisé avec « refresh_token »
client_id	[1..1]	Identification du TPP	String[36] doit être égal ou lié à l'OrganizationIdentifier du Distinguished Name du certificat eIDAS, selon la spécification ETSI
client_secret	[0..1]	Le secret client	Comme l'authentification du client TPP est fournie via MTLS, ce paramètre n'est pas très utile.

L'ASPSP
- Identifie et authentifie le TPP via le certificat eIDAS présenté (QWAC)
- Vérifie la correspondance directe ou indirecte de la valeur de [client_id] avec le numéro d'autorisation situé dans le certificat eIDAS du TPP (QWAC).
- Révoque le refresh token

3.4.2.11. OAuth2 pour applications natives

La RFC 8252 (https://tools.ietf.org/html/rfc8252) étend l'usage de l'OAuth Authorization request aux applications installées sur un appareil donné (par ex. un smartphone).

Sur la base de cette RFC, on pourrait envisager un processus d'autorisation direct (straight through) en utilisant

Universal Link (appareils sous iOS)
App Link (appareils sous Android)

Toutefois, la spécification de l'API n'impose pas ce mécanisme.

3.4.3. Niveaux d'autorisation AISP

Comme un TPP agit pour le compte d'un PSU étant un PAO, les cas d'usage PSD2 liés au rôle AISP requièrent les niveaux d'autorisation suivants :

Autorisation par rôle
Autorisation par accord TPP-PSU
Autorisation par contexte PSU

3.4.3.1. Liste des ASPSP concernés

Lorsqu'il contracte avec un TPP, le PSU fournira une liste des ASPSP auxquels il autorise le TPP à

accéder. Cette liste peut ne pas être exhaustive et donc ne pas inclure certains des ASPSP du PSU.

3.4.3.2. Enregistrement de l'accord TPP-PSU par chaque ASPSP

Cet enregistrement vise à permettre l'accès ultérieur du TPP aux données du PSU hébergées par un ASPSP donné, en fournissant au TPP un jeton d'accès OAuth2.

Le jeton d'accès peut être obtenu par l'un des Grants suivants :

OAuth2 Authorization Code grant (approche REDIRECT)
- Ce grant peut être enrichi des paramètres supplémentaires suivants empruntés à OpenID Connect :
  - [login_hint]
  - [ui_locales]
OpenID Connect Grant (approche REDIRECT)
Client Initiated Backchannel Authentication Grant (approche DÉCOUPLÉE)

Chaque ASPSP devra documenter son propre choix sur ce sujet.

3.4.3.3. Scopes OAuth2 AISP

Il est demandé que les rôles AISP, CBPII ou PISP ne soient pas mélangés au sein d'une même définition de scope dans une demande de jeton d'accès OAuth2.

Le scope OAuth2 demandé par un AISP peut être l'une des valeurs suivantes :

« aisp »
« aisp extended_transaction_history »

La première valeur de scope permet à l'AISP d'accéder à tous les comptes accessibles et données autorisés par le PSU jusqu'à l'expiration du délai légal spécifié entre deux SCA. Toutefois, cette valeur ne permet pas de demander un historique de transactions étendu, c'est-à-dire un historique incluant des transactions de plus de 90 jours.

La seconde valeur de scope permet à l'AISP d'accéder à tous les comptes accessibles et données autorisés par le PSU jusqu'à l'expiration du délai légal spécifié entre deux SCA. Elle permet aussi de demander un historique de transactions étendu.

Toutefois, ce scope « aisp extended_transaction_history » sera restreint à « aisp » par l'ASPSP lors du premier rafraîchissement de jeton. Ainsi :

L'AISP pourra demander un historique de transactions étendu avec le tout premier jeton d'accès obtenu après une demande de jeton. Ainsi, dans ce cas, une seule SCA sera requise et utilisée pour obtenir le jeton et pour demander un historique de transactions étendu.
Toute demande ultérieure d'historique de transactions étendu sera considérée comme hors scope (cf. §3.4.2)

3.4.3.4. Consentement détaillé du PSU

Le consentement détaillé du PSU spécifiera quel compte ou quelle fonctionnalité sera accessible à l'AISP. Il peut être vu comme un ensemble d'accréditations individuelles.

Cet ensemble est spécifique à un PSU donné, un TPP donné et un ASPSP donné.

Chaque accréditation individuelle repose sur un compte spécifique détenu par le PSU et tenu par l'ASPSP. Elle spécifie quelles données (transactions, soldes) le TPP est autorisé à traiter sur ce compte.

Le PSU gère ce contexte avec l'AISP, qui est responsable de :

‒ La capture des choix du PSU :

Le PSU spécifie à l'AISP quel compte et quelle fonctionnalité doivent être accessibles ou non.
L'exécution des choix du PSU :
- L'AISP a la responsabilité de respecter les choix du PSU et de ne pas accéder à une fonctionnalité pour laquelle il n'a pas été habilité.

À tout moment, le PSU peut modifier ses choix de consentement, mais cela ne peut se faire qu'avec l'AISP.

De plus, le consentement du PSU peut être ou non transmis par l'AISP à l'ASPSP, selon l'un des deux modèles de gestion du consentement suivants.

Modèle Full-AISP (A1)

Dans ce modèle, l'ASPSP n'exige pas d'être informé des détails du consentement du PSU.

Quelle que soit la requête de l'AISP, l'ASPSP répondra, sans être en mesure de vérifier la conformité de la requête par rapport aux choix du PSU.

En effet, lorsqu'il obtient le contexte PSU de l'ASPSP (via l'appel [get /accounts]), l'AISP obtiendra tous les liens HAL et identifiants de ressource pertinents pour chaque compte éligible.

Ces liens HAL aideront l'AISP à demander les fonctionnalités nécessaires sur ces comptes : soldes et/ou transactions.

Modèle mixte (A2)

Dans ce modèle, l'ASPSP exige d'être informé des détails du consentement du PSU. Par conséquent, l'ASPSP a implémenté un point d'entrée d'API ad-hoc qui peut être appelé par l'AISP afin de transmettre les choix du PSU.

En effet, lorsqu'il obtient le contexte PSU de l'ASPSP (via l'appel [get /accounts]), l'AISP obtiendra tous les comptes éligibles, mais les liens HAL et identifiants de ressource ne seront fournis que pour les comptes pour lesquels un consentement a été donné par le PSU.

Ces liens HAL aideront l'AISP à demander les fonctionnalités nécessaires sur ces comptes : soldes et/ou transactions.

Choix du modèle

Il appartient à l'ASPSP d'implémenter ou non le modèle mixte (A2). Toutefois, si ce modèle a été implémenté par l'ASPSP, il appartient à l'AISP de transmettre les détails du consentement du PSU à l'ASPSP chaque fois que le PSU donne ou modifie ce consentement.

Une fois que les détails du consentement du PSU ont été reçus et sauvegardés par l'ASPSP, l'AISP, lorsqu'il obtient le contexte PSU de l'ASPSP (via l'appel [get /accounts]), n'obtiendra que les liens HAL pour les comptes et fonctionnalités autorisés.

3.4.4. Niveaux d'autorisation CBPII

Comme un CBPII agit pour le compte d'un PSU étant un PAO, les cas d'usage PSD2 liés aux rôles AISP et CBPII requièrent les niveaux d'autorisation suivants :

Autorisation par rôle
Autorisation par accord TPP-PSU
Autorisation par contexte PSU

Toutefois, dans certains cas, le CBPII peut avoir été préalablement enrôlé par le PSU auprès de l'ASPSP concerné (cf. §3.4.4.3).

3.4.4.1. Liste des ASPSP concernés

Lorsqu'il contracte avec un TPP, le PSU fournira une liste des ASPSP auxquels il autorise le TPP à accéder. Cette liste peut ne pas être exhaustive et donc ne pas inclure certains des ASPSP du PSU.

3.4.4.2. Enregistrement de l'accord TPP-PSU par chaque ASPSP

Cet enregistrement vise à permettre l'accès ultérieur du TPP aux données du PSU hébergées par un ASPSP donné, en fournissant au TPP un jeton d'accès OAuth2.

Le jeton d'accès peut être obtenu :

Soit via un flux OAuth2 Authorization Code (approche REDIRECT)
OpenID Connect Grant (approche REDIRECT)
Client Initiated Backchannel Authentication Grant (approche DÉCOUPLÉE)

3.4.4.3. Niveau d'autorisation CBPII pré-enrôlé

Lorsque le PSU a préalablement enrôlé le CBPII auprès de son ASPSP concerné, ce dernier peut préférer appliquer un schéma d'autorisation plus simple.

Le jeton d'accès peut alors être obtenu via un flux OAuth2 Client Credentials, l'authentification du PSU étant inutile puisque le consentement du PSU a déjà été capturé.

3.4.4.4. Scope CBPII

Il est demandé que les rôles AISP et CBPII ne soient pas mélangés au sein d'une même définition de scope dans une demande de jeton d'accès OAuth2.

Le scope OAuth2 demandé par un CBPII ne peut être que « cbpii ».

3.4.5. Niveaux d'autorisation PISP et gestion de la fraude

3.4.5.1. Cas d'usage

Poster et obtenir une demande de paiement/virement

Pour poster ou obtenir une demande de paiement pour le compte d'un Marchand, ou une demande de virement pour le compte d'un Donneur d'ordre, le PISP peut utiliser un jeton d'accès qui peut être obtenu de l'ASPSP via un flux OAuth2 Client Credentials.

Toutefois, l'exécution de la demande de paiement nécessite une confirmation :

de la part du PSU par une authentification appropriée
de la part du PISP lui-même après réalisation de son analyse de risque de fraude.

Dans cette perspective, durant le post de la demande de paiement, le PISP devra suggérer

les approches d'authentification qu'il prend en charge. L'ASPSP répondra alors avec l'approche d'authentification choisie complétée et l'URL à utiliser pour initier l'authentification du PSU.

Confirmation d'une demande de paiement

Cette authentification doit être forte, sauf cas d'exemption, et peut être réalisée via une approche ENFORCED REDIRECT ou DÉCOUPLÉE (cf. infra).

Une fois que le PSU a confirmé la demande de paiement à l'ASPSP via cette authentification, le PISP obtiendra un jeton d'accès. Le PISP doit utiliser ce jeton d'accès pour sa propre confirmation de la demande de paiement après avoir vérifié, par exemple, l'absence de faille de sécurité potentielle.

Annulation d'une demande de paiement

Au cas où le PISP doit annuler une demande de paiement, le jeton d'accès à utiliser peut être obtenu de l'ASPSP via un flux OAuth2 Client Credentials.

Toutefois, l'ASPSP peut exiger une confirmation via une authentification du PSU. Cette authentification peut être réalisée via une approche SIMPLE REDIRECT ou DÉCOUPLÉE (cf. infra).

Dans cette perspective, durant la demande d'annulation, le PISP devra suggérer les approches d'authentification qu'il prend en charge. L'ASPSP répondra alors :

soit avec la décision de ne pas traiter l'authentification du PSU ; l'annulation est alors effective
soit avec l'approche d'authentification choisie complétée par l'URL à utiliser pour initier l'authentification du PSU ; l'annulation sera effective après cette authentification du PSU.

3.4.5.2. Approche SIMPLE REDIRECT

Cette approche ne peut être utilisée que pour une annulation de demande de paiement.

L'authentification du PSU est alors traitée via une simple redirection du PSU vers le serveur d'authentification de l'ASPSP en utilisant l'URL initialement fournie par l'ASPSP.

L'ASPSP authentifie le PSU puis redirige ce dernier en utilisant l'une des URL de call-back fournies par le PISP.

3.4.5.3. Approche ENFORCED REDIRECT

Cette approche est obligatoire pour une confirmation de demande de paiement en approche REDIRECT.

Un jeton Authorization Code sera utilisé pour la confirmation. L'authentification du PSU est traitée via le flux Authorization Code avec le serveur d'authentification de l'ASPSP.

Objet et analyse de risque

L'initiation de paiement peut en effet rencontrer certains problèmes de sécurité en approche REDIRECT.

Une première attaque (fixation de session) pourrait survenir, fondée sur le fait qu'un PSU donné transmettra la requête de redirection à un autre PSU qui pourrait être en mesure de s'authentifier et de payer l'achat effectué par le premier PSU.

De plus, même si la première attaque est atténuée, l'attaquant pourrait aussi tenter de simuler la redirection (fausse redirection) vers le TPP afin d'induire la confirmation de la demande de paiement auprès de l'ASPSP.

Protection contre la fixation de session

Afin d'éviter l'attaque par fixation de session, le PISP doit s'assurer qu'il n'y a pas de « PSU-switch » durant la redirection. Cela peut se faire en gérant un nonce qui

sera stocké dans la session du user agent du PSU avant la redirection vers l'ASPSP et
- sera récupéré depuis le user agent du PSU après la redirection.

En cas d'échec de la récupération, il y a de fortes chances qu'une telle attaque ait eu lieu. Le PISP devrait alors annuler la demande de paiement pour cause de fraude.

Sinon, en cas de récupération réussie du nonce, le PISP peut confirmer la demande de paiement à l'ASPSP qui est alors en mesure de déclencher les virements concernés.

Protection contre la fausse redirection

Afin de poster la confirmation, le PISP doit demander un jeton Authorization Code à l'ASPSP.

En réponse à la demande de paiement, l'ASPSP a fourni au PISP l'URI du

serveur d'autorisation. Certains paramètres OAuth2 doivent avoir été pré-valorisés :

[response_type] valorisé avec « code »
[scope] valorisé avec « pisp »
[context] valorisé avec une indication vers la demande de paiement

Le PISP complétera cette URL avec ses propres paramètres OAuth2

[client_id]
[state] si nécessaire
[redirect_uri] comme URL de call-back.

L'OAuth2 Authorization Code grant peut alors se dérouler (cf. §3.4.2.3).

Après la récupération du Authorization Code via la redirection du PSU vers le PISP, ce dernier doit alors s'assurer, par le mécanisme de vérification du nonce, qu'il n'y a pas eu de « PSU-switch » durant la redirection, comme expliqué précédemment.

Le PISP peut alors échanger le Authorization Code contre le jeton d'accès.

la durée de vie du jeton d'accès est spécifiée par le serveur d'autorisation afin de limiter la période d'utilisabilité.
aucun refresh token ne doit être fourni.

La confirmation est alors postée, en utilisant ce jeton d'accès.

En cas d'attaque par fausse redirection, le jeton d'accès n'aurait pas pu être récupéré par le PISP. Même en tentative de confirmation, l'ASPSP peut détecter l'absence du jeton et rejettera alors la demande de paiement pour cause de FRAUDE.

Sinon, la confirmation envoyée par le PISP conduira au déclenchement normal des virements concernés.

3.4.5.4. Approche OAuth2 DÉCOUPLÉE

Dans cette approche, le jeton Client Credential peut être utilisé pour tous les cas d'usage PISP :

Poster une demande de paiement
Obtenir la demande de paiement précédemment postée
Modifier pour annulation la demande de paiement
Confirmer la demande de paiement

L'authentification du PSU est traitée via un canal découplé initié par l'ASPSP.

Après authentification du PSU, le PISP est informé par un appel direct de l'ASPSP. Le PISP peut alors confirmer la demande de paiement, ce qui conduira au déclenchement normal des virements concernés.

3.4.5.5. Tableau récapitulatif

	SIMPLE REDIRECT	ENFORCED REDIRECT	DECOUPLED
Protection par mécanisme de nonce appliquée par le PISP	Le nonce doit être calculé par le PISP et stocké dans le user-agent du PSU dès lors que le PISP accepte les approches Simple REDIRECT ou Enforced REDIRECT lors du post ou de l'annulation d'une demande de paiement.

	SIMPLE REDIRECT	ENFORCED REDIRECT	DECOUPLED
Successful et Unsuccessful Report Uri fournis par le PISP	À utiliser par l'ASPSP via la redirection du PSU		À utiliser directement par l' ASPSP après l'authentification du PSU
Approche d'authentification acceptée fixée par le PISP	Doit inclure « REDIRECT »		Doit inclure « DECOUPLED »
Approche d'authentification appliquée fixée par l'ASPSP	« REDIRECT »		« DECOUPLED »
Authentification du PSU	Pour la confirmation d'une annulation	Pour la confirmation d'une demande de paiement

3.5. Authentification applicative

Chaque requête envoyée par le TPP doit être signée et l'ASPSP peut également signer ses réponses.

Si l'ASPSP constate que la signature est absente ou invalide pour une requête donnée, il doit rejeter cette requête avec un HTTP400.

Si le TPP constate que la signature est invalide pour une réponse donnée, il doit en avertir l'ASPSP concerné.

3.5.1. Mécanisme Http-Signature

Le mécanisme http-signature est spécifié par le draft IETF suivant :

https://datatracker.ietf.org/doc/draft cavage http signatures/

On notera que ce draft IETF a désormais été remplacé par un nouveau draft :

https://datatracker.ietf.org/doc/draft-ietf-httpbis-message-signatures/

Toutefois, comme OpenBankingEurope et ETSI, conjointement avec plusieurs initiatives d'API PSD2 dont STET, ont publié un nouveau standard de signature, il est fortement conseillé d'envisager de remplacer http-signature par ce nouveau standard de signature (cf. 3.5.2).

3.5.1.1. Calcul de la signature

La manière dont cela devrait être implémenté est la suivante

Calculer un digest SHA256 du corps HTTP et ajouter ce digest comme en-tête HTTP supplémentaire.

Utiliser un certificat qualifié spécifique (QSealC), respectant la spécification technique ETSI/TS119495, afin d'appliquer une signature RSA-SHA256 sur
- tous les en-têtes suivants présents dans la requête HTTP envoyée par le TPP, y compris le digest précédemment calculé
  - Date (si disponible)
  - Content-Type (lorsqu'il y a un payload)
  - Content-Length (lorsqu'il y a un payload)
  - X-Request-Id
  - Tous les en-têtes préfixés « PSU » disponibles (cf. § 3.5.2)
  - le pseudo-en-tête spécifique « (request-target) » spécifié par le draft IETF
- tous les en-têtes suivants présents dans la réponse HTTP fournie par l'ASPSP, y compris le digest précédemment calculé
  - Date (si disponible)
  - Content-Type (lorsqu'il y a un payload)
  - Content-Length (si disponible)
  - X-Request-Id
Ajouter cette signature dans un en-tête HTTP supplémentaire embarquant
- L'identifiant de clé qui doit spécifier la manière d'obtenir le certificat qualifié concerné (voir ci-dessous)
- L'algorithme qui a été utilisé
- La liste des en-têtes qui ont été signés
- La signature elle-même.

Depuis la version #11 du draft, deux nouveaux pseudo-en-têtes ont été introduits afin de

renforcer la signature : (created) et (expires). Toutefois, des travaux sont toujours en cours sur ce sujet et l'usage de ces deux champs n'est pas encore recommandé.

EN-TÊTE HTTP SUPPLÉMENTAIRE	DONNÉE	COMMENTAIRE
Digest	Digest du corps
Signature	http-signature de la requête (cf. https://datatracker.ietf.org/doc/draft-cavage-http- signatures/)

3.5.1.2. Valeur de l'identifiant de clé

Il est demandé que cet identifiant soit valorisé avec :

Soit le keyId qui a été assigné par le serveur d'autorisation durant la configuration technique OAuth2 (cf. § 3.4.2.2).
Soit une URL visant à fournir le certificat qualifié concerné.
- Afin d'assurer une discrimination facile du certificat parmi d'autres, il est demandé que la dernière partie de l'URL vers le certificat soit suffixée par un underscore suivi de l'empreinte SHA-256 du certificat.
  - Ex. : https://path.to/myQsealCertificate_714f8154ec259ac40b8a9786c9908 488b2582b68b17e865fede4636d726b709f
- Cette URL aurait pu être fournie durant la configuration technique OAuth2 dans le champ « 5xu » du JKS fourni par le TPP (cf. RFC7517).

3.5.2. JSON Web Signature Profile for Open Banking

Ce mécanisme de signature est spécifié par le document suivant :

https://www.openbankingeurope.eu/media/2095/obe-json-web-signature-profile-foropen-banking.pdf

Il repose sur l'usage d'une Json Web Signature (JWS telle que spécifiée par la RFC7515).

La manière dont cela devrait être implémenté est la suivante

Choisir un certificat qualifié (QSealC), respectant la spécification technique ETSI/TS119495 et appartenant à l'émetteur de la requête ou de la réponse comme certificat de signature.
Choisir un algorithme de signature parmi ceux listés à la fois dans la RFC7518 et l'ETSI TS 119 312, bien qu'une revue régulière des faiblesses potentielles de ces algorithmes soit fortement recommandée.
Calculer un digest SHA256 du corps HTTP et ajouter ce digest comme en-tête HTTP supplémentaire.
Construire un JWS protected header dont
- le champ [sigD/pars] listera tous les champs d'en-tête HTTP en minuscules à signer (voir ci-dessous) et l'encoder en Base64url.
- le champ [x5t#S256] sera valorisé avec le hash encodé en Base64url du certificat de signature précédemment choisi
- le champ [alg] sera valorisé avec le nom de l'algorithme de signature
- Construire la chaîne d'en-têtes HTTP comme la liste de tous les en-têtes/valeurs à signer.
o tous les en-têtes suivants présents dans la requête HTTP envoyée par le TPP, y compris le digest précédemment calculé
- Date (si disponible)
- Content-Type (lorsqu'il y a un payload)

Content-Length (lorsqu'il y a un payload)
X-Request-Id
Tous les en-têtes préfixés « PSU » disponibles (cf. § 3.5.2)
le pseudo-en-tête spécifique « (request-target) » spécifié par le draft IETF
tous les en-têtes suivants présents dans la réponse HTTP fournie par l'ASPSP, y compris le digest précédemment calculé
- Date (si disponible)
- Content-Type (lorsqu'il y a un payload)
- Content-Length (si disponible)
- X-Request-Id
Concaténer le JWS protected header encodé en Base64url et la chaîne d'en-têtes HTTP avec un point (« . ») comme séparateur.
Calculer la signature, en utilisant le certificat et l'algorithme choisis, sur le résultat de la concaténation précédente.
Concaténer le JWS protected header encodé en Base64url et la signature résultante avec un double-point (« .. ») comme séparateur

Ajouter le résultat de la concaténation précédente comme en-tête HTTP supplémentaire « x-jws-signature »

3.6. Informations orientées détection de fraude

Les en-têtes HTTP supplémentaires suivants doivent être utilisés dans la requête HTTP envoyée par le TPP, à condition que les données concernées soient disponibles dans la connexion entre le PSU et le TPP. Cette transmission permet à l'ASPSP d'intégrer ces informations dans son propre processus de détection de fraude.

De plus, ces en-têtes peuvent être considérés comme une preuve de la connexion du PSU.

EN-TÊTE HTTP SUPPLÉMENTAIRE	DONNÉE	COMMENTAIRE
PSU-IP-Address	Adresse IP du terminal du PSU lors de la connexion au TPP	Au regard des règles RGPD, cela doit être soumis au consentement du PSU
PSU-IP-Port	Port IP du terminal du PSU lors de la connexion au TPP
PSU-HTTP-Method	Méthode HTTP utilisée pour la requête la plus pertinente du terminal du PSU vers le TPP
PSU-Date	Horodatage de la requête la plus pertinente du terminal du PSU vers le TPP
PSU-User-Agent	Champ d'en-tête « User-Agent » envoyé par le terminal du PSU lors de la connexion au TPP
PSU-Referer	Champ d'en-tête « Referer » envoyé par le PSU terminal lors de la connexion au TPP
PSU-Accept	Champ d'en-tête « Accept » envoyé par le PSU terminal lors de la connexion au TPP
PSU-Accept-Charset	Champ d'en-tête « Accept-Charset » envoyé par le terminal du PSU lors de la connexion au TPP
PSU-Accept-Encoding	Champ d'en-tête « Accept-Encoding » envoyé par le terminal du PSU lors de la connexion au TPP
PSU-Accept-Language	Champ d'en-tête « Accept-Language » envoyé par le terminal du PSU lors de la connexion au TPP
PSU-GEO-Location	La géolocalisation transmise de la requête HTTP correspondante entre PSU et TPP si disponible.	Au regard des règles RGPD, cela doit être soumis au consentement du PSU
`PSU-Device-ID`	UUID (Universally Unique Identifier) d'un appareil utilisé par le PSU, si disponible. L'UUID identifie soit un appareil, soit une installation d'application dépendante d'un appareil. En cas d'identification d'installation, cet ID doit rester inchangé jusqu'à la suppression de l' appareil.	Au regard des règles RGPD, cela doit être soumis au consentement du PSU

3.7. Autres en-têtes HTTP spécifiques à utiliser

EN-TÊTE HTTP SUPPLÉMENTAIRE	DONNÉE		COMMENTAIRE
X-Request-ID	En-tête de corrélation à positionner dans une requête et à récupérer dans la réponse correspondante.
Idempotency-Key	Clé d'idempotence à ajouter par le client de l'API pour garantir qu'une requête donnée, lorsqu'elle est réessayée deux fois ou plus, ne sera bien exécutée qu'une seule fois par le serveur de l'API. Cela s'applique en particulier aux requêtes POST.		Les règles d'unicité, de validité et d'expiration doivent être fixées selon : https://datatracker.ietf.org/doc/draft-ietf-httpapi- idempotency-key-header/

3.8. Codes et messages de retour HTTP spécifiques à utiliser

MESSAGE	CODE HTTP	SIGNIFICATION
FORMAT_ERROR	400	Le format de certains champs de la requête ne correspond pas aux exigences XS2A. Un chemin explicite vers le champ correspondant peut être ajouté dans le message de retour.
RESOURCE_UNKNOWN	404	Si resourceId dans le path
PERIOD_INVALID	400	Période demandée hors limites.

MESSAGE	CODE HTTP	SIGNIFICATION
ACCESS_EXCEEDED	429	L'accès au compte a dépassé la multiplicité consentie par jour.
REQUESTED_FORMATS _INVALID	406	Les formats demandés dans l'en-tête Accept ne correspondent pas aux formats proposés par l'ASPSP.

3.9. Résumé technique de l'API STET PSD2

SUJET	CHOIX		COMMENTAIRE
Réseau d'accès	Internet
Protocole réseau	HTTP 1.1 (Minimum)
Chiffrement des données Authentification croisée	TLS 1.2		Pourrait être renforcé via STS et/ou PFS
Protocole d'autorisation			Dans le respect des RFC 6749, 7009 L'un des modes de jeton suivants - Authorization Code Grant (AISP, CBPII et PISP) pour l'approche REDIRECT - Client credential (PISP, CBPII) Sur la base de MTLS, l'identité du TPP est fournie par son certificat eIDAS durant les procédures OAuth2. https://datatracker.ietf.org/doc/rfc8705/ L'extension OpenId Connect peut aussi être utilisée à la place de l'Authorization Code Grant Le Client Initiated Backchannel Authorization Grant peut être utilisé afin d'implémenter une approche DÉCOUPLÉE



		OAuth2

Protocole applicatif	REST		Dans le respect du Richardson Maturity Model, au niveau trois afin de fournir des liens HYPERMEDIA.
Authentification applicative	http-signature		À noter qu'il s'agit en réalité d'un
Approches d'authentification forte du client (PSU)	REDIRECT, DECOUPLED
Format de données	JSON/UTF8		Avec usage de structures de données basées sur ISO20022
Documentation technique	SWAGGER 2.0		Le format Date/Heure doit respecter ISO8601 et RFC3339 conformément aux spécifications OpenApi. Le créateur d'une Date/Heure doit choisir - N'importe quel format de fuseau horaire, bien que le format UTC soit recommandé. - N'importe quel format de fraction de seconde, y compris l'absence de fraction de seconde. Une simple date peut être spécifiée comme une date/heure UTC avec une partie heure égale à « 00:00:00Z ». Le destinataire d'une Date/Heure doit être en mesure d'interpréter sa valeur dès lors qu'elle est conforme à ISO8601 et RFC3339.