dip -> di

examples/client_metadata/client_client_id_did.json

@@ -10,7 +10,7 @@
           "ES256K"
         ]
       },
-      "dip_vp": {
+      "di_vp": {
         "proof_type": [
           "DataIntegrityProof"
         ],

examples/client_metadata/client_code_format.json

@@ -11,7 +11,7 @@
         "ES256K"
       ]
     },
-    "dip_vp": {
+    "di_vp": {
       "proof_type": [
         "DataIntegrityProof"
       ],

examples/request/pd_dip_vc.json

@@ -1,10 +1,10 @@
 {
-  "id": "example_dip_vc",
+  "id": "example_di_vc",
   "input_descriptors": [
     {
       "id": "id_credential",
       "format": {
-        "dip_vc": {
+        "di_vc": {
           "proof_type": [
             "DataIntegrityProof"
           ],

examples/request/request_object_client_id_did.json

@@ -12,7 +12,7 @@
           "ES256K"
         ]
       },
-      "dip_vp": {
+      "di_vp": {
         "proof_type": [
           "DataIntegrityProof"
         ],

examples/request/vp_token_alternative_credentials.json

@@ -15,7 +15,7 @@
         "A"
       ],
       "format": {
-        "dip_vc": {
+        "di_vc": {
           "proof_type": [
             "DataIntegrityProof"
           ],

examples/request/vp_token_type_and_claims.json

@@ -4,7 +4,7 @@
     {
       "id": "ID card with constraints",
       "format": {
-        "dip_vc": {
+        "di_vc": {
           "proof_type": [
             "DataIntegrityProof"
           ],

examples/request/vp_token_type_only.json

@@ -4,7 +4,7 @@
     {
       "id": "id card credential",
       "format": {
-        "dip_vc": {
+        "di_vc": {
           "proof_type": [
             "DataIntegrityProof"
           ],

examples/request/vp_token_type_only_ac_and_ldp.json

@@ -9,7 +9,7 @@
         {
           "id": "id card credential",
           "format": {
-            "dip_vc": {
+            "di_vc": {
               "proof_type": [
                 "DataIntegrityProof"
               ],

examples/response/id_token_is_jose_vp.json

@@ -79,15 +79,15 @@
       "path": "$",
       "path_nested": {
         "path": "$.verifiableCredential[0]",
-        "format": "dip_vp"
+        "format": "di_vp"
       }
     },
     {
       "format": "jose_vp",
       "id": "vaccination certificate",
       "path_nested": {
         "path": "$.verifiableCredential[1]",
-        "format": "dip_vp"
+        "format": "di_vp"
       }
     }
   ],

examples/response/id_token_ref_vp_token.json

@@ -18,10 +18,10 @@
       "descriptor_map": [
         {
           "id": "ID Card with constraints",
-          "format": "dip_vp",
+          "format": "di_vp",
           "path": "$",
           "path_nested": {
-            "format": "dip_vc",
+            "format": "di_vc",
             "path": "$.verifiableCredential[0]"
           }
         }

examples/response/id_token_ref_vp_token_code.json

@@ -13,10 +13,10 @@
       "descriptor_map": [
         {
           "id": "ID Card with constraints",
-          "format": "dip_vp",
+          "format": "di_vp",
           "path": "$",
           "path_nested": {
-            "format": "dip_vc",
+            "format": "di_vc",
             "path": "$.verifiableCredential[0]"
           }
         }

examples/response/id_token_ref_vp_token_multple_vps.json

@@ -18,10 +18,10 @@
       "descriptor_map": [
         {
           "id": "ID Card with constraints",
-          "format": "dip_vp",
+          "format": "di_vp",
           "path": "$[0]",
           "path_nested": {
-            "format": "dip_vc",
+            "format": "di_vc",
             "path": "$[0].verifiableCredential[0]"
           }
         },

examples/response/presentation_submission.json

@@ -4,10 +4,10 @@
   "descriptor_map": [
     {
       "id": "ID card with constraints",
-      "format": "dip_vp",
+      "format": "di_vp",
       "path": "$",
       "path_nested": {
-        "format": "dip_vc",
+        "format": "di_vc",
         "path": "$.verifiableCredential[0]"
       }
     }

examples/response/presentation_submission_multiple_vps.json

@@ -4,10 +4,10 @@
   "descriptor_map": [
     {
       "id": "ID Card with constraints",
-      "format": "dip_vp",
+      "format": "di_vp",
       "path": "$[0]",
       "path_nested": {
-        "format": "dip_vc",
+        "format": "di_vc",
         "path": "$.verifiableCredential[0]"
       }
     },

examples/response/ps_dip_vc.json

@@ -1,13 +1,13 @@
 {
-  "definition_id": "example_dip_vc",
-  "id": "example_dip_vc_presentation_submission",
+  "definition_id": "example_di_vc",
+  "id": "example_di_vc_presentation_submission",
   "descriptor_map": [
     {
       "id": "id_credential",
       "path": "$",
-      "format": "dip_vp",
+      "format": "di_vp",
       "path_nested": {
-        "format": "dip_vc",
+        "format": "di_vc",
         "path": "$.verifiableCredential[0]"
       }
     }

examples/response/vp_token_dip_vp_with_ps.json

@@ -46,7 +46,7 @@
     "descriptor_map": [
       {
         "id": "ID Card with constraints",
-        "format": "dip_vc",
+        "format": "di_vc",
         "path": "$.verifiableCredential[0]"
       }
     ]

openid-4-verifiable-presentations-1_0.md

@@ -107,7 +107,7 @@ Cryptographic Holder Binding:
 :  Ability of the Holder to prove legitimate possession of a Verifiable Credential by proving control over the same private key during the issuance and presentation. Mechanism might depend on the Credential Format. For example, in `jose_vc` Credential Format, a Verifiable Credential with Cryptographic Holder Binding contains a public key or a reference to a public key that matches to the private key controlled by the Holder. 
 
 Claims-based Holder Binding:
-:  Ability of the Holder to prove legitimate possession of a Verifiable Credential by proofing certain claims, e.g., name and date of birth, for example by presenting another Verifiable Credential. Claims-based Holder Binding allows long term, cross device use of a Credential as it does not depend on cryptographic key material stored on a certain device. One example of such a Verifiable Credential could be a Diploma.
+:  Ability of the Holder to prove legitimate possession of a Verifiable Credential by proofing certain claims, e.g., name and date of birth, for example by presenting another Verifiable Credential. Claims-based Holder Binding allows long term, cross device use of a Credential as it does not depend on cryptographic key material stored on a certain device. One example of such a Verifiable Credential could be a diloma.
 
 Biometrics-based Holder Binding:
 :  Ability of the Holder to prove legitimate possession of a Verifiable Credential by demonstrating a certain biometric trait, such as finger print or face. One example of a Verifiable Credential with biometric Holder Binding is a mobile driving license [@ISO.18013-5], which contains a portrait of the Holder.
@@ -398,7 +398,7 @@ Content-Type: application/json
     {
       "id": "id card credential",
       "format": {
-        "dip_vc": {
+        "di_vc": {
           "proof_type": [
             "DataIntegrityProof"
           ],
@@ -533,7 +533,7 @@ Location: https://client.example.org/universal-link?
   &presentation_definition=...
   &nonce=n-0S6_WzA2Mj
   &client_metadata=%7B%22vp_formats%22:%7B%22jose_vp%22:%
-  7B%22alg%22:%5B%22EdDSA%22,%22ES256K%22%5D%7D,%22dip
+  7B%22alg%22:%5B%22EdDSA%22,%22ES256K%22%5D%7D,%22di
   _vc%22:%7B%22proof_type%22:%5B%22DataIntegrityProof%22%5D,%22
   cryptosuite%22:%5B%22ecdsa-sd-2023%22%5D%7D%7D%7D
 ```
@@ -1011,7 +1011,7 @@ brevity):
 
 The following is a non-normative example of a VP Token containing a single Verifiable Presentation after a request using Presentation Exchange:
 
-<{{examples/response/vp_token_raw_dip_vp.json}}
+<{{examples/response/vp_token_raw_di_vp.json}}
 
 The following is a non-normative example of a `presentation_submission` parameter sent alongside a VP Token in the example above. It corresponds to the second Presentation Definition example in (#request_presentation_definition):
 
@@ -1542,7 +1542,7 @@ The following is a non-normative example of the payload of a Verifiable Presenta
 
 In the example above, the requested `nonce` value is included as the `nonce` and `client_id` as the `aud` value in the proof of the Verifiable Presentation.
 
-The following is a non-normative example of a Verifiable Presentation of a format identifier `dip_vp` with an embedded `proof` property:
+The following is a non-normative example of a Verifiable Presentation of a format identifier `di_vp` with an embedded `proof` property:
 
 ```json
 {
@@ -2112,15 +2112,15 @@ Note: The VP's `nonce` claim contains the value of the `nonce` of the presentati
 
 This section illustrates presentation of a Credential conformant to [@VC_DATA] that is secured using Data Integrity, using JSON-LD.
 
-The Credential format identifiers are `dip_vc` for a W3C Verifiable Credential and `dip_vp` for W3C Verifiable Presentation.
+The Credential format identifiers are `di_vc` for a W3C Verifiable Credential and `di_vp` for W3C Verifiable Presentation.
 
 Cipher suites should use securing mechanisms names defined in [Securing Mechanisms sectino of the Verifiable Credential Extensions Note](https://www.w3.org/TR/vc-extensions/#securing-mechanisms).
 
 #### Example Credential
 
 The following is a non-normative example of the payload of a Verifiable Credential that will be used throughout this section:
 
-<{{examples/credentials/dip_vc.json}}
+<{{examples/credentials/di_vc.json}}
 
 #### Presentation Request
 
@@ -2130,9 +2130,9 @@ The following is a non-normative example of an Authorization Request:
 
 The following is a non-normative example of the contents of a `presentation_definition` parameter that contains the requirements regarding the Credential to be presented:
 
-<{{examples/request/pd_dip_vc.json}}
+<{{examples/request/pd_di_vc.json}}
 
-This `presentation_definition` parameter contains a single `input_descriptor` element, which sets the desired format to DIP VC and defines a constraint over the `type` parameter to select Verifiable Credentials of type `IDCredential`.
+This `presentation_definition` parameter contains a single `input_descriptor` element, which sets the desired format to di VC and defines a constraint over the `type` parameter to select Verifiable Credentials of type `IDCredential`.
 
 #### Presentation Response
 
@@ -2142,11 +2142,11 @@ The following is a non-normative example of an Authorization Response:
 
 The following is a non-normative example of the content of the `presentation_submission` parameter:
 
-<{{examples/response/ps_dip_vc.json}}
+<{{examples/response/ps_di_vc.json}}
 
 The following is a non-normative example of the Verifiable Presentation in the `vp_token` parameter provided in the same response and referred to by the `presentation_submission` above:
 
-<{{examples/response/dip_vp.json}}
+<{{examples/response/di_vp.json}}
 
 Note: The VP's `challenge` claim contains the value of the `nonce` of the presentation request and the `domain` claims contains the Client Identifier of the Verifier. This allows the Verifier to detect replay of a presentation as recommended in (#preventing-replay). 
 

schema/request.json

@@ -42,7 +42,7 @@
           "required": ["alg"],
           "additionalProperties": false
         },
-        "^dip_vc$|^dip_vp$|^dip$": {
+        "^di_vc$|^di_vp$|^di$": {
           "type": "object",
           "properties": {
             "proof_type": {