5. Considerazioni IANA

5.1 Registro degli schemi di autenticazione

L'"Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" definisce lo spazio dei nomi per gli schemi di autenticazione nelle challenge e nelle credenziali. È stato creato ed è attualmente mantenuto presso http://www.iana.org/assignments/http-authschemes.

5.1.1 Procedura

Le registrazioni devono includere i seguenti campi (MUST):

• Nome dello schema di autenticazione (Authentication Scheme Name)
• Puntatore al testo della specifica (Pointer to specification text)
• Note (facoltativo) (Notes (optional))

I valori da aggiungere a questo spazio dei nomi richiedono un IETF Review (vedere la [RFC5226], Sezione 4.1).

5.1.2 Considerazioni per i nuovi schemi di autenticazione

Vi sono alcuni aspetti del framework di autenticazione HTTP che impongono vincoli a come possono funzionare i nuovi schemi di autenticazione:

• Si presume che l'autenticazione HTTP sia stateless: tutte le informazioni necessarie per autenticare una richiesta devono essere fornite nella richiesta, anziché dipendere dal fatto che il server ricordi le richieste precedenti (MUST). L'autenticazione basata sulla connessione sottostante, o a essa vincolata, è al di fuori dell'ambito della presente specifica ed è intrinsecamente difettosa, a meno che non si adottino misure per garantire che la connessione non possa essere usata da alcuna parte diversa dall'utente autenticato (vedere la Sezione 2.3 della [RFC7230]).

• Il parametro di autenticazione "realm" è riservato alla definizione degli spazi di protezione come descritto nella Sezione 2.2. I nuovi schemi non devono usarlo in modo incompatibile con tale definizione (MUST NOT).

• La notazione "token68" è stata introdotta per compatibilità con gli schemi di autenticazione esistenti e può essere usata una sola volta per challenge o credenziale. Pertanto, i nuovi schemi dovrebbero usare invece la sintassi auth-param, perché altrimenti le estensioni future saranno impossibili.

• L'analisi delle challenge e delle credenziali è definita dalla presente specifica e non può essere modificata dai nuovi schemi di autenticazione. Quando si usa la sintassi auth-param, tutti i parametri dovrebbero supportare sia la sintassi token sia quella quoted-string, e i vincoli sintattici dovrebbero essere definiti sul valore del campo dopo l'analisi (cioè dopo il trattamento quoted-string). Ciò è necessario affinché i destinatari possano usare un parser generico applicabile a tutti gli schemi di autenticazione.

Nota: Il fatto che la sintassi del valore del parametro "realm" sia limitata a quoted-string è stata una cattiva scelta progettuale da non ripetere per i nuovi parametri.

• Le definizioni dei nuovi schemi dovrebbero definire il trattamento dei parametri di estensione sconosciuti. In generale, una regola "must-ignore" è preferibile a una regola "must-understand", perché altrimenti sarà difficile introdurre nuovi parametri in presenza di destinatari preesistenti. Inoltre, è bene descrivere la politica per la definizione di nuovi parametri (ad esempio "aggiornare la specifica" o "usare questo registro").

• Gli schemi di autenticazione devono documentare se sono utilizzabili nell'autenticazione del server di origine (cioè usando WWW-Authenticate) e/o nell'autenticazione del proxy (cioè usando Proxy-Authenticate).

• Le credenziali trasportate in un campo di intestazione Authorization sono specifiche dello user agent e hanno quindi, nell'ambito della richiesta in cui compaiono, lo stesso effetto sulle cache HTTP della direttiva di risposta "private" di Cache-Control (Sezione 5.2.2.6 della [RFC7234]).

Pertanto, i nuovi schemi di autenticazione che scelgono di non trasportare credenziali nel campo di intestazione Authorization (ad esempio usando un campo di intestazione appena definito) dovranno vietare esplicitamente la memorizzazione in cache, imponendo l'uso di direttive di richiesta Cache-Control (ad esempio "no-store", Sezione 5.2.1.5 della [RFC7234]) oppure di direttive di risposta (ad esempio "private").

5.2 Registrazione dei codici di stato

L'"Hypertext Transfer Protocol (HTTP) Status Code Registry" situato presso http://www.iana.org/assignments/http-status-codes è stato aggiornato con le registrazioni riportate di seguito:

Valore	Descrizione	Riferimento
401	Unauthorized	Sezione 3.1
407	Proxy Authentication Required	Sezione 3.2

5.3 Registrazione dei campi di intestazione

I campi di intestazione HTTP sono registrati nel registro "Message Headers" mantenuto presso http://www.iana.org/assignments/message-headers/.

Il presente documento definisce i seguenti campi di intestazione HTTP, pertanto il registro "Permanent Message Header Field Names" è stato aggiornato di conseguenza (vedere [BCP90]).

Nome del campo di intestazione	Protocollo	Stato	Riferimento
Authorization	http	standard	Sezione 4.2
Proxy-Authenticate	http	standard	Sezione 4.3
Proxy-Authorization	http	standard	Sezione 4.4
WWW-Authenticate	http	standard	Sezione 4.1

Il change controller è: "IETF ([email protected]) - Internet Engineering Task Force".

---