Add APID VC implementations for sign & verify, add JSON serialization for VC at UniFFI layer #251
Conversation
KendallWeihe
requested review from
nitro-neal,
kirahsapong,
shamilovtim,
diehuxx,
decentralgabe and
frankhinek
as code owners
| } | ||
| } | ||
|
|
||
| // TODO prioritize JWT claims -- hit up Neal |
| pub context: Vec<String>, | ||
| pub id: String, | ||
| pub r#type: Vec<String>, | ||
| pub issuer: String, // JSON serialized |
There was a problem hiding this comment.
This could cause confusion on if its an issuer string "did:dht:123" or an json serialized json string.
Should we rename json_serialized_issuer ?
I think sticking with the official name has value too though
There was a problem hiding this comment.
Oh yeah wow I really appreciate this idea... I think yes we should follow that practice everywhere wherein we're json serializing over the FFI (including over in tbdex, going to open a PR for that now...)
There was a problem hiding this comment.
nice, yeah I really like this idea TBD54566975/tbdex-rs#63
| self.sign_with_signer(&key_id, signer) | ||
| } | ||
|
|
||
| pub fn sign_with_signer(&self, key_id: &str, signer: Arc<dyn Signer>) -> Result<String> { |
| header.set_token_type("JWT"); | ||
| let vc_jwt = josekit::jwt::encode_with_signer(&payload, &header, &jose_signer)?; | ||
|
|
||
| Ok(vc_jwt) |
There was a problem hiding this comment.
I wonder if we should validate/verify before we give the Ok, I wonder if invalid values can sneak through to this point and we give a VC that is signed with invalid properties
There was a problem hiding this comment.
hmmmmmm maybe, but I'm not convinced yet
| } | ||
|
|
||
| fn signature_len(&self) -> usize { | ||
| 64 |
There was a problem hiding this comment.
I think there was a JoseKit Enum for this
There was a problem hiding this comment.
there is EdCurve::Ed25519 but it doesn't have the usize value associated to it
apidmodulesign(bearer_did: BearerDidmethodStringtoSystemTimeissuerandcredentialSubjectat the UniFFI layer