[Feature Request] Client-side pass generation

[RiverRuby]

I would like to generate the pass on the client-side, and just have the server sign the manifest. This is so we can have private information in the pass that the server does not see (specifically, a unique cryptographic signature from an NFC card that should remain private to the user).

I tried removing the parts of PKPass that use Node.js things like fs in a personal fork (https://github.com/vb7401/passkit-generator), and just use the Buffer model for reading everything. However, when I try to import that fork I get an error saying that Module not found: Can't resolve 'passkit-generator'.

Do you have any tips here?

[alexandercerutti]

Hi @vb7401, first of all thank you for using passkit-generator!

This library is not studied at all to run on the client (e.g. browsers, except Cloudflare Workers, which have a browser-like api.). It uses Buffers, but it is a Node.JS class only. We should convert to using Uint8Array (which is extended by Buffers) I guess, and verify this all the dependency work as well (I'm not so sure about node-forge).

About signing the pass on the server, what's your idea about an architecture that would involve such elements? Should file's SHA-1 be calculated on the client or the server (which are the content of manifest.json)?

Also, splitting things is not that easy currently. It would probably require a whole package rewriting.

You can see by yourself that is not a very easy thing to be accomplished, especially in short times, so I think a lot of things should be evalutated.

Is there a particular reason for which you cannot setup a firebase cloud function or a serverless lambda or a cloudflare worker and use passkit-generator there?
Thank would help you to hide secrets with their native systems.

Let me know.

[RiverRuby]

Thank you for the quick reply! And thank you for such a fantastic job on passkit-generator, amazing library for what feels like an underutilized technology in Apple Wallet!

This all makes sense to me. The goal of the experience is to collect private signatures from NFC cards, and then not expose these signatures to the server at all. So yes, the SHA-1 hashes for manifest.json would be computed on the client-side, and then signed on the server. This way, the server doesn't learn anything of the user's private signatures, but also doesn't need to expose the .pem files necessary for signing and creating the .pkpass file.

For the short-term, I will stick to doing this as a serverless function and not store any of the data that is sent, just use it to sign the data properly and send it back to the user to store. But if we were to do this client-side, why is not just factoring out the code that does signing and doing the rest in-browser?

[alexandercerutti]

I might still be missing something to understand the whole picture.

What are the "private signatures from NFC cards" you are talking about? And how would you collect them and make them interop with Passes?

Something like providing support to generate an NFC-compatible pass for a third party, which should provide you their NFC encryptionPublicKey?