A verifiable credential is signed by whoever issued it and carried by whoever it describes. The organisation accepting it checks a signature — it does not call the issuer to ask about you. Monokee issues and verifies them on open standards, as steps in the same journeys that already run your federation.
The difference is not philosophical. It is about whether somebody has to stand in the middle — and therefore who has to be online, who sees what, and who is holding the thing being checked.
An identity provider stands between the person and the application and answers on their behalf, at every access. It works — and it makes that provider a permanent intermediary: it has to be reachable for the service to function at all, and every relationship passing through it is visible to it.
The credential was signed when it was issued. The verifier resolves the issuer's public key and checks the signature against it. The issuer is not contacted, learns nothing about the transaction, and does not have to be online for it to succeed.
Between issuance and presentation the credential lives in a wallet its subject controls. They decide what to present and to whom. That is the part regulators find interesting and the part that makes some existing business models uncomfortable.
Deliberately no registry, no ledger and no vendor in this list. Which one a deployment sits on is an operational decision that should not reach the applications — and if it does, the architecture has already failed.
An identifier that resolves to a document instead of pointing at an account inside somebody else's directory. It is what lets a verifier find the key it needs without first having a relationship with the issuer, and what lets an issuer be identified consistently wherever its credentials turn up.
What a DID actually resolves to: the public keys used to check a signature, and the service endpoints used to open a channel. The document is the interface — which is why the method that produced it, and the registry behind it, can change without anything downstream noticing.
How a credential gets from an issuer into a wallet, carried over the same OAuth-shaped exchange your systems already speak. It is the reason issuance no longer needs a bespoke integration per wallet, and the reason an issuance step can sit in a journey next to an authentication step.
How a verifier asks for a credential and how the wallet answers — including asking for the two attributes actually needed rather than the whole document. The request is explicit, the person sees what is being asked, and the answer is a signed presentation rather than a lookup.
Issuance and presentation are separate events, often months apart, and the second one does not need the first one's participants to be present.
Verifiable credentials solve problems federation was never shaped for. They do not solve the ones it already handles, and pretending otherwise is how pilots end up as pilots.
Somebody already verified elsewhere — by a bank, by a public administration, by another company in the group — presents the attestation instead of repeating a document check that has already been paid for once.
A qualification, a certification, a membership, a role held at a company that is not yours. Federation was never good at these, because there is no shared directory to federate with and no appetite to build one.
eIDAS 2.0 and the European Digital Identity Wallet turn this from an architectural preference into something with a date attached. Being able to accept a credential stops being a differentiator and starts being a requirement.
Most access in most organisations still runs on OpenID Connect and SAML, and will for years. The value is in adding a credential where it removes a step or a re-check — not in replacing a federation that is working.
Monokee sits on both ends. The wallet is the one role it deliberately does not take: that belongs to the person, and an issuer that also holds the credential has quietly rebuilt the thing it was replacing.
Attributes the organisation already holds — an employment relationship, a qualification, a verified document — become a signed credential the person can carry away and present elsewhere. Issuance is a step in a journey: it happens after whatever proof the policy requires, not in a separate console.
A journey can ask for a credential the way it asks for a second factor: at the point where it changes the decision. The request states which attributes are needed, the wallet answers with a signed presentation, and the flow continues — or does not.
We'll look at whether a credential removes it, and what it would take to issue one.
Ask for a demo