Adding an additional note in documentation that identifier values SHO…

…ULD be of type string

docs/context/ref/Context.md

@@ -54,11 +54,12 @@ derived types may require the name object as mandatory, depending on use case.
 
 ### `id` (optional)
 
-Context data objects may include a set of equivalent key-value pairs that can be used to help applications
-identify and look up the context type they receive in their own domain. The idea behind this design is that applications can provide as many equivalent identifiers to a target application as possible, e.g. an instrument may be represented by an ISIN, CUSIP or Bloomberg identifier.
+Context data objects may include a set of equivalent key-value pairs that can be used to help applications identify and look up the context type they receive in their own domain. The idea behind this design is that applications can provide as many equivalent identifiers to a target application as possible, e.g. an instrument may be represented by an ISIN, CUSIP or Bloomberg identifier.
 
 Identifiers do not make sense for all types of data, so the `id` property is therefore optional, but some derived types may choose to require at least one identifier.
 
+Identifier values SHOULD always be of type string.
+
 ## See Also
 
 FDC3 Specifications

docs/context/spec.md

@@ -110,6 +110,8 @@ An `id` field with type `object` is defined in the base [fdc3.context](ref/Conte
 
 Where an identifier is the name of an existing standard, external to FDC3, it is represented in all caps. For example: FIGI, PERMID, CUSIP, ISO-2. When an identifier is a more general concept, it is represented in all lower case.  For example: ticker, name, geocode, email.
 
+Identifier values SHOULD always be of type string.
+
 All standard identifier names are reserved names. Applications may use their own identifiers ad hoc. For example:
 
 ```json