Domanda obbligatorietà valori per attributi

[andrewkrgeo]

La mia è una domanda banale, ma non sono riuscito a trovare nella documentazione il set di attributi "obbligatori" ovvero quegli attributi che sicuramente avranno un valore. Faccio un esempio, in particolare su questi due valori:

• l'indirizzo mail è un dato del livello 2 che sarà sicuramente sempre valorizzato?
• il numero di telefono?

Posso supporre lato Service Provider che gli IDP mi manderanno queste informazioni (se richieste chiaramente) sempre correttamente valorizzate (quindi non valori null o blanks).

scusate la banalità della domanda, ma non mi pare di aver visto informazioni a riguardo. Forse nella documentazione degli IDP?

grazie mille e perdonate la domanda banale!

andrea

[peppelinux]

Ciao @andrewkrgeo
SAML2 Core specifica

If a SAML attribute includes a "null" value, the corresponding <AttributeValue> element MUST be
empty and MUST contain the reserved xsi:nil XML attribute with a value of "true" or "1".

Sui metadata degli IdP è possibile capire quali attributi sono supportati e rilasciabili, il tuo SP deve comunque gestire eventuali eccezioni e adottare una verifica della consistenza degli attributi. Su due piedi il campo email ad oggi non è mai stato un problema. La tua è una buona domanda, lascio la issue aperta per future consultazioni

[mauromol]

@peppelinux sebbene non strettamente legato alla questione sollevata da @andrewkrgeo (che mi sono posto anche io), ti faccio notare però un'altra zona grigia delle specifiche SPID, o meglio del validatore attualmente in uso, di cui ho ampiamente discusso con @damikael su italia/spid-saml-check#137 (comment).

La parte che citi tu riguarda il caso di attributo con valore "null". Esiste però anche la sfumatura di attributo "senza valore", che probabilmente è più vicino al dubbio di @andrewkrgeo. In questo caso la specifica, poche righe prima, dice:

The meaning of an <Attribute> element that contains no <AttributeValue> elements depends on
its context. Within an <AttributeStatement>, if the SAML attribute exists but has no values, then the
<AttributeValue> element MUST be omitted.

Faccio notare invece che il validatore ad oggi richiede necessariamente che il tag <AttributeValue> sia presente e sia vuoto in caso di mancanza di valore.

Questo solo per completare il quadro.

[peppelinux]

Ciao @mauromol, riporto qui quanto abbiamo discusso su slack.

Ti ho capito bene e ti rispondo con il cappello da sviluppatore, ovvero NULL != "" (blank).

Tutti e due a loro volta sono diversi da undefined.
Se uno sviluppatore considera nel DB di un IdP un valore blank, ecco che apparirà un attributo presente con valore assente.
Se nel DB ha NULL, ecco che saml2 chiede nil.
Se undefined, ecco che non dovrebbe essere presente, affatto.

Ora, da sviluppatore tenderei a pensare di dover gestire ogni genere di "eccezione" all'interno della mia implementazione, al contempo ritengo che questo thread possa essere arricchito dai contributi dei colleghi in AgID. Complessivamente possiamo ritenere che questo aspetto possa essere ulteriormente disambiguato @damikael

Grazie come sempre a tutti!

[mauromol]

Concordo @peppelinux, aggiungendo però quanto segue:

1. nel caso in cui SPID decida di richiedere che l'SP sia in grado di gestire tutti questi tre casi in modo distinto, allora dovrebbe dirmi per ciascuno degli attributi quali di questi tre casi sono possibili e che semantica l'SP deve associargli (es.: se il cellulare è "NULL", cosa significa? Che l'utente non vuole darmelo? E se invece è "undefined" cosa significa? Che l'utente ha dichiarato che non ha numero di cellulare?)
2. in ogni caso, ed a maggior ragione se alcuni di questi tre casi devono essere rifiutati, la cosa dovrebbe essere resa esplicita nelle regole tecniche: attualmente, come da me evidenziato in Alcuni check imposti dal tool non vengono poi implementati dagli IdP reali spid-saml-check#137, le regole tecniche non dicono nulla a riguardo, bensì è il validatore ad aver fatto una scelta di un certo tipo, che può essere o meno condivisa

Chiaramente trattasi di mie opinioni personali.

[peppelinux]

(es.: se il cellulare è "NULL", cosa significa? Che l'utente non vuole darmelo? E se invece è "undefined" cosa significa? Che l'utente ha dichiarato che non ha numero di cellulare?)

Se fossimo in un'altra federazione questo sarebbe possibile ma in SPID il consenso al rilascio è monolitico, tutto o niente. Quindi la volontà dell'utente non può escludere un singolo attributo

2. in ogni caso, ed a maggior ragione se alcuni di questi tre casi devono essere rifiutati, la cosa dovrebbe essere resa esplicita nelle regole tecniche: attualmente, come da me evidenziato in Alcuni check imposti dal tool non vengono poi implementati dagli IdP reali spid-saml-check#137, le regole tecniche non dicono nulla a riguardo, bensì è il validatore ad aver fatto una scelta di un certo tipo, che può essere o meno condivisa

Sul validatore ci stiamo lavorando con i colleghi in AgID e la comunità dei developers, tutti insieme, su spid-sp-test.
Per l'occasione stiamo migliorando la documentazione tecnica dei test e delle implementazioni, questo thread cade a fagiolo, vero @damikael?

[mauromol]

Se fossimo in un'altra federazione questo sarebbe possibile ma in SPID il consenso al rilascio è monolitico, tutto o niente. Quindi la volontà dell'utente non può escludere un singolo attributo

Ok, questa è un'informazione: l'utente o dà l'ok alla trasmissione di tutto, o di nulla. Però se spostiamo il problema alla fase di richiesta di credenziale all'IdP come la mettiamo? Se l'utente non ha il cellulare o non vuole comunicarlo?
E se parliamo di un altro dato, ad esempio l'indirizzo PEC (il "recapito digitale")? Sicuramente molti cittadini non ce l'hanno, dunque come funziona?

Il discorso che facevo al punto 1. è generale, nel senso che, appunto, se SPID vuole supportare i tre casi in modo distinto, sarebbe bene che per ogni attributo mi dicesse cosa è possibile e cosa no, e con quale semantica.

[damikael]

Ciao,
ringrazio @mauromol per le riflessioni,
sicuramente è un tema che affronteremo con maggiore attenzione per cercare di evitare ogni ambiguità
e che in parte stiamo già affrontando internamente e con @peppelinux nel definire l'insieme dei test Response non strettamente necessari al superamento della verifica tecnica.
E' importante comunque ricordare, e mi ricollego anche alla domanda iniziale di @andrewkrgeo, che gli attributi identificativi SPID, sono definiti nel DPCM del 24/10/2014
all'art.1, comma 1c

attributi identificativi: nome, cognome, luogo e data di nascita, sesso, ovvero ragione o denominazione sociale, sede legale, nonche' il codice fiscale o la partita IVA e gli estremi del documento d'identita' utilizzato ai fini dell'identificazione

e che l'art. 5 comma 1 specifica:

Le identita' digitali rilasciate all'utente contengono obbligatoriamente il codice identificativo, gli attributi identificativi e almeno un attributo secondario, funzionale alle comunicazioni tra il gestore dell'identita' digitale e l'utente.

La stessa distinzione tra attributi identificativi e attributi secondari è mantenuta nella Tabella attributi SPID.

[mauromol]

@damikael Questo è interessante, non avevo notato la differenza tra attributi identificativi e secondari.
Quindi, se capisco bene, gli attributi identificativi dovrebbero avere sempre un valore, quelli secondari potrebbero non avercelo.
Posto però che anche per gli attributi identificativi entra in gioco la tipologia di credenziale utilizzata: se, ad esempio, in fase di richiesta specifico come purpose PX e poi l'utente usa una credenziale per persona fisica ad uso professionale (una delle 3 tipologie compatibili con PX), allora l'attributo companyFiscalNumber dovrà pur arrivarmi senza valore (o non definito, o null, ecc.), nonostante si tratti di uno degli attributi identificativi... Corretto?

[damikael]

@mauromol sì, è corretto, sempre considerando che viene comunque restituito lo specifico set di attributi definito nel metadata e richiamato con la AuthnRequest.