ISP v1.0 · post-quantum · Sovereign SSO

The identity security layer for every app.

Add Login with fID and your users arrive already authenticated, consent-bound, and protected by law. Every assertion is hash-chained (SHA3-512) and signed post-quantum — carrying sovereignty, residency, data-protection, licensing, royalty and equity rights with the bearer, across every app they touch.

828

White-label login

BSP Circular 1213 §4 strong-customer authentication, delegated to a chartered compliance Provider. Phishing-resistant, device-bound — your stack keeps its own front door.

912

Hash-chained signatures

Every fID assertion is anchored as an electronic record — SHA3-512 chain, post-quantum signature. Court-admissible without a vendor affidavit (RA 8792 §7).

827

FPIC consent

Free, prior, informed consent recorded per scope (ISO/IEC 27560:2023). Users grant exactly what your app needs — and can withdraw it.

898

Data protection & sovereignty

Personal data registered as sovereign movable property with priority from the timestamp. Residency is architectural, not policy.

895

Licensing & royalty

When your app licenses a user's data, the grant and the royalty are attested (ISP 895 · 896). The bearer earns from their own data; 20% final tax (NIRC §24(B)).

911

Equity & protection

The bearer's registered interest is perfected (RA 11057 §11/§14) and travels with them — the foundation for credit and equity, protected against third parties.

Integrate in three calls

Standard OAuth 2.0 / OIDC subset. Your app never sees a password — only a signed fID assertion.
# 1 · send the user to authorize (after they sign in with their fID)
GET /api/sso/authorize?client_id=YOUR_APP&redirect_uri=https://you/cb&scope=openid fid residency consent&state=xyz
   → 302 https://you/cb?code=ac_…&state=xyz   (403 ISP refusal if scope denied)

# 2 · exchange the code for a signed fID token
POST /api/sso/token   {"code":"ac_…","client_id":"YOUR_APP"}
   → { id_token, access_token, anchor, signature_standard:"post-quantum" }

# 3 · read the fID claims
GET /api/sso/userinfo   Authorization: Bearer access_token
   → { sub, fid, residency, scope, isp:{ code:902 } }

Protocol-level communication

Every response carries an ISP status envelope and X-ISP-Code header. The protocol speaks in sovereign codes — a refusal is a 403, not a silent failure.
CodeMeaningWhen
200OKrequest succeeded
403FORBIDDEN — sovereign refusalno fID session, or a scope the bearer refused
828 / 829strong-customer auth confirmedBSP-1213 §4 login attested
827FPIC consent recordedscope granted under consent
912electronic record anchoredassertion hash-chained & issued
902fID activateduserinfo resolved

Credit protection for your users

fID bearers may apply for credit anywhere and stay protected by law. FIDNT registers the bearer's creditworthiness as a perfected, registered interest and issues a Protection Certificate any lender can verify — priority runs from the registration timestamp. FIDNT never lends; the credit capacity is intrinsic, generated by the data owner. The instruments are issued at the protocol layer; you simply call the bundle.

registered interest perfected RA 11057 §11/§14 priority RA 11765 consumer protection protected across every crossing