Parallel subject [Offtopic]

[HGBits]

Hi pando, so I want to address something that indirectly has to do with passless, I would like if possible your help to build a passkey manager around my own npass password manager project, it is a reimplementation for the pass that already integrates several features.

Because the architecture is different everything needs to be rethought and there are some features that I still want to implement in the future as support for pin and password as a diceware, finally future intentions.

you can take a look here to learn more: https://github.com/HGBits/npass-store

if you decide to contribute to this, I can adjust things here to try to facilitate understanding and construction.

[HGBits]

one detail worth mentioning is that I'm starting to build an android version of this my project, nothing I can publish yet...

[pando85]

Thanks for reaching out. I had a look through npass and I think I understand the direction you're taking with identities, the encrypted logical map and opaque blob names.

There are some interesting ideas there, but I don't think it makes sense for me to take on building a Passless integration around it at this stage.

Passless currently relies quite heavily on the standard "pass"-compatible storage model. In particular, the RP/credential directory structure lets us discover and index passkeys without decrypting them, and the encrypted CBOR credential format is shared with Password Store on Android. That interoperability is one of the main reasons for using "pass" as the software backend.

npass has a substantially different storage architecture, especially the encrypted map + opaque blobs. Supporting it would therefore be more than adapting a few commands: we would effectively be introducing and maintaining another storage format, including its discovery/indexing semantics, synchronization behaviour and eventually a separate compatible implementation on Android.

There is also a practical issue with passkeys being binary CBOR data, while the current npass interfaces are primarily designed around shell/string data. That would need a well-defined binary-safe interface or encoding before the two projects could interoperate cleanly.

So for now I'd prefer not to add this scope to Passless.

If you want to experiment with it yourself, the storage backend boundary in Passless would be the natural place to prototype an npass backend without changing the existing pass backend. If at some point there is a working implementation, the Android side exists as well, and there is a clear benefit over the current pass-based approach, we can take another look at it.