From 83aa28c37925b20b410aa6d44501dab9e456fbe2 Mon Sep 17 00:00:00 2001 From: Giuseppe De Marco Date: Wed, 1 Feb 2023 18:52:46 +0100 Subject: [PATCH 1/6] fix: user attributes - claim address --- docs/en/attributi_utente.rst | 7 +------ docs/it/attributi_utente.rst | 7 +------ 2 files changed, 2 insertions(+), 12 deletions(-) diff --git a/docs/en/attributi_utente.rst b/docs/en/attributi_utente.rst index eaafa326..efc8ae41 100644 --- a/docs/en/attributi_utente.rst +++ b/docs/en/attributi_utente.rst @@ -234,12 +234,7 @@ The following table shows the list of user attributes supported by SPID and/or C ``"$PREFIX/eid_exp_date":"2002-09-24"`` - |spid-icon| * - **address** |br| Category: extra registry - - Physical home address |br| - ZIP code |br| - City |br| - Province |br| - Country |br|. - JSON Object (address): + - JSON Object (address): Formatted, **street_address** (**mandatory**), locality, region, postal_code, country, country_code The attribute contains the address type (via, viale, piazza …), the address and the house number. diff --git a/docs/it/attributi_utente.rst b/docs/it/attributi_utente.rst index ca56217f..fb54dd14 100644 --- a/docs/it/attributi_utente.rst +++ b/docs/it/attributi_utente.rst @@ -236,12 +236,7 @@ La seguente tabella riporta l'elenco degli attributi utente supportati da SPID e ``"$PREFIX/eid_exp_date":"2002-09-24"`` - |spid-icon| * - **address** |br| Categoria: extra anagrafica - - Indirizzo domicilio fisico |br| - CAP domicilio fisico |br| - Comune domicilio fisico |br| - Provincia domicilio fisico |br| - Nazione domicilio fisico |br|. - JSON Object (address): + - JSON Object (address): Formatted, **street_address** (**obbigatorio**),locality, region, postal_code,country, country_code L'attributo contiene la tipologia (via, viale, piazza …), l'indirizzo e il numero civico. From 2c3f2fd7e8a6ec5bb2452d2c291f1887d923779a Mon Sep 17 00:00:00 2001 From: Giuseppe De Marco Date: Mon, 6 Feb 2023 11:03:48 +0100 Subject: [PATCH 2/6] fix: English typo -> Intermediates --- README.md | 4 ++-- docs/en/entity_configuration.rst | 6 +++--- docs/en/entity_statement.rst | 4 ++-- docs/en/la_federazione_delle_identita.rst | 12 ++++++------ docs/en/metadata_oidc_ta_sa.rst | 2 +- docs/en/seccons_bcps.rst | 4 ++-- docs/en/termini_acronimi.rst | 14 +++++++------- docs/en/trust_marks.rst | 16 ++++++++-------- docs/en/trust_negotiation.rst | 8 ++++---- 9 files changed, 35 insertions(+), 35 deletions(-) diff --git a/README.md b/README.md index 264f5967..bfbea16e 100644 --- a/README.md +++ b/README.md @@ -20,8 +20,8 @@ ## Intro This repository is mantained by the Department for Digital Transformation, -the Agency for Digital Italy (AgID), the State Mint and Printing Institute -(IPZS) and hosts the sphinx project tree of SPID/CIE OpenID Connect technical specifications, +the Agency for Digital Italy (AgID), Polygraphic Institute and the State Mint +(Istituto Poligrafico e Zecca dello Stato) and hosts the sphinx project tree of SPID/CIE OpenID Connect technical specifications, published to [Docs Italia](https://docs.italia.it/docs/spid-cie-oidc-docs/) and [Github pages](https://italia.github.io/spid-cie-oidc-docs/). ## Documentation diff --git a/docs/en/entity_configuration.rst b/docs/en/entity_configuration.rst index b3eb0ece..3b2c074b 100644 --- a/docs/en/entity_configuration.rst +++ b/docs/en/entity_configuration.rst @@ -67,8 +67,8 @@ Entity Configuration - common claims Inside the EC the claims **iss** e **sub** contain the same value (URL). -Entity Configuration Leaves and Intermediaries -++++++++++++++++++++++++++++++++++++++++++++++ +Entity Configuration Leaves and Intermediates ++++++++++++++++++++++++++++++++++++++++++++++ In addition to the previously defined claims, the EC of the Leaf and Intermediate Entities, contain also the following claims: @@ -94,7 +94,7 @@ the following claims: - :ref:`Non-normative example of EC of an OP` - :ref:`Non-normative example of EC of a RP` - - :ref:`Non-normative example of EC of a Federation Intermediary (SA)` + - :ref:`Non-normative example of EC of a Federation Intermediate (SA)` .. _entity_configuration_ta: diff --git a/docs/en/entity_statement.rst b/docs/en/entity_statement.rst index 62dfe8f5..8ad31ccf 100644 --- a/docs/en/entity_statement.rst +++ b/docs/en/entity_statement.rst @@ -22,7 +22,7 @@ The same considerations made for the **ECs** and reported in the section :ref:`F Entity Statement ++++++++++++++++ -The ES issued by the TA or by an Intermediary for its own direct subordinates, MUST contain the following attributes: +The ES issued by the TA or by an Intermediate for its own direct subordinates, MUST contain the following attributes: .. list-table:: @@ -72,7 +72,7 @@ The ES issued by the TA or by an Intermediary for its own direct subordinates, M Metadata Policy +++++++++++++++ -Trust Anchors and Intermediaries (SAs) MUST publish a policy regarding their respective descendants in the Entity Statement referring to them. The Metadata Policy MUST cascade to all descendants. +Trust Anchors and Intermediates (SAs) MUST publish a policy regarding their respective descendants in the Entity Statement referring to them. The Metadata Policy MUST cascade to all descendants. TA Metadata Policy for RP ^^^^^^^^^^^^^^^^^^^^^^^^^ diff --git a/docs/en/la_federazione_delle_identita.rst b/docs/en/la_federazione_delle_identita.rst index 7e12ebdc..ec2342b1 100644 --- a/docs/en/la_federazione_delle_identita.rst +++ b/docs/en/la_federazione_delle_identita.rst @@ -42,8 +42,8 @@ The OIDC Federation produces an infrastructure of trust that is: .. image:: ../../images/spid_cie_oidc_federation_model.svg :width: 100% -*At the base of the trees there are the Federation Authorities of SPID and CIE id and, going up, the OPs that have no Intermediaries, the RPs and the -Intermediaries that, in turn, aggregate other RPs.* +*At the base of the trees there are the Federation Authorities of SPID and CIE id and, going up, the OPs that have no Intermediates, the RPs and the +Intermediates that, in turn, aggregate other RPs.* Configuration of the Federation +++++++++++++++++++++++++++++++ @@ -53,7 +53,7 @@ The configuration of the Federation is published by the Trust Anchor inside its All the members MUST obtain the Federation configuration before the operational phase and they MUST keep it up-to-date on a daily basis. The Federation configuration contains the Trust Anchor -public keys for the signature operations, the maximum number of Intermediaries allowed between a Leaf and the Trust Anchor (**max_path length**) and the authorities who are enabled to issue the Trust Marks (**trust_marks_issuers**). +public keys for the signature operations, the maximum number of Intermediates allowed between a Leaf and the Trust Anchor (**max_path length**) and the authorities who are enabled to issue the Trust Marks (**trust_marks_issuers**). Here a non-normative example of :ref:`Entity Configuration response Trust Anchor`. @@ -66,13 +66,13 @@ The participant MUST publish its configuration (Entity Configuration) at the webpath :ref:`.well-known/openid-federation`. The technical and administrative representatives complete the onboarding procedure, -defined by the Federation Authority or by an Intermediary (SA), +defined by the Federation Authority or by an Intermediate (SA), in order to register a new Entity or for updating a preexisting one. -The Federation Authority or an Intermediary, after doing all the required technical and administrative controls, registers the public keys of the onboarded Entity and releases a proof of Federation membership, +The Federation Authority or an Intermediate, after doing all the required technical and administrative controls, registers the public keys of the onboarded Entity and releases a proof of Federation membership, in the form of Trust Mark (TM). The Leaf MUST include the TM inside its own Federation configuration (Entity Configuration) as proof of success in the Onboarding process. -The Federation Authority or an Intermediary MUST publish the Leaf Entity Statement containing the Federation public keys of the onboarded Entity and the TMs released for it. +The Federation Authority or an Intermediate MUST publish the Leaf Entity Statement containing the Federation public keys of the onboarded Entity and the TMs released for it. diff --git a/docs/en/metadata_oidc_ta_sa.rst b/docs/en/metadata_oidc_ta_sa.rst index 5e8e6af4..a5bb5e1c 100644 --- a/docs/en/metadata_oidc_ta_sa.rst +++ b/docs/en/metadata_oidc_ta_sa.rst @@ -2,7 +2,7 @@ .. _MetadataTA: -Trust Anchor (TA) and Intermediary (SA) Metadata +Trust Anchor (TA) and Intermediate (SA) Metadata ++++++++++++++++++++++++++++++++++++++++++++++++ A TA and a SA MUST publish in the EC a Metadata of type *federation_entity*, as reported in the following example: diff --git a/docs/en/seccons_bcps.rst b/docs/en/seccons_bcps.rst index 233c8a78..f53cf4f1 100644 --- a/docs/en/seccons_bcps.rst +++ b/docs/en/seccons_bcps.rst @@ -22,9 +22,9 @@ be started and consequently MUST NOT create connections to third party systems. Maximum Number of authority_hints +++++++++++++++++++++++++++++++++ -Inside a Federation, through the constraint named **max_path_lenght**, the Trust Anchor decides how many intermediaries are allowed between it and the Leaves. This kind of relationship is vertical, from the Leaf to the root. As an example, if this attribute has the value equal to 1, it means that only one SA is allowed between a Leaf and the TA. +Inside a Federation, through the constraint named **max_path_lenght**, the Trust Anchor decides how many Intermediates are allowed between it and the Leaves. This kind of relationship is vertical, from the Leaf to the root. As an example, if this attribute has the value equal to 1, it means that only one SA is allowed between a Leaf and the TA. -Every Leaf MUST publish its superiors inside the list contained in the claim **authority_hints**. A Leaf in the Federation MAY have superiors belonging to different Federations. The analysis of the available superiors introduces an horizontal navigation model. As an example, an OP tries to find the shortest path to the Trust Anchor through all the URLs contained in the array **authority_hints**, before doing a further vertical move upwards, to one of the Intermediaries that are present in this array. +Every Leaf MUST publish its superiors inside the list contained in the claim **authority_hints**. A Leaf in the Federation MAY have superiors belonging to different Federations. The analysis of the available superiors introduces an horizontal navigation model. As an example, an OP tries to find the shortest path to the Trust Anchor through all the URLs contained in the array **authority_hints**, before doing a further vertical move upwards, to one of the Intermediates that are present in this array. The threshold **max_path_lenght** is applied to the vertical navigation and, after exceeding this threshold without finding a TA, the procedure of Federation Entity Discovery MUST be stopped. Consider the example of an RP that's a subordinate of an SA that's in turn a subordinate of another SA, while the **max_path_lenght** claim is equal to 1 and, after exceeding this threshold without finding the Trust Anchor, the procedure MUST be stopped. diff --git a/docs/en/termini_acronimi.rst b/docs/en/termini_acronimi.rst index 0964a04d..0e46985d 100644 --- a/docs/en/termini_acronimi.rst +++ b/docs/en/termini_acronimi.rst @@ -17,17 +17,17 @@ Terms used by `OIDC-FED#Section_1.2`_ and this documentation. funcional aspects and the onboarding procedures. * - **Trust Anchor** - Entity handled by the Federation Authority that represents the Federation, its configuration and the trust root. - * - **Intermediate Entity** or **Intermediary** - - An Intermediate Entity (SA), facilitates the onboarding process in the Federation and MAY handle the functionalities on behalf of its subordinate (aggregated) Entities. Inside the Federation, the Intermediary publishes its configuration and the Entity statements of its subordinates, according to the rules defined by Fedetarion Authority. + * - **Intermediate Entity** or **Intermediate** + - An Intermediate Entity (SA), facilitates the onboarding process in the Federation and MAY handle the functionalities on behalf of its subordinate (aggregated) Entities. Inside the Federation, the Intermediate publishes its configuration and the Entity statements of its subordinates, according to the rules defined by Fedetarion Authority. * - **Leaf Entity** or **Leaf** - Entity defined by OpenID Connect as Relying Party and OpenID Provider. It could also be an Attribute Authority (OAuth2 Authorization Server and Resource Server). * - **Entity** - - Participant to the the Federation. It may be a Trust Anchor, Intermediary or Leaf. + - Participant to the the Federation. It may be a Trust Anchor, Intermediate or Leaf. * - **Entity Configuration** - Federation metadata issued by an Entity about itself, in the form of a self-signed JWT :rfc:`7515`. It contains the public Federation's signing keys, the OIDC metadata, the URLs of its superiors authorities and the Trust Marks issued by authorities that are recognizable inside the Federation and that certify the Entity's compliance to specific profiles. * - **Entity Statement** - - Statement issued by a superior Entity (Trust Anchor or Intermediary) regarding - a subordinate subject (RP, OP or Intermediary), in the form of a signed JWT :rfc:`7515`, containing + - Statement issued by a superior Entity (Trust Anchor or Intermediate) regarding + a subordinate subject (RP, OP or Intermediate), in the form of a signed JWT :rfc:`7515`, containing the public key of the Entity, the Trust Marks issued by the Entity itself and the Metadata policy to be applied to the subject's Metadata. * - **Trust Mark** @@ -41,7 +41,7 @@ Terms used by `OIDC-FED#Section_1.2`_ and this documentation. specifying what values and values subsets are allowed for a given Metadata claim. * - **Authority hint** - An array of URLs containing the identifiers of the superior Entities, Trust Anchor or - Intermediary, that MUST issue an Entity Statement for their own subordinates. + Intermediate, that MUST issue an Entity Statement for their own subordinates. * - **Federation Entity Discovery** - Collection of Entity Configuration / Statements, from a Leaf Entity up to the Trust Anchor * - **Trust Chain** @@ -87,7 +87,7 @@ In this section are defined all the acronyms that are used throughout the text. * - **RP** - Relying Party (Leaf Entity). * - **SA** - - Intermediate Entity or Intermediary. An intermediate Entity that can handle all the Federation + - Intermediate Entity or Intermediate. An intermediate Entity that can handle all the Federation aspects of one or more RPs. * - **AA** - Attribute Authority, handler of the qualified attribues (Leaf Entity). diff --git a/docs/en/trust_marks.rst b/docs/en/trust_marks.rst index 9427b135..1355052d 100644 --- a/docs/en/trust_marks.rst +++ b/docs/en/trust_marks.rst @@ -14,11 +14,11 @@ Typical examples include the Entity's national or international identification c by the issuing subject. During the registration process of a new Leaf Entity (onboarding), the TMs are issued and signed by the TA -or its Intermediaries (SA) or by Attribute Authorities (AA), if they are defined inside the attribute **trust_mark_issuers**, published inside the TA's Entity Configuration. +or its Intermediates (SA) or by Attribute Authorities (AA), if they are defined inside the attribute **trust_mark_issuers**, published inside the TA's Entity Configuration. Each member Entity MUST expose, in its own configuration (EC), the TMs released by the issuing authorities. -In the CIE / SPID scenario, a TM is signed by the TA **MinInterno** / **Agid** or their Intermediaries (SA) or by Attribute Authorities (AA). +In the CIE / SPID scenario, a TM is signed by the TA **MinInterno** / **Agid** or their Intermediates (SA) or by Attribute Authorities (AA). The TA defines the subjects who are enabled to issue TMs that are recognizable inside the Federation, and this is done by the claim **trust_marks_issuers**, contained in its own Entity Configuration. @@ -33,18 +33,18 @@ In the following, a non-normative example of the object **trust_marks_issuers** "trust_marks_issuers":{ "https://registry.agid.gov.it/openid_relying_party/public/":[ "https://registry.spid.agid.gov.it/", - "https://public.intermediary.spid.it/" + "https://public.intermediate.spid.it/" ], "https://registry.agid.gov.it/openid_relying_party/private/":[ "https://registry.spid.agid.gov.it/", - "https://private.other.intermediary.it/" + "https://private.other.intermediate.it/" ] } } Each member Entity MUST expose in its configuration (EC), the TMs released by the issuing authority. -In the CIE / SPID scenario, a TM is signed by the TA **MinInterno** / **Agid** or their Intermediaries (SA) or +In the CIE / SPID scenario, a TM is signed by the TA **MinInterno** / **Agid** or their Intermediates (SA) or Attribute Authorities (AA). The TA defines the subjects that are enabled to issue TMs that are recognizable inside the Federation, @@ -83,8 +83,8 @@ The following table defines the that are recognizable inside the * - **openid_provider** - the Entity in the claim *sub* is an OP. - OP - * - **intermediary** - - the Entity in the claim *sub* is an Intermediary. + * - **intermediate** + - the Entity in the claim *sub* is an Intermediate. - SA * - **oauth_resource** - the Entity in the claim *sub* is an Attribute Authority. @@ -111,7 +111,7 @@ The following table defines the that are recognizable insid **federation_entity** Trust Mark -------------------------------- -In addition to the claims of the **public** and **private** profiles, the profile **intermediary** identifies the SA and adds the extensions **full** and **light** in the **sa_profile** claim, according to the ways of operation towards the subordinate Entities. +In addition to the claims of the **public** and **private** profiles, the profile **intermediate** identifies the SA and adds the extensions **full** and **light** in the **sa_profile** claim, according to the ways of operation towards the subordinate Entities. .. seealso:: diff --git a/docs/en/trust_negotiation.rst b/docs/en/trust_negotiation.rst index 8d74238f..81ee9061 100644 --- a/docs/en/trust_negotiation.rst +++ b/docs/en/trust_negotiation.rst @@ -22,7 +22,7 @@ the Metadata of all the OPs, renewing their related Trust Chain. After obtaining the final Metadata of all the OpenID Connect Providers, the RP generates the **SPID button** or **CIE button** and publishes it inside its authentication page. -The procedure of Federation Entity Discovery for the RPs gets simplified because, inside the Federation, the existence of Intermediaries between the OPs and their Trust Anchor is not allowed. +The procedure of Federation Entity Discovery for the RPs gets simplified because, inside the Federation, the existence of Intermediates between the OPs and their Trust Anchor is not allowed. .. image:: ../../images/metadata_discovery.svg @@ -67,20 +67,20 @@ renew the RP Metadata, according to the Trust Chain renewal procedure. After obtaining the final Metadata, the Provider validates the request sent by RP. In case an RP has a SA as a superior Entity and not directly the TA, the procedure of achieving and validating the Entity Configuration of the RP occurs through the Entity Statement published -by the SA towards the RP and through validating the Entity Configuration of the SA with the Entity Statement issued by the TA towards the SA. If the threshold of the maximum number of vertical Intermediaries, +by the SA towards the RP and through validating the Entity Configuration of the SA with the Entity Statement issued by the TA towards the SA. If the threshold of the maximum number of vertical Intermediates, defined by the value **max_path_length**, is exceeded, the OP stops the process of Federation Entity Discovery and rejects the RP request. .. [1] The Federation Trust Marks are configured in the claim **trust_marks_issuers** and contained in the Entity Configuration of the Trust Anchor. -.. [2] An RP can expose more than one superior Entity inside its own claim **authority_hints**. An example is an RP that takes part both in the SPID and in the CIE Federation. Besides, an RP can result as a subordinate of more than one Intermediaries, either of SPID or CIE. +.. [2] An RP can expose more than one superior Entity inside its own claim **authority_hints**. An example is an RP that takes part both in the SPID and in the CIE Federation. Besides, an RP can result as a subordinate of more than one Intermediates, either of SPID or CIE. .. image:: ../../images/trust_anchor.svg :width: 100% *Each member exposes its own configuration and its own Trust Marks. The link between a Leaf and -the Trust Anchor occurs directly or through an Intermediary (SA) as in the picture.* +the Trust Anchor occurs directly or through an Intermediate (SA) as in the picture.* Access to the Entity Configuration From 257a9f44175b2b578a775a10d5ac4d787f8fb4c3 Mon Sep 17 00:00:00 2001 From: Giuseppe De Marco Date: Tue, 7 Feb 2023 15:41:43 +0100 Subject: [PATCH 3/6] fix: typo in user claims address --- docs/en/attributi_utente.rst | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/docs/en/attributi_utente.rst b/docs/en/attributi_utente.rst index efc8ae41..e3280fc2 100644 --- a/docs/en/attributi_utente.rst +++ b/docs/en/attributi_utente.rst @@ -235,12 +235,8 @@ The following table shows the list of user attributes supported by SPID and/or C - |spid-icon| * - **address** |br| Category: extra registry - JSON Object (address): - Formatted, **street_address** - (**mandatory**), locality, region, postal_code, country, country_code - The attribute contains the address type (via, viale, piazza …), the address and the house number. - The three informations are preferably sorted as in the specific countries. - - "**street_address**": The attribute contains the address type (via, viale, piazza …), the address and the house number. The three informations are preferably sorted as in the specific countries. + - "**street_address (**mandatory**)**": The attribute contains the address type (via, viale, piazza …), the address and the house number. The three informations are preferably sorted as in the specific countries. - "**postal_code**": ZIP From f0993369f310702dd1ebe7d9fa0a8e1dfd727ed7 Mon Sep 17 00:00:00 2001 From: Giuseppe De Marco Date: Tue, 7 Feb 2023 15:43:41 +0100 Subject: [PATCH 4/6] fix: typo in user claims address ITA --- docs/it/attributi_utente.rst | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/docs/it/attributi_utente.rst b/docs/it/attributi_utente.rst index fb54dd14..32eec289 100644 --- a/docs/it/attributi_utente.rst +++ b/docs/it/attributi_utente.rst @@ -237,12 +237,8 @@ La seguente tabella riporta l'elenco degli attributi utente supportati da SPID e - |spid-icon| * - **address** |br| Categoria: extra anagrafica - JSON Object (address): - Formatted, **street_address** - (**obbigatorio**),locality, region, postal_code,country, country_code - L'attributo contiene la tipologia (via, viale, piazza …), l'indirizzo e il numero civico. - Le tre informazioni sono preferibilmente ordinate come d'uso per lo specifico Stato. - - "**street_address**":L'attributo contiene la tipologia (via, viale, piazza …), l'indirizzo e il numero civico. Le tre informazioni sono preferibilmente ordinate come d'uso per lo specifico Stato. + - "**street_address** (**obbligatorio**)":L'attributo contiene la tipologia (via, viale, piazza …), l'indirizzo e il numero civico. Le tre informazioni sono preferibilmente ordinate come d'uso per lo specifico Stato. - "**postal_code**": CAP From 3ea5a71568004c6872d1cb92df61256b80dc9470 Mon Sep 17 00:00:00 2001 From: Giuseppe De Marco Date: Tue, 7 Feb 2023 15:46:53 +0100 Subject: [PATCH 5/6] fix: typo in user claims address --- docs/en/attributi_utente.rst | 2 +- docs/it/attributi_utente.rst | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/en/attributi_utente.rst b/docs/en/attributi_utente.rst index e3280fc2..8b7263ca 100644 --- a/docs/en/attributi_utente.rst +++ b/docs/en/attributi_utente.rst @@ -236,7 +236,7 @@ The following table shows the list of user attributes supported by SPID and/or C * - **address** |br| Category: extra registry - JSON Object (address): - - "**street_address (**mandatory**)**": The attribute contains the address type (via, viale, piazza …), the address and the house number. The three informations are preferably sorted as in the specific countries. + - "**street_address**": The attribute contains the address type (via, viale, piazza …), the address and the house number. The three informations are preferably sorted as in the specific countries. - "**postal_code**": ZIP diff --git a/docs/it/attributi_utente.rst b/docs/it/attributi_utente.rst index 32eec289..f6f6931a 100644 --- a/docs/it/attributi_utente.rst +++ b/docs/it/attributi_utente.rst @@ -238,7 +238,7 @@ La seguente tabella riporta l'elenco degli attributi utente supportati da SPID e * - **address** |br| Categoria: extra anagrafica - JSON Object (address): - - "**street_address** (**obbligatorio**)":L'attributo contiene la tipologia (via, viale, piazza …), l'indirizzo e il numero civico. Le tre informazioni sono preferibilmente ordinate come d'uso per lo specifico Stato. + - "**street_address**":L'attributo contiene la tipologia (via, viale, piazza …), l'indirizzo e il numero civico. Le tre informazioni sono preferibilmente ordinate come d'uso per lo specifico Stato. - "**postal_code**": CAP From a964e043fe124e19355a30d5d35a5fae57634983 Mon Sep 17 00:00:00 2001 From: Giuseppe De Marco Date: Tue, 7 Feb 2023 15:47:34 +0100 Subject: [PATCH 6/6] fix: typo in user claims address - spacing --- docs/en/attributi_utente.rst | 2 +- docs/it/attributi_utente.rst | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/en/attributi_utente.rst b/docs/en/attributi_utente.rst index 8b7263ca..33345075 100644 --- a/docs/en/attributi_utente.rst +++ b/docs/en/attributi_utente.rst @@ -244,7 +244,7 @@ The following table shows the list of user attributes supported by SPID and/or C - "**region**": Province - - "**country_code**" : Country + - "**country_code**": Country Example: diff --git a/docs/it/attributi_utente.rst b/docs/it/attributi_utente.rst index f6f6931a..aab0ebf6 100644 --- a/docs/it/attributi_utente.rst +++ b/docs/it/attributi_utente.rst @@ -238,15 +238,15 @@ La seguente tabella riporta l'elenco degli attributi utente supportati da SPID e * - **address** |br| Categoria: extra anagrafica - JSON Object (address): - - "**street_address**":L'attributo contiene la tipologia (via, viale, piazza …), l'indirizzo e il numero civico. Le tre informazioni sono preferibilmente ordinate come d'uso per lo specifico Stato. + - "**street_address**": L'attributo contiene la tipologia (via, viale, piazza …), l'indirizzo e il numero civico. Le tre informazioni sono preferibilmente ordinate come d'uso per lo specifico Stato. - "**postal_code**": CAP - - "**locality**":Comune + - "**locality**": Comune - "**region**": Provincia - - "**country_code**" : Nazione + - "**country_code**": Nazione Esempio: