Darn iPhone.
I just get “PCD Response Error” after “Gathering NDEF size”
Spark 2, I am scanning correctly. (Able to get it to pop up the web link outside the app), giving it adequate time, have restarted.
Hoping the other iPhone user will report it working or not.
iPhone user here, and Spark Actions for iOS developer too. ^ ^
The chip requires to keep the connection alive to complete the authentication process.
The chip generates a challenge for the server, and then the app needs to send that to the server and wait for the server’s response to send back to the chip for the final authentication data. If the chip has communication broken by moving the chip after it started the process it will show that error.
Can you confirm the app version you have? On the main screen press the ? mark on the top right please.
1 Like
Spark Actions 1.0.16
Have been keeping it steady for a negotiation.
Now it’s saying “Empty PCD response data” (on iOS)
While getting the TagInfo on the 'droid I downloaded the Spark Actions app and it seems happy to read the Spark 2. Haven’t tried to write with it yet in case you’d like troubleshooting steps for the iOS app.
TagInfo
** TagInfo Scan (version 4.28.0) 28-Jan-24 20:10:46 **
Report Type: – IC INFO ------------------------------
IC Manufacturer:
Probably Genuine - AES OC couldn’t be performed
NOTE: To perform AES Originality check, enable the option “Originality Check” from settings if not done, and make sure internet connection is active.
IC Type:
NTAG 413 DNA
NFC Forum NDEF-compliant tag:
Type 4 Tag
– NDEF ------------------------------
NFC data set information:
NDEF message containing 1 record
Current message size: 92 bytes
Maximum message size: 126 bytes
NFC data set access: Read & Write
Record #1: URI record:
Type Name Format: NFC Forum well-known type
Short Record
type: “U”
protocol field: https://
URI field: Spark Actions - VivoKey Technologies
Payload length: 88 bytes
Payload data:
[00] 04 76 69 76 6F 6B 65 79 2E 63 6F 2F 31 31 37 37 |.vivokey.co/1177|
[10] 39 63 36 33 32 35 38 63 37 31 66 63 39 35 65 38 |9c63258c71fc95e8|
[20] 64 31 63 61 31 32 34 38 37 35 63 39 2F 3F 73 75 |d1ca124875c9/?su|
[30] 6E 3D 30 34 31 32 33 30 32 32 32 46 35 43 38 30 |n=041230222F5C80|
[40] 2D 30 30 30 32 31 44 2D 45 36 46 35 35 36 45 43 |-00021D-E6F556EC|
[50] 32 30 31 43 36 43 33 41 |201C6C3A |
NDEF message:
[00] D1 01 58 55 04 76 69 76 6F 6B 65 79 2E 63 6F 2F |…XU.vivokey.co/|
[10] 31 31 37 37 39 63 36 33 32 35 38 63 37 31 66 63 |11779c63258c71fc|
[20] 39 35 65 38 64 31 63 61 31 32 34 38 37 35 63 39 |95e8d1ca124875c9|
[30] 2F 3F 73 75 6E 3D 30 34 31 32 33 30 32 32 32 46 |/?sun=041230222F|
[40] 35 43 38 30 2D 30 30 30 32 31 44 2D 45 36 46 35 |5C80-00021D-E6F5|
[50] 35 36 45 43 32 30 31 43 36 43 33 41 |56EC201C6C3A |
Capability Container (CC) file content:
Mapping version 2.0
CC length: 15 bytes
Maximum Le value: 256 bytes
Maximum Lc value: 255 bytes
NDEF File Control TLV:
- Length: 6 bytes
- NDEF file ID: 0xE104
- Maximum NDEF data size: 128 bytes
- NDEF access: Read & Write
[00] 00 0F 20 01 00 00 FF 04 06 E1 04 00 80 00 00 00 |… …|
[10] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |…|
Type 4 Tag File Control Information (FCI):
Type 4 Tag v2 application FCI: [none]
CC file FCI: [none]
NDEF file FCI: [none]
NDEF file contents:
[00] 00 5C D1 01 58 55 04 76 69 76 6F 6B 65 79 2E 63 |...XU.vivokey.c|
[10] 6F 2F 31 31 37 37 39 63 36 33 32 35 38 63 37 31 |o/11779c63258c71|
[20] 66 63 39 35 65 38 64 31 63 61 31 32 34 38 37 35 |fc95e8d1ca124875|
[30] 63 39 2F 3F 73 75 6E 3D 30 34 31 32 33 30 32 32 |c9/?sun=04123022|
[40] 32 46 35 43 38 30 2D 30 30 30 32 31 45 2D 43 36 |2F5C80-00021E-C6|
[50] 41 39 39 35 31 37 39 32 42 31 36 38 38 33 00 00 |A9951792B16883…|
[60] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |…|
[70] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |…|
– EXTRA ------------------------------
Memory Information:
160 bytes total memory
- 128 bytes user memory
IC Information:
Capacitance: 70 pF
ISO-FID : ISO DF-Name:
E110 : D2760000850101
- Contains ISO FIDs: E103, E104
Version information:
Vendor ID: Probably Genuine - AES OC couldn’t be performed
Type: NTAG
Subtype: 70 pF
Major version: 0x10
Minor version: 0x00
Storage size: 128 bytes
Protocol: ISO/IEC 14443-4
Configuration Information:
Secure Dynamic Messaging: Enabled
UID Mirroring: Enabled
SDM Read Counter: Enabled
SDM Read Counter Value: 0
Originality Check (asymmetric):
Signature verified with NXP public key
TagInfo Version:
Version :4.28.0
Device Info:
Device Model :Google ( Pixel 3a XL )
Android OS Version :12
– FULL SCAN ------------------------------
Technologies Supported:
Fully compliant to the ISO/IEC 14443, all parts 1 to 4
Fully compliant to the ISO/IEC 7816-4 file selection
and APDU handling
Fully compliant passive target compliant to
ISO/IEC18092
Android Technology Information:
Tag description:
- TAG: Tech [android.nfc.tech.IsoDep, android.nfc.tech.NfcA, android.nfc.tech.Ndef]
- Maximum transceive length: 65279 bytes
- Default maximum transceive time-out: 618 ms
- Extended length APDUs supported
- Maximum transceive length: 253 bytes
- Default maximum transceive time-out: 618 ms
Detailed Protocol Information:
ID: 04:12:30:22:2F:5C:80
ATQA: 0x4403
SAK: 0x20
ATS: 0x067733810280
- Max. accepted frame size: 128 bytes (FSCI: 7)
- Supported receive rates:
- 106, 212, 424 kbit/s (DR: 1, 2, 4)
- Supported send rates:
- 106, 212, 424 kbit/s (DS: 1, 2, 4)
- Different send and receive rates supported
- SFGT: 604.1 us (SFGI: 1)
- FWT: 77.33 ms (FWI: 8)
- NAD not supported
- CID supported
- Historical bytes: 0x80 |.|
Memory Content:
PICC configuration:
- Unknown master key
- Key configuration:
- 1 mutable AES 128 bit master key
- 4 immutable AES 128 bit originality keys
Application configuration (DF 0xD2760000850101):
- Unknown AppMasterKey
- Key configuration:
- 3 mutable AES 128 bit AppKeys
Go ahead and delete that app, we should be in 1.3.19
App name is “Spark Actions”
Try again and let me know please.
1 Like
Actually app 1.4.20 is up for Apple Review, it just fixes some typos.
But you should be at least in 1.3.xx
1 Like
That worked perfect. Thanks for the help, haven’t seen iOS not present an update like this before.
Is probably my fault, we changed the app name from “Spark://” to “Spark Actions” so I guess Apple’s servers got freaked out. Hopefully it will not be annoying anymore. Also app updates work in mysterious ways lol. Since the app was just approved, it might not have pushed updates to all users yet.
Glad it worked! ^^ please let me know if there is any other buggies around.
1.4.20 will fix some typos around SupportNet and other messages. (Thanks to @Vicarious ) for letting me know right away.
3 Likes
Ok, so the data on the spark itself is locked and we’re relying on the vivokey server for what happens next. So we have to have an internet connection to do anything with it? Can the UID be used for access control?
Also, are all logins taking JWT the same or do they have to be vivokey API compatible?
I’m sorry my knowledge about API and webAuth is extremely limited, I’m much more into hardware 
Yes, you do have to have internet for the Authentication API to work.
Yes, you could use just the UID for identification. Although not very secure.
The Append JWT setting sends the “fresh” authentication token from VivoKey server to the url you select, it wouldn’t be necessary if the receiving server is not setup to verify the validity and expiration of the JWT token. But if it uses it, then the server can trust that the user accessing the server is reaching out from a fresh chip scan and not an old copy-pasted url.
For authentication, yes, we use the API with JWT on this app.
Here is more info about the Spark’s Auth API
1 Like
thanks for the confirmation 
That the way i meant, thanks for confirming this too
That’s where i get a bit confused … I get the principle and basic flow of how it works from the chip up to the Vivokey server.
Once the Vivokey server gets the JWT and send it to the target website (the site youre trying to log in)(is that the API endpoint?) how does it knows that the JWT is proper?
Does that site have to be compatible with Vivikey API or any JWT compatible target will work?
Thanks for all teh info and sharing, i hope my questions are not too basic
Thank you, this makes so much more sense now
The external auth will go to the vivokey server and it (vivokey server) will ask for a scan before sending the okey-dokey back to the service (whatever you’re trying to log in).
How are you/vivokey going to maintain the server and keep them up? Is it going to be funded throu the sale of implants or will there be a service fee?
So I can’t replace my fido key yet™ with the spark, but once the cloud service is up I won’t need to carry a key anymore
PS: I’m really curious because I have a Spark2 I got in a bundle I haven’t implanted yet, and I’m debating doing it or waiting until I break for the Apex and/or flex secure 
yes VivoKey Cloud and the associated mobile app will rely on the auth API to generate a JWT, which along with a pin code, will serve as an authentication factor for the VivoKey Cloud service. Then any external service relying on VivoKey Cloud for IdP services will accept the user authentication via SAML and eventually we will again support OpenID Connect.
VivoKey Cloud will be a subscription service. However, by subscribing you’ll also get access to various services we plan on deploying “behind” it.
Actually we released Spark for Apex so you can use the Apex for both Fido and VivoKey Cloud. A Spark could serve as a backup option for your VivoKey Cloud account.
1 Like
Makes sense for all the details and support
I know the Apex has the fido applet, I witch I think works just like a NFC fido key ? (you register it to the site and scan it when prompted instead of entering the password, if I understand it correctly). So the spark can be the backup of the Apex if the Apex get compromised/messed up during instal or need to be wiped clean but only for the Vivokey service?
And this is because the spark programming is locked?
So only use it there to limit exposure and possible getting it compromised?
The spark cannot backup the apex… think of it more like the auth API, which is at the center of all future VivoKey services, works with the spark. In order for you to use the apex with the auth API, You need the spark applet on apex.
With VivoKey Cloud, You will be able to associate multiple spark chips with your Cloud identity account. That means you can register your Apex and your Spark. In that way, your Apex and Spark back each other up as access tokens to your VivoKey Cloud account.
2 Likes
Got it
Thanks again for the info and support.
Is it in the works to offer an apex card?
Id love to “test drive” it before going in implant route (a good reason why i didnt do the spark yet)
It’s in the works but it’s going to be a while i think.