FIDO_DEV_GET_PUAT(3)

💖 FIDO_DEV_GET_PUAT 💖

okay so bestie, we're in fido_dev_get_puat(3) territory — that's the Library Functions Manual, section 3, and it's literally all about FIDO2 PIN/UV Auth token management. like, the four functions that handle your token era. no cap. 👑

---

✨ NAME ✨

fido_dev_get_puat, fido_dev_set_puat, fido_dev_puat_ptr, fido_dev_puat_len — the FIDO2 PIN/UV Auth token management functions. that's the whole squad. 🫶

---

🌸 SYNOPSIS 🌸

#include <fido.h>

int
fido_dev_get_puat(fido_dev_t *dev, unsigned int perm, const char *rpid,
    const char *pin);

int
fido_dev_set_puat(fido_dev_t *dev, const unsigned char *ptr,
    size_t len);

const unsigned char *
fido_dev_puat_ptr(const fido_dev_t *dev);

size_t
fido_dev_puat_len(const fido_dev_t *dev);

---

🦋 DESCRIPTION 🦋

okay so first up, fido_dev_get_puat() negotiates a FIDO2 PIN/UV Auth token with the permission bitmask you pass in perm, and then associates it with dev. matching them up fr fr. 💅

here's the tea on the args:

• if perm does not require you to specify a relying party ID, then rpid can be NULL. easy.
• but if it does need one, rpid has to point to a NUL-terminated UTF-8 string. non-negotiable.
• if a PIN isn't needed to authenticate against dev, then pin can be NULL.
• otherwise pin must point to a NUL-terminated UTF-8 string.

and the supported flags for perm are, in order:

• FIDO_PUAT_MAKECRED — permission for fido_dev_make_cred(). an rpid is required.
• FIDO_PUAT_GETASSERT — permission for fido_dev_get_assert(). an rpid is required.
• FIDO_PUAT_CREDMAN — permission for the credential management API. an rpid is optional.
• FIDO_PUAT_BIOENROLL — permission for the biometric enrollment API. the rpid is ignored.
• FIDO_PUAT_LARGEBLOB — permission for the large blobs API. the rpid is ignored.
• FIDO_PUAT_CONFIG — permission for the authenticator config API. the rpid is ignored.
• FIDO_PUAT_CREDMAN_RO — persistent read-only permission for the credential management API. the rpid is ignored.

fido_dev_set_puat() is your girl for associating a token you retrieved out-of-band with dev. and listen — no references to ptr are kept. like, none. it does not hold onto your pointer, bestie. 🙈

if ptr is NULL, or len is zero, the token gets cleared from dev. bye bye token. 👋

fido_dev_puat_ptr() returns a pointer to the PIN/UV Auth token currently associated with dev. and the matching length? you get that by calling fido_dev_puat_len(). they're a duo. 🎀

---

💜 why even associate a token tho

associating a token with dev has one main glow-up benefit: it reduces user interaction to a minimum in a sequence of operations where each one would otherwise demand some form of UV. iconic behaviour, honestly.

likewise — if multiple operations in a sequence need to be authenticated by a PIN, using a token avoids the need to cache the PIN for the duration of the whole sequence. so you're not out here storing your PIN the whole time. that's the vibe. ✨

---

⚠️ token precedence & validity (read this part pls)

once a token is associated with dev, it takes precedence over the regular PIN/UV Authentication for all operations that support the use of a token — until it's cleared from dev. periodt.

the validity of the token is determined by the authenticator. it may expire, and its permissions may be affected by its use. 😭

an invalid token is not automatically cleared from dev. so don't just assume it ghosted you — it's still there.

applications can call fido_dev_set_puat() or fido_dev_get_puat() to discard or obtain a new PIN/UV Auth token, and then retry the failed operation as appropriate. that's your recovery arc. 🌈

for further details on token semantics, please refer to the FIDO Client to Authenticator Protocol (CTAP) standard. iykyk. 📖

---

🔥 RETURN VALUES 🔥

• on success, fido_dev_get_puat() and fido_dev_set_puat() return FIDO_OK. slay. ✅
• on error, a different error code defined in <fido/err.h> is returned. check it, don't guess.

fido_dev_puat_ptr() may return NULL if there is no PIN/UV Auth token associated with dev. and if it's not NULL, the returned pointer is guaranteed to exist until either fido_dev_get_puat(), fido_dev_set_puat(), or fido_dev_free() is invoked. so like, don't go freeing stuff and then using that pointer. 💀

---

👑 SEE ALSO 👑

• fido_dev_new(3)

---

that's the whole page bestie, go forth and manage your tokens responsibly. 💖✨🎀🦋🌸💅🫶

this came to you from Debian, dated April 8, 2026, living under the name FIDO_DEV_GET_PUAT(3) — mwah, take care of her. 💜