haha 
5 Likes
actually made a bunch of progress on this today… verify server is basically done… client side javascript library is next… iOS app is in the works already.
3 Likes
5 Likes
5 Likes
Awesome. I think you are definitely going to win the race of who will finish first.
1 Like
Android app is working and almost complete… needs a few changes.
i dunno… the race is still very much on…
The thing that always seems to take the longest is the polishing process… going from 0-80% done can be very quick like in this case… but 80% - 100% is always much more difficult… the last 20% takes 80% longer than the first 80% of the project.
5 Likes
Polishing is easy in my instance so that is a fair point.
WordPress handles the polish
1 Like
So yeah… of course things got a little hung up… the problem we’re dealing with is security… specifically hardening this kind of “simple” verification service against phishing. Nothing outside of FIDO / passkeys is really all that phishing resistant, but there are measures that can be taken to at least force attackers to make an effort… so we are trying to sort out ways to ensure somebody couldn’t just slap up a simple phishing site and forward verification QR codes / links from legit sites to their phishing sites and gain access to accounts that way.
Even web nfc could have issues with this since all nfc interactions are facilitated by javascript on the client site, and a phishing site could perform the same nfc interactions with our API to obtain its own JWT.
We started down the road of basically re-inventing OpenID Connect, but realized we still want to maintain a few key features;
- No user accounts necessary
- Minimal setup for websites to integrate it
- Hardened against phishing attacks
Because of this, we need to leverage all manner of tricks across multiple operating systems, browsers, and tricky mobile environments.
5 Likes
Really appreciate the transparency and the amount of work that’s clearly going into building out VivoKey Cloud and the authentication platform. It’s clear you’re taking the time to get this right, especially with all the extra hurdles around phishing resistance and making it work smoothly across platforms.
That said, I’ve had my Spark 2 for two years now if not longer and, honestly, it’s been sitting there without much of a real-world use yet. I’d really love to finally put it to work. Carrying around a separate security key is… well, let’s just say it feels like lugging around a flip phone in 2025 — technically still works, but not exactly convenient.
Do you have any kind of timeframe on when we might see an initial release or early access to the app/features? Even a rough target would be awesome — mostly so my Spark 2 can stop being just a cool party trick and actually pull its weight lol.
1 Like
Your timing is crazy good. The main developer on the VivoKey Verify project has been sidelined for months but we literally had our “back on the wagon” strategy meeting today. There should be some significant news in the next couple weeks.
2 Likes
That’s crazy because I think I’m finally getting back into the mindset where I want to get back to work on this project. I’ll have to keep an eye out for your announcement and see how it helps with this.
1 Like
Will there any part of it that’s open source? I’d love to have a look at it security-wise.
1 Like
Good question.. the Verify API which is what this will be based on is an “open api”.. the code we will build Verify on will use the Verify API and currently I don’t see any reason to keep it closed.
4 Likes
Ok so some updates here..
-
The Verify API has undergone some changes.. we solved some icky issues with API keys being coded into mobile apps, without removing the privacy aspects of salting unique chip sub claims based on developer account IDs. We do this by depreciating the /session endpoint and instead introducing two new ones; /authenticate and /verify. Now you pass your challenge responses to /authenticate in exactly the same way you passed calls to /session, but now you get back a JWE - an encrypted JWT. This JWE is then passed from mobile app to backend, and the backend server makes the call to /verify with the JWE and the now totally private API key. It gets back the unencrypted JWT, or alternatively a call can be made to /verify.json to get back unencrypted and unsigned JSON data if the developer doesn’t want to deal with JWT libraries.
-
We are no longer going to bother with Verify API integration into websites via plugins etc. There is no way to make such a service any more secure against phishing than OTP or SMS two-factor codes. That said, we did arrive at a natural conclusion that will greatly improve the utility of Spark-type chips for individuals.. more on this coming soon™. I think the solution we’re working on now really solves the security problem outlined above and does not require websites to integrate anything new.
3 Likes