Skip to content
Integration

Connect user-held identity to your service

Your app presents the request. The user approves disclosure. Your service decides access.

The issuance, presentation, verifier and federation adapter described here are planned additions. The available iOS SDK supports evidence capture, storage, signing and continuity; your app owns its screens and workflow.

Planned identity exchange

The holder app, issuer and your service

These responsibilities describe the planned exchange package, issuer and verifier. They establish where each part runs and who controls it.

In the holder app
The holder app owns screens, consent and recovery. It supplies the stored proofing values for issuance. The exchange package adds protocol transport, holder-key signing and storage with erasure scoped to each instance.
At the issuer
The issuer verifies re-sent values against proofing bindings, signs the identity record and erases those values. It retains status and verification references. Issuer trust must be agreed with your service.
In your service
Deploy the verifier in your environment. It returns checked claims and their evidence. You own account linking, access rules and retention of received information. An optional OIDC or SAML 2.0 adapter connects verification to your existing sign-in system.
Planned protocol flow

Present from an app or browser

Planned flows for native apps, mobile browsers and desktop browsers. Follow the request, user approval and verified result across each boundary.

Blue: user custody · Amber: your application and service · Purple: Kenshiki software

Native app → holder app → your service

Planned native-app flow. The RP app starts the request. The holder app supplies the approved proof. Your backend binds the verified result to the initiating app request.

Your mobile app User’s phone Your service · relying party RP app Your application Holder app Kenshiki SDK inside Kenshiki verifier In your environment Access system Your existing policy Start identity requestfrom the RP app Create signed requestbound to this action Return holder-appinvocation request Open holder appwith the request SDK validates requestand recipient User reviews claimsand approves SDK signs and sendsencrypted presentation Verify claims, key proofand request binding Resume the originatingapp request Check app identityand request binding Consume verified resultonce, for this request Return checked claimsand evidence Apply access rulesand return result

Your mobile app · RP app

User’s phone · Holder app, Kenshiki SDK inside

Your service · relying party · Kenshiki verifier + Access system

  1. RP app → Access system

    Start identity request from the RP app

  2. Access system → Kenshiki verifier

    Create signed request bound to this action

  3. Kenshiki verifier → RP app

    Return holder-app invocation request

  4. RP app → Holder app

    Open holder app with the request

  5. Holder app

    SDK validates request and recipient

  6. Holder app

    User reviews claims and approves

  7. Holder app → Kenshiki verifier

    SDK signs and sends encrypted presentation

  8. Kenshiki verifier

    Verify claims, key proof and request binding

  9. RP app → Access system

    Resume the originating app request

  10. Access system

    Check app identity and request binding

  11. Access system → Kenshiki verifier

    Consume verified result once, for this request

  12. Kenshiki verifier → Access system

    Return checked claims and evidence

  13. Access system → RP app

    Apply access rules and return result

The RP app and holder app have separate roles, even on one phone. Kenshiki SDK operations stay inside the holder app; your backend owns completion and access.

Mobile browser → holder app → your service

Planned same-device redirect flow. The browser and holder app run on one phone; your service binds completion to the browser visit that started the request.

Your application User’s phone Your service · relying party Browser Your site Holder app Kenshiki SDK inside Kenshiki verifier In your environment Access system Your existing policy Open request linkvia universal link SDK validates requestand recipient User reviews claimsand approves SDK signs and sendsencrypted presentation Verify claims, key proofand request binding Return completion URLwith one-time code Open completion URLin browser Return completion codeto your service Check originatingbrowser visit Consume verified resultonce, for this visit Return checked claimsand evidence Link accountand decide access

Your application · Browser

User’s phone · Holder app, Kenshiki SDK inside

Your service · relying party · Kenshiki verifier + Access system

  1. Browser → Holder app

    Open request link via universal link

  2. Holder app

    SDK validates request and recipient

  3. Holder app

    User reviews claims and approves

  4. Holder app → Kenshiki verifier

    SDK signs and sends encrypted presentation

  5. Kenshiki verifier

    Verify claims, key proof and request binding

  6. Kenshiki verifier → Holder app

    Return completion URL with one-time code

  7. Holder app → Browser

    Open completion URL in browser

  8. Browser → Access system

    Return completion code to your service

  9. Access system

    Check originating browser visit

  10. Access system → Kenshiki verifier

    Consume verified result once, for this visit

  11. Kenshiki verifier → Access system

    Return checked claims and evidence

  12. Access system

    Link account and decide access

User approval stays in the holder app; the access decision stays with your service. Declining stops disclosure.

Desktop browser → user’s phone → your service

Planned cross-device flow. The request starts on the desktop. Approval and signing happen on the phone. Your service completes the original desktop request after checking the cross-device binding.

Your application User’s phone Your service · relying party Browser Your site Holder app Kenshiki SDK inside Kenshiki verifier In your environment Access system Your existing policy Start identity requeston the desktop Create signed requestbound to this visit Return requestfor phone handoff Transfer the requestto the holder app SDK validates requestand recipient User reviews claimsand approves SDK signs and sendsencrypted presentation Verify claims, key proofand request binding Complete the originaldesktop request Check cross-deviceand browser binding Consume verified resultonce, for this visit Return checked claimsand evidence Apply access rulesand return result

Your application · Browser

User’s phone · Holder app, Kenshiki SDK inside

Your service · relying party · Kenshiki verifier + Access system

  1. Browser → Access system

    Start identity request on the desktop

  2. Access system → Kenshiki verifier

    Create signed request bound to this visit

  3. Kenshiki verifier → Browser

    Return request for phone handoff

  4. Browser → Holder app

    Transfer the request to the holder app

  5. Holder app

    SDK validates request and recipient

  6. Holder app

    User reviews claims and approves

  7. Holder app → Kenshiki verifier

    SDK signs and sends encrypted presentation

  8. Kenshiki verifier

    Verify claims, key proof and request binding

  9. Browser → Access system

    Complete the original desktop request

  10. Access system

    Check cross-device and browser binding

  11. Access system → Kenshiki verifier

    Consume verified result once, for this visit

  12. Kenshiki verifier → Access system

    Return checked claims and evidence

  13. Access system → Browser

    Apply access rules and return result

The phone sends proof to your verifier. Access completes on the desktop that started the request. Cross-device binding must resist request forwarding; a request identifier alone is not sufficient.

Issue, hold, present, verify

01 · Issue from recorded evidence · Planned

The first-party holder app re-sends stored proofing values. The issuer compares keyed digests from proofing, binds the record to a holder key, signs and erases the values.

The planned issuance profile uses OpenID4VCI authorization code flow with PAR, PKCE and DPoP. The evidence identifies each recorded check, its source, outcome, policy mode and revision. Failed verification returns a typed error.

02 · Hold on the user’s device · Planned

The SDK keeps the signed record and holder-key reference in protected, instance-scoped storage. Private signing keys stay on the device. Key loss or invalidation requires re-issuance.

The host receives typed data to build its approval screen. It owns the wording and interaction; the SDK owns request validation and construction of the response.

03 · Request an approved disclosure · Planned

Your service requests specific claims. The holder app identifies the recipient and requested information, then asks the user to approve or decline. The response binds the disclosure to that request and recipient.

On the same iPhone, the browser opens the holder app through a universal link. The planned presentation profile uses OpenID4VP with an encrypted direct_post.jwt response to the verifier; completion returns to the original browser visit.

04 · Verify, then apply your access rules · Planned

The verifier checks issuer trust, signatures, holder-key proof, requested claims, recipient, freshness, status and replay protection. Your service binds completion to the app request or browser visit that initiated it.

Verified claims do not automatically identify an existing account. Your service defines account linking and access. Shared information may contain personal data; withdrawing permission cannot retract a disclosure already received.

Your service receives verified claims, the recorded check evidence and the time status was checked. It applies its own access rules to that result.

Choose your next integration step

Evaluate capture and evidence in an example app, or review the disclosure boundary before defining the claims your service needs.

Evaluate iOS capture →Review custody and disclosure →