use array as preferred for credential types

README.md

@@ -167,6 +167,7 @@ yourself.
 ```rust
 use static_iref::uri;
 use serde::{Serialize, Deserialize};
+use ssi::claims::vc::syntax::NonEmptyVec;
 use ssi::prelude::*;
 
 // Defines the shape of our custom claims.
@@ -183,10 +184,10 @@ let credential = ssi::claims::vc::v1::JsonCredential::<MyCredentialSubject>::new
   Some(uri!("https://example.org/#CredentialId").to_owned()), // id
   uri!("https://example.org/#Issuer").to_owned().into(), // issuer
   DateTime::now(), // issuance date
-  vec![MyCredentialSubject {
+  NonEmptyVec::new(MyCredentialSubject {
     name: "John Smith".to_owned(),
     email: "john.smith@example.org".to_owned()
-  }]
+  })
 );
 
 // Create a random signing key, and turn its public part into a DID URL.
@@ -216,7 +217,7 @@ let vc = cryptosuite.sign(
   ProofOptions::from_method(verification_method)
 ).await.expect("signature failed");
 ```
- 
+
 It is critical that custom claims can be interpreted as Linked-Data. In
 the above example this is done by specifying a serialization URL for each
 field of `MyCredentialSubject`. This can also be done by creating a custom

crates/claims/crates/vc/Cargo.toml

@@ -33,7 +33,10 @@ educe.workspace = true
 base64.workspace = true
 bitvec = "0.20"
 flate2 = "1.0"
-reqwest = { version = "0.11", default-features = false, features = ["json", "rustls-tls"] }
+reqwest = { version = "0.11", default-features = false, features = [
+    "json",
+    "rustls-tls",
+] }
 ssi-verification-methods.workspace = true
 ssi-dids-core.workspace = true
 ssi-data-integrity.workspace = true

crates/claims/crates/vc/src/v1/syntax/presentation.rs

@@ -21,7 +21,7 @@ impl RequiredType for PresentationType {
 }
 
 impl TypeSerializationPolicy for PresentationType {
-    const PREFER_ARRAY: bool = false;
+    const PREFER_ARRAY: bool = true;
 }
 
 pub type JsonPresentationTypes<T = ()> = Types<PresentationType, T>;

crates/dids/methods/pkh/src/lib.rs

@@ -1313,7 +1313,7 @@ mod tests {
             ],
             "VerifiablePresentation": [
               { "name": "@context", "type": "string[]" },
-              { "name": "type", "type": "string" },
+              { "name": "type", "type": "string[]" },
               { "name": "holder", "type": "string" },
               { "name": "verifiableCredential", "type": "VerifiableCredential" },
               { "name": "proof", "type": "Proof" }

src/lib.rs

@@ -171,6 +171,7 @@
 //! # async fn main() {
 //! use static_iref::uri;
 //! use serde::{Serialize, Deserialize};
+//! use ssi::claims::vc::syntax::NonEmptyVec;
 //! use ssi::prelude::*;
 //!
 //! // Defines the shape of our custom claims.
@@ -187,10 +188,10 @@
 //!   Some(uri!("https://example.org/#CredentialId").to_owned()), // id
 //!   uri!("https://example.org/#Issuer").to_owned().into(), // issuer
 //!   DateTime::now(), // issuance date
-//!   vec![MyCredentialSubject {
+//!   NonEmptyVec::new(MyCredentialSubject {
 //!     name: "John Smith".to_owned(),
 //!     email: "john.smith@example.org".to_owned()
-//!   }]
+//!   })
 //! );
 //!
 //! // Create a random signing key, and turn its public part into a DID URL.
@@ -221,7 +222,7 @@
 //! ).await.expect("signature failed");
 //! # }
 //! ```
-//!  
+//!
 //! It is critical that custom claims can be interpreted as Linked-Data. In
 //! the above example this is done by specifying a serialization URL for each
 //! field of `MyCredentialSubject`. This can also be done by creating a custom