Merge pull request #157 from italia/address

fix: user attributes - claim address and Intermediate typo

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

docs/en/attributi_utente.rst

@@ -234,16 +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):
-       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.
+     - JSON Object (address):
 
         - "**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.
 
@@ -253,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: 
 

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<Esempio_EN1.2>`
    - :ref:`Non-normative example of EC of a RP<Esempio_EN1.1>`
-   - :ref:`Non-normative example of EC of a Federation Intermediary (SA)<Esempio_EN1.3>`
+   - :ref:`Non-normative example of EC of a Federation Intermediate (SA)<Esempio_EN1.3>`
 
 .. _entity_configuration_ta:
 

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
 ^^^^^^^^^^^^^^^^^^^^^^^^^

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<Esempio_EN1.4>`.
 
@@ -66,13 +66,13 @@ The participant MUST publish its configuration
 (Entity Configuration) at the webpath :ref:`.well-known/openid-federation<Esempio_EN1>`.
 
 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.

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:

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.
 

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).

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 <entity_role> that are recognizable inside the S
     * - **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 <trustmark_profile> that are recognizable inside
 **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::
 

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