DiligenceID Developers
GitHub

Sign in

The Developer Portal is the first application to authenticate people through DiligenceID rather than through a password and a profile. There is nothing to register for: you prove one thing about yourself, and the portal makes an account out of the answer.

What actually happens

The portal names a verification policy — developer-portal-login — and DiligenceID does the rest. The portal does not construct the request, choose which claims to ask for, or name a credential; all of that is fixed in the policy, which is why an application cannot quietly ask for more than it was approved for.

Developer Portal            "run developer-portal-login"
        ↓
DiligenceID                 builds the request from the policy's frozen snapshot
        ↓
Your wallet                 shows you what is being asked, and waits
        ↓
You approve                 the wallet discloses only the claim that was asked for
        ↓
DiligenceID                 checks the issuer, signature, holder binding, expiry and status
        ↓
Developer Portal            receives the policy's assertions, and a subject
        ↓
Developer Portal session

What the portal is told

Exactly this:

{
  "result": "verified",
  "assertions": { "membership_status": "active" },
  "subject": "<opaque, specific to this portal>"
}

Your credential does not pass through the portal. Neither do the claims you did not disclose — the policy asks for membership_status and nothing else, so member_since, region and display_name stay in your wallet and are never sent.

The subject is specific to this portal

The identifier the portal knows you by is derived from you and from this portal together. Present the same credential to a different application and it receives a different identifier, so two applications comparing notes cannot tell they are looking at the same person.

It is not your email, not a username, and not any identifier DiligenceID uses internally.

What the portal stores

Four fields, and no more:

Field Why it exists
applicationSubject Recognises you when you come back
createdAtUtc When the account was made
lastLoginAtUtc When it was last used
accountStatus Whether it is active

membership_status is not stored. It was true at the moment you signed in, and the portal has no basis to assert it tomorrow — if a page needs to know, it asks again.

If sign-in does not complete

What happened What you will see
No credential that satisfies the policy That credential does not confirm an active Diligence membership
The credential has expired This credential has expired
The credential was revoked This credential can no longer be used
You declined in your wallet You return here, not signed in, and no account is created
The request timed out Start again when you are ready

Nothing partial is kept. A sign-in that does not complete leaves no account and no session behind.

Signing out

Signing out ends the portal's session. It does nothing to your credential, which is yours and stays in your wallet.

Edit this page on GitHub