the fundamental difference is pin code based association. the phone app does also use an oauth token approach to authorization along with other measures like certificate pinning, but the pin code is the crux of it. since the pin code is a critical aspect of account security, we don’t want 3rd party clients accepting pin codes, period.
this is in no way finalized, but the idea is that we’d have a kind of “register” endpoint that the desktop client would use to associate that client with your profile so it’s able to basically process scan requests for you and anyone else associated with that client. then, when you scan, the client polls for pending scan requests… if there is only one, it could automatically grab the challenge from the server and submit to the chip, then send back the response to confirm… but if there are multiple then you’d have to probably display options, pick one, then scan again.
There are more details that need to be worked out of course, but that would be the general idea. Also the Spark 1 should be supported if the reader hardware supports ISO15693… that would be a good idea… but might require hardware detection and specialized command transforms since various PC/SC readers all have different APDU and transparent modes for pass-through commands that android and iOS abstract (annoying).
This seems odd, I obviously am missing something because I can not see any way that the pin should be critical to anything. You should not even need to tie the client to the account except for push notifications from what I can tell.
Should the implant not be enough validation of identity? Is that not the whole point?
Thinking about the attack surface, by adding the pin you are essentially adding a second factor of authentication to the client device on it’s first use. This makes some amount of sense as otherwise someone could use any reader to log in as you.
My question then probably should be why force the use of a phone for the client association. Why not provide an endpoint that the user is sent to? Basically if you are adding a password/pin step for first time device registration why not use an outh flow that clients can implement. I can see why it would not be a priority currently but it seems unnecessary to force me to use a phone as a secure element as well as my implant.
Also as a side note, it would be cool if the API allowed for the validation of a scan without linking to the users account, basically I am thinking for use cases like the Annual Cyborg Meet-up where you could use the VivoKey implant as an ID system.
Chip auth alone isn’t safe. Remember: it’s in you, but ultimately it’s only the chip that gets identified. If you’re unconscious (read: asleep), the PIN prevents your unprincipled wife from scanning your hand and logging in as you.
What I am confused about is why the app has to be the exclusive way of registering a client. Specifically this bit:
There are plenty of ways this can work without hard locking to the offical app such as implementing a pin/password based oauth flow for associating a client with a user for the first time.
Totally understand it not being a priority, one of the reasons I was more pushing for the API to be opened was so that we can contribute but I understand why that also is not a priority.
yep this is actually what i was talking about… your desktop client could walk through the oauth flow and you authorize the client by getting a notification on your phone and scan your chip… then your profile is associated with that desktop client.
It’s always a balance between user privacy and utility… would you want anyone who scanned your VivoKey to have a method to automatically pull your user profile details without your even being aware of it or somehow authorizing it? This is why the openid connect scopes the relying party want access to must be approved before the access and identity tokens are granted.
well, i guarantee my wife would just use my phone… we all know each other’s unlock patterns
I was more meaning, I try to set up new client on PC
Get sent to vivokey.com/newclient
Type in pin
No need for phone, and no need for 3rd party to have pin.
To be clear, having the phone as part of the flow is not a deal breaker (would be a bit late for that ) just seems unnecessary and would limit use cases like “Fuck broke my phone, need to login here”
ok so off the top of my head, the access token is what links us back to the vivokey profile on the server side… so without a token you’d need some sort of vivokey profile identifier you’d issue to the API that would then inform us which profile to push a scan request to… so the only way to get that would be to have a previous authorized identity token from which you pulled the profile sub data from… it just gets… complicated.
yeah i know… it’s the pin handling that is at issue… keyloggers, spoofers, malicious 3rd party vivokey clients that record PIN codes… i mean, anyone could put a fake app together that asks the user for their PIN but the important part for us is to be able to say “nothing will ask for your account PIN except the official vivokey app”… i mean we are even careful not to use a standard phone keyboard for PIN entry because keys can be logged by those keyboards… and we block screen captures on that (and other critical) screens to protect the pin. It’s the only bit of “something you know” we use, and we are defend the hell out of that one bit.
After you authorize the desktop client with a chip scan, then your client is active an no longer needs the phone… but an NFC smartphone is just a critical part of the vivokey ecosystem.
Yes, but the only reasonably secure URI is on the Spark 2 with the SUN suffix containing the CMAC signature… the Spark 1 has no such protections, and on the Apex there will likely be no such signature since the customer will be able to deploy the VivoKey NDEF applet and write whatever they want.
but to be honest i now kinda forget the goal? is this still regarding the desktop client or something else?
I didn’t really have a specific goal in mind. Just the idea that you could scan and implant and get a user ID or something back if it was a valid VivoKey implant, to use with projects where the thing attached to the reader want’s to get the users identity.
My only plan so far was if we have that Meetup I was going to make a candy or drink despencer that works once per VivoKey user. Basically just a VivoKey verified UID.
Definitely can’t think of a high priority reason for it.
gotcha ok… makes sense… perhaps we could explore something that wouldn’t necessarily give away any additional information but instead simply confirm the chip was a valid VivoKey device… let me think on it.
) just seems unnecessary and would limit use cases like “Fuck broke my phone, need to login here”