search

Sphereon-Opensource / mobile-wallet

Open-Source Mobile SSI Wallet
Apache License 2.0
68 stars 23 forks source link

Hey there, just a couple questions. #274

Open its-danny opened 2 months ago

its-danny commented 2 months ago

I'm working on an app (https://github.com/mist-id/mist), and I've been using your wallet for testing (thank you very much, btw). I've had a couple of questions while working on it that I'm hoping you can shed some light on.

  1. The wallet sends key_opts as sig. Looking at the spec, shouldn't this be verify? Or if not, then sign?
  2. The returned VCs are wrapped in something like { verifiable_credential: [ vc: ... ] }. This isn't in the spec or anything unless I missed it. Is this a standard I should be aware of?
nklomp commented 2 months ago

I'm working on an app (https://github.com/mist-id/mist), and I've been using your wallet for testing (thank you very much, btw). I've had a couple of questions while working on it that I'm hoping you can shed some light on.

  1. The wallet sends key_opts as sig. Looking at the spec, shouldn't this be verify? Or if not, then sign?

Would you happen to have a link to the source code you mentiond. Be advised that currently our SDK is pretty much in flux and as a result our web and mobile/edge wallet as well. This has to do with us removing things like strict dependencies on DIDs and other improvements to be more in line with EIDAS2/ARF (like adding support for SD-JWT and mdl/mdoc).

  1. The returned VCs are wrapped in something like { verifiable_credential: [ vc: ... ] }. This isn't in the spec or anything unless I missed it. Is this a standard I should be aware of?

What we are doing is basically mapping internally everything onto a VCM Datamodel 1.1 format. We support JSON-LD, JWTs, and in some branches also SD-JWTs and Mdocs. Then for our wallet to display things in a uniform way, we are basically mapping them all onto a json-ld like representation. Where we then map the original signature and payloads onto the proof object(s) in that credential.

The json-ld credential and JWT credential are of course mentioned in VCDM 1.1. The JWT is decoded into a json-ld credential, and then we add an artificial jwtProof2020 to it with a jwt key that is the original JWT encoded credential, so we can always get back to the original format. The vc key you mention is part of the VCDM 1.1 model. vp and vc are the objects you need in a presentation and credential JWT object respectively according to 1.1

Hope that helps. Happy to see the actual code path to your first question