[BUG] Passkey format seems not interoperable with desktop application (passless)

[trap000d]

Describe the bug

I'm giving a try to passkey feature introduced in Android-Password-Store 2.0.
There is a site which allows to test passkeys https://webauthn.io/

Mobile device: Android 16, Firefox, APS 2.0
Desktop: Arch Linux, passless (AUR)

Seems passkeys generated by desktop utility passless are incompatible with ones created by Android-Password-Store.

Steps to reproduce

Steps to reproduce the behavior:

1. Install and configure passless on desktop
2. Start desktop browser
3. Navigate to https://webauthn.io/
4. Pick some user name, then generate passkey.
5. Synchronise password-store repo with mobile device
6. Open browser on mobile device, navigate to the same site
7. Try to authenticate with credentials above
8. See error: Failed to parse /fido2/webauth.io/[some long id] The file does not appear to contain valid passkey data
9. Repeat it in reverse order: create credentials on mobile, then try to authenticate on desktop
10. See error: "The request is not allowed by the user agent or the platform in the current context, possibly because the user denied permission"

Expected behavior

I assume the same passkey, once exported, should be accepted on any device with properly configured pass/passless, and/or APS

Screenshots

No response

Device information

• Device: Android phone
• OS: Android 16
• App version: 2.0

Additional context

I've dumped both keys created on desktop and Android. They look absolutely different:

trap000d@zinc:~$ pass fido2/webauthn.io/b0ba420ee0e2c2a30fdcea508ffb7623ba1c0681c85ca99e380043279097818c
�bid� �����B�������������P�����v�#���������\�����8�C�'��������brp�bidkwebauthn.iodname�duser�bid��w�e�b�a�u�t�h�n�i�o�-�t�r�a�p�0�0�0�ednamehtrap000eldisplay_name�jsign_countcalg'kprivate_key� �X�m����C�~�?�����������2�x������@���|�Z�f���"�:���5���~�_gcreated�jiu
ldiscoverable�jex

trap000d@zinc:~$ pass fido2/webauthn.io/2abc2d69acda9b65a10e1d29cb7f1625042ed34bb0f7b0e555835572a9cb1b0c
qGJpZJggGCoYvBgtGGkYrBjaGJsYZRihDhgdGCkYyxh_FhglBBguGNMYSxiwGPcYsBjlGFUYgxhVGHIYqRjLGBsMYnJwomJpZGt3ZWJhdXRobi5pb2RuYW1la3dlYmF1dGhuLmlvZHVzZXKkYmlkkxh3GGUYYhhhGHUYdBhoGG4YaRhvGC0YdBhyGGEYcBgwGDAYMBhmZG5hbWVodHJhcDAwMGZsZGlzcGxheV9uYW1laHRyYXAwMDBma3JldmVhbF9uYW1l9WpzaWduX2NvdW50AGNhbGcna3ByaXZhdGVfa2V5mCAYWhh4AxhOGPQYehhOGIEYHxgvGNEYPBjzGO0YTxgyGPEYxxioGHIYuhh_GE4YhRh7GC8YxBicBBirGFMYNWdjcmVhdGVkGmppeNhkem9uZXBQYWNpZmljL0F1Y2tsYW5k

I've also have given a try to https://github.com/pando85/Android-Password-Store fork, however this one has UI bugs so I couldn't even generate credentials at all. I assume it should be another issue.

P.S. Or you might consider to synchronise code bases?

[agrahn]

pando85/passless breaks with design principles set by the original pass commandline client:

1. Password files are simple, line-structured, text files secured by PGP encryption: the first line bears the password, and optional content, e.g. TOTP data, key: value data, freeform text, may follow.
   Now, passkeys are binary; they are a CBOR-encoded combination of private key, user- and relying party-related metadata. Passless writes these data directly to a binary file, defeating the possibility to add optional, user-provided content. To keep compatibility with Unix Pass, agrahn/Android-Password-Store first Base64URL-encodes the passkey data before writing it as a line of text to the Pass file. Details on passkey encoding and storage are given here. It should be easy for passless to migrate their passkey data to this format.

2. In Unix Pass, the root directory and any subdirectory within the storage directory tree can be initialised individually with its own (set of) PGP key(s). By selecting the right subdirectory in the tree, the user decides which recipient PGP IDs a password is to be encrypted to.
   Passless treats passkey files differently from password files. It stores all passkeys in the hard-coded fido2 directory below root. Therefore, Passless and its generated credential storage cannot be used in a multi-user environment which Unix Pass was originally designed for. In agrahn/Android-Password-Store, on the other hand, the user can freely choose the location of passkey storage during passkey creation. The suggested path can be modified/extended via the "Directory" field on the "New passkey" form. This way, it is possible to store passkeys next to a traditional password for a given Web site. As usual, the passkey's storage path can also be modified retroactively, at any time, in an edit session in the app GUI.

I've also have given a try to https://github.com/pando85/Android-Password-Store fork, however this one has UI bugs so I couldn't even generate credentials at all. I assume it should be another issue.

P.S. Or you might consider to synchronise code bases?

New releases (also on F-Droid) of https://github.com/pando85/Android-Password-Store appear in rapid succession without being thoroughly tested beforehand. I reviewed the code recently, it turns out to be non-functional, insecure AI-slop, maybe intended to promote Passless. So no, therefore and for the reasons listed above this cannot be merged here.

[trap000d]

@agrahn, thanks for detailed explanation. I had a look on that PR #960 and the discussion, and fully agree with your opinion. AI generated "product" does not look good to me too for reasons such as no ability to verify and maintaining the code (as well as ethical concerns).

I'm staying with your version of APS. Synchronisation of passkeys between devices is not a "must have feature" to me.