Kinda, yes.
(slightly simplifying the mechanism here)
This seems to be based on the EU Wallet project, which is still work in progress. The EU wallet is based on OpenID (oidc4vci, oidc4vp). The wallet allows for selective disclosure of attributes. These attributes are signed by a issuing party (i.e. the government of a EU country). That way a RP (relying party) can verify that the data in the claim (e.g. this user is 18+) is valid.
However, this alone is not enough, because it could be a copy of that data. You can just query a wallet for that attribute, store it and replay it to some other website. This is obviously not wanted.
So the wallet also has a mechanism to bind the credential to a specific device. When issuing a credential the wallet provides a public key plus a proof of possession of the associated private key (e.g. a signature over an issuer-provided nonce) to the issuer. The issuer then includes that public key in the signed part of the credential. When the RP verifies the credential it also asks the wallet to sign part of the response using the private key associated with that public key. This is supposed to prove that the credential was sent by the device it was issued to.
Now this is where the draconian device requirements come in: the wallet is supposed to securely store the private key associated with the credential. For example in a Secure Enclave on the device. The big flaw here is that none of this binding stuff works if you can somehow get access to the private key, e.g. on a rooted phone if the wallet doesn't use a secure enclave or with a modified wallet app that doesn't use a secure enclave to store the private key. You could ask a friend who is 18+ to request the credential, copy it to your phone and use that to log in.
Uh, replay attacks are a solved problem in pretty much any industry standard challenge-response authentication, including OpenID. Am I missing something?
I wrote a bit about why in the readme (see archiving vs backup). In my opinion, syncing, snapshots, and backup tools like restic are great but fundamentally solve a different problem from what I want out of an archive tool like aegis, git-annex, or boar[2].
I want my backups to be automatic and transparent, for that restic is a great tool. But for my photos, my important documents and other immutable data, I want to manually accept or reject any change that happens to them, since I might not always notice when something changes. For example if I fat finger an rm, or a bug in a program overrides something and I don't notice.
[1]: https://git.sr.ht/~alexdavid/aegis
[2]: https://github.com/mekberg/boar