Address #412 and #413 with an editorial tweak (#434)

* address #412 and #413 explicitly * reverse fluke overwrite of #422 commit * reverse fluke overwrite of #422 commit --------- Co-authored-by: bumblefudge <[email protected]>
decentralized-identity · Aug 17, 2023 · aecdef7 · aecdef7
1 parent 2fa8171
commit aecdef7
Showing 1 changed file with 19 additions and 8 deletions.
diff --git a/spec/spec.md b/spec/spec.md
@@ -307,14 +307,25 @@ be ignored, unless otherwise specified by a [[ref:Feature]];
   are being used for.
 - The [[ref:Presentation Definition]] ****MAY**** include a `format` property.
   Some envelope transport protocols may include the value of this property in
-  other locations and use different property names (See the [Format Embed Locations](#)
-  section for details), but regardless of whether it resides at the default
-  location (the `format` property of the `presentation_definition` object), the
-  value ****MUST**** be an object with one or more properties matching the registered
-  [Claim Format Designations](#claim-format-designations) (e.g., `jwt`, `jwt_vc`,
-  `jwt_vp`, etc.). The properties inform the [[ref:Holder]] of the [[ref:Claim]]
-  format configurations the [[ref:Verifier]] can process. The value for each
-  claim format property ****MUST**** be an object composed as
+  other locations and use different property names (See the [Format Embed
+  Locations](#) section for details), but regardless of whether it resides at
+  the default location (the `format` property of the `presentation_definition`
+  object), the value ****MUST**** be an object consisting of keyed arrays.  Each
+  array should be keyed to a [Claim Format
+  Designation](#claim-format-designations) (e.g., `jwt`, `jwt_vc`, `jwt_vp`,
+  etc.) registered in the governing
+  [registry](https://identity.foundation/claim-format-registry/#registry). The
+  values in each array should only be values of `alg` and/or `proofType` that
+  are valid according to this registry (and the upstream registries it relies on
+  to define valid values for `alg` or `proofType` per claim format). As these
+  upstream registries of valid profiles within each claim format may add,
+  rename, or deprecate entries over time, it is recommended that implementers
+  check both the claim format registry and its dependencies when defining these
+  objects to minimize risk of ambiguity or incompatibility with other
+  implementations. These arrays of strings thus function as enumerations of
+  supported profiles for each claim format, informing the [[ref:Holder]] of
+  which [[ref:Claim]] format configurations the [[ref:Verifier]] can process.
+  The value for each claim format property ****MUST**** be an object composed as
   follows:
     - The object ****MUST**** include a format-specific property (i.e., `alg`,
       `proof_type`) that expresses which algorithms the [[ref:Verifier]]