5. Considérations relatives à l'IANA

5.1 Registre des schémas d'authentification

Le "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" définit l'espace de noms des schémas d'authentification dans les défis et les informations d'authentification. Il a été créé et est désormais maintenu à l'adresse http://www.iana.org/assignments/http-authschemes.

5.1.1 Procédure

Les enregistrements doivent inclure les champs suivants (MUST) :

• Nom du schéma d'authentification (Authentication Scheme Name)
• Pointeur vers le texte de la spécification (Pointer to specification text)
• Notes (facultatif) (Notes (optional))

Les valeurs à ajouter à cet espace de noms exigent un IETF Review (voir la [RFC5226], section 4.1).

5.1.2 Considérations pour les nouveaux schémas d'authentification

Certains aspects du cadre d'authentification HTTP imposent des contraintes sur la manière dont les nouveaux schémas d'authentification peuvent fonctionner :

• L'authentification HTTP est présumée sans état : toutes les informations nécessaires pour authentifier une requête doivent être fournies dans la requête, plutôt que de dépendre du fait que le serveur se souvienne des requêtes antérieures (MUST). Une authentification fondée sur la connexion sous-jacente, ou liée à celle-ci, sort du cadre de la présente spécification et est intrinsèquement défectueuse, sauf si des mesures sont prises pour garantir que la connexion ne peut être utilisée par aucune partie autre que l'utilisateur authentifié (voir la section 2.3 de la [RFC7230]).

• Le paramètre d'authentification "realm" est réservé à la définition des espaces de protection tels que décrits à la section 2.2. Les nouveaux schémas ne doivent pas l'utiliser d'une manière incompatible avec cette définition (MUST NOT).

• La notation "token68" a été introduite pour assurer la compatibilité avec les schémas d'authentification existants et ne peut être utilisée qu'une seule fois par défi ou par information d'authentification. Ainsi, les nouveaux schémas devraient plutôt utiliser la syntaxe auth-param, faute de quoi les extensions futures seront impossibles.

• L'analyse des défis et des informations d'authentification est définie par la présente spécification et ne peut pas être modifiée par les nouveaux schémas d'authentification. Lorsque la syntaxe auth-param est utilisée, tous les paramètres devraient prendre en charge à la fois la syntaxe token et la syntaxe quoted-string, et les contraintes syntaxiques devraient être définies sur la valeur du champ après analyse (c'est-à-dire après le traitement quoted-string). Cela est nécessaire pour que les destinataires puissent utiliser un analyseur générique applicable à tous les schémas d'authentification.

Remarque : Le fait que la syntaxe de la valeur du paramètre "realm" soit limitée à quoted-string était un mauvais choix de conception qu'il ne faut pas répéter pour les nouveaux paramètres.

• Les définitions des nouveaux schémas devraient définir le traitement des paramètres d'extension inconnus. En général, une règle « must-ignore » est préférable à une règle « must-understand », car sinon il sera difficile d'introduire de nouveaux paramètres en présence de destinataires anciens. En outre, il est bon de décrire la politique de définition de nouveaux paramètres (par exemple « mettre à jour la spécification » ou « utiliser ce registre »).

• Les schémas d'authentification doivent documenter s'ils sont utilisables pour l'authentification auprès du serveur d'origine (c'est-à-dire au moyen de WWW-Authenticate) et/ou pour l'authentification auprès du mandataire (c'est-à-dire au moyen de Proxy-Authenticate).

• Les informations d'authentification transportées dans un champ d'en-tête Authorization sont propres à l'agent utilisateur et ont donc, dans le cadre de la requête où elles apparaissent, le même effet sur les caches HTTP que la directive de réponse "private" de Cache-Control (section 5.2.2.6 de la [RFC7234]).

Par conséquent, les nouveaux schémas d'authentification qui choisissent de ne pas transporter d'informations d'authentification dans le champ d'en-tête Authorization (par exemple en utilisant un champ d'en-tête nouvellement défini) devront interdire explicitement la mise en cache, en imposant l'utilisation soit de directives de requête Cache-Control (par exemple "no-store", section 5.2.1.5 de la [RFC7234]), soit de directives de réponse (par exemple "private").

5.2 Enregistrement des codes d'état

Le "Hypertext Transfer Protocol (HTTP) Status Code Registry" situé à l'adresse http://www.iana.org/assignments/http-status-codes a été mis à jour avec les enregistrements ci-dessous :

Valeur	Description	Référence
401	Unauthorized	Section 3.1
407	Proxy Authentication Required	Section 3.2

5.3 Enregistrement des champs d'en-tête

Les champs d'en-tête HTTP sont enregistrés dans le registre "Message Headers" maintenu à l'adresse http://www.iana.org/assignments/message-headers/.

Le présent document définit les champs d'en-tête HTTP suivants, de sorte que le registre "Permanent Message Header Field Names" a été mis à jour en conséquence (voir [BCP90]).

Nom du champ d'en-tête	Protocole	Statut	Référence
Authorization	http	standard	Section 4.2
Proxy-Authenticate	http	standard	Section 4.3
Proxy-Authorization	http	standard	Section 4.4
WWW-Authenticate	http	standard	Section 4.1

Le contrôleur de modification est : "IETF ([email protected]) - Internet Engineering Task Force".

---