From c3fd8e0f537099fe0d983ac19ae0d0dacce2f663 Mon Sep 17 00:00:00 2001
From: peppelinux <demarcog83@gmail.com>
Date: Sun, 23 Jul 2023 06:57:46 +0200
Subject: [PATCH] normative lang, media type for EC, RP PE typos

---
 docs/en/defined-terms.rst          |  7 +++++++
 docs/en/relying-party-solution.rst | 11 +++--------
 docs/en/trust.rst                  |  5 ++++-
 3 files changed, 14 insertions(+), 9 deletions(-)

diff --git a/docs/en/defined-terms.rst b/docs/en/defined-terms.rst
index 2df421bfe..73bd92d33 100644
--- a/docs/en/defined-terms.rst
+++ b/docs/en/defined-terms.rst
@@ -2,6 +2,13 @@
 
 .. _defined-terms.rst:
 
+
+Normative Language and Conventions
+++++++++++++++++++++++++++++++++++
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
+
+
 Defined Terms
 +++++++++++++
 
diff --git a/docs/en/relying-party-solution.rst b/docs/en/relying-party-solution.rst
index 971996ef5..a35bf3e4a 100644
--- a/docs/en/relying-party-solution.rst
+++ b/docs/en/relying-party-solution.rst
@@ -340,10 +340,10 @@ Here a non-normative example of ``presentation_definition``:
 
   {
     "presentation_definition": {
-      "id": "pid-sd-jwt:unique_id+given_name+family_name",
+      "id": "presentation definitions",
       "input_descriptors": [
         {
-          "id": "eu.europa.ec.eudiw.pid.it.1",
+          "id": "pid-sd-jwt:unique_id+given_name+family_name",
           "name": "Person Identification Data",
           "purpose": "User authentication",
           "format": "vc+sd-jwt",
@@ -409,14 +409,9 @@ Below is a non-normative example of the decrypted JSON ``response`` content:
         "id": "04a98be3-7fb0-4cf5-af9a-31579c8b0e7d",
         "descriptor_map": [
             {
-                "id": "eu.europa.ec.eudiw.pid.it.1:unique_id",
+                "id": "pid-sd-jwt:unique_id+given_name+family_name",
                 "path": "$.vp_token.verified_claims.claims._sd[0]",
                 "format": "vc+sd-jwt"
-            },
-            {
-                "id": "eu.europa.ec.eudiw.pid.it.1:given_name",
-                "path": "$.vp_token.verified_claims.claims._sd[1]",
-                "format": "vc+sd-jwt"
             }
         ]
     }
diff --git a/docs/en/trust.rst b/docs/en/trust.rst
index 8fa149c8c..44dd1652d 100644
--- a/docs/en/trust.rst
+++ b/docs/en/trust.rst
@@ -254,7 +254,10 @@ Below is a non-normative example of a Trust Anchor Entity Configuration, where e
 Entity Configuration
 --------------------
 
-The Entity Configuration is the verifiable document that each Federation Entity must publish on its own behalf.
+The Entity Configuration is the verifiable document that each Federation Entity must publish on its own behalf in the web path **.well-known/openid-federation**.
+
+The Entity Confgiuration HTTP response MUST have the media type `application/entity-statement+jwt`.
+
 The Entity Configuration must be cryptographically signed. The public part of this key must be present in the
 Entity Configuration and within the Entity Statement issued by a immediate superior concerning the Federation Entity.