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.