Mobile-ID / Certificates & scope
RAR/C06 · eID / SSO / ShareInfoISO/IEC 24745:2022
English
Tiếng ViệtEnglish
Design a PoC
From verified source identity

Your palm.
Your trusted
identity.

Contactless verification starts with the right person. Bring source identity, devices, palm biometrics and evidence into one coherent workflow.

Explore source identityTrusted Palm Device →
RAR/C06: eID / SSO / ShareInfo - integration confirmed by Mobile-ID.

One solution. Four defined components.

From the capture endpoint to the application relying on the decision.

01Trusted Palm DeviceCapture & endpoint context02Trusted Palm ID CoreEnrollment, matching & lifecycle03Integration layerRAR/C06, HIS, SIS, HRM & ACS04Trust governancePolicy, data & evidence

Recognize the palm.
Bind the right person.

eID, SSO and ShareInfo are deployment-specific channels, not three mandatory sequential calls.

SSO

Authenticated session result

Receive the SSO result and bind the subject, application and session under the agreed protocol.

Review channel scope →
ShareInfo

Authorized information sharing

Receive authorized attributes for the stated purpose; retain only what is needed for binding.

Review channel scope →
A valid source identity is not enough.

The verified identity holder must be the same person presenting the palm.

Review same-person controls →

Five services. Five clear questions.

Identity results and authorization decisions remain separate.

Authorize

Evaluate identity, role, entitlement, device and risk to make an authorization decision.

Check role and operator certification before granting machine access.
Explore this capability →

From proofing to controlled binding.

  1. 01Purpose
  2. 02Source identity
  3. 03Same participant
  4. 04Capture
  5. 05Binding
  6. 06Evidence

Real interfaces. Clear context.

Reference journeys from Trusted PalmPay; screenshots are not palm evaluation evidence.

Reference implementation - Trusted PalmPay
Identity proofing
Identity proofingSelect to enlarge ↗
Identity proofing →UI reference, not proof of biometric performance.

Trusted Palm Device.
Your endpoint in the trust chain.

Hardware, firmware, the engine and the service have distinct responsibilities.

TRUSTED PALM DEVICEFunctional schematic - not a commercial model
RGBPalm Print
IR / NIRPalm Vein
↓
Capture & session control
↓
Device identity & protected channel
↓
Trusted Palm ID CoreProfile, policy & evidence

Sensors, PAD and processing placement depend on the model, firmware and engine.

A component of the customer offering

Capture at the service point.
Trust under a deployment profile.

Trusted Palm Device participates alongside the Core, integration and governance layers. Creator/GRGBanking, Mobile-ID and customer roles are defined by delivery records.

Touchpoints
Counters, kiosks, gates and care points
Profile to select
Model / firmware / SDK / engine
Boundary
Processing by configuration; no universal feature claims
Architecture & boundariesCompatibility profileDelivery scope

Protect the reference.
Do not combine every record in one vault.

Mobile-ID confirms its data-organization model follows ISO/IEC 24745:2022.

Within the customer environment

Biometric vault

biometricRef

Reference protected under the profile.

↔bindingRefControlled binding

Business identity store

subjectRef

HIS / SIS / HRM / eGov

Tenant + purpose scoped. No cross-customer sharing by default.
Capture image
No default retention; exceptions need approval
Evidence
Minimal references, no image or palm payload
Lifecycle
Retain, revoke, re-enroll, delete
Explore the data model →

The right patient.
At each care touchpoint.

Contactless verification does not replace clinical protocols. When palm cannot be used, continue through an appropriate alternative.

Solution scenario

First enrollment

Bind a palm reference to the correct patient record.

  1. 01Verify source record
  2. 02Notice & processing basis
  3. 03Capture
  4. 04Quality checks
  5. 05Duplicate review
  6. 06Bind reference
Actors
Patient; registration officer
Authoritative source
HIS Patient Master / VNeID / CCCD
Service
Verify 1:1
Evidence
Source record; enrollment session; processing basis; reviewer; device.
Read the full scenario →

One identity core. Many application contexts.

Solution scenarios, not a list of customer deployments.

HealthcareEducation & campusGovernment servicesWorkforce & industryBuildings & hospitalityTransit & travel entitlementLogistics & handoverBanking identityMembership & retailHuman authorizationTrusted PalmPay
Explore the application library →

Representative deployment models

These are not completed customer deployments. They are ready-made models that can be replaced by verified case studies once evidence and publication permission are available.

CARE-01Illustrative model

Patient identity at the point of care

A model for first enrollment, returning-patient identification and verification before care tasks that require the right person.

Source identity proofingControlled palm enrollmentIdentify or verifyCheck HIS/LIS contextDecision and evidence
HISLISPACS
Explore related scenario →
CAMPUS-01Illustrative model

Student and candidate verification

A model for student binding, exam verification and context-aware access to learning facilities.

Student identityPalm enrollmentExam or service sessionVerificationAllow or review
SISLMS
Explore related scenario →
WORKFORCE-01Illustrative model

Workforce, shift and operating authorization

A model combining personnel verification with shift, zone and business conditions before authorizing an action.

Workforce identityPalmShift and zonePolicyAuthorization and evidence
HRMIAMACS
Explore related scenario →
GOV-01Illustrative model

Re-identification at a public-service point

A model that binds palm biometrics to a previously proofed identity and re-identifies the user within an authorized service.

Source identityPalm bindingService pointRe-identificationCase handling
eGovRAR/C06
Explore related scenario →
ACCESS-01Illustrative model

Person- and context-aware access

A model combining palm verification with role, zone and time before the access-control system enforces a decision.

PalmIdentityRoleZone and timeAllow or deny
ACSIAM
Explore related scenario →
LOGISTICS-01Illustrative model

Courier verification and handover evidence

A model that verifies the right sender or recipient against shipment, location and time before recording handover.

Sender/recipientPalmShipmentVerificationHandover and evidence
WMSTMS
Explore related scenario →

Trust starts with sourced records.

Organizational, PAD and eID certificates have distinct scopes; none is automatically extended to the entire Palm ID service.

Integrate by role.
Accept with evidence.

01Device / SDK vendorModel, capture session, payload and firmware.02Business-system vendorHIS, SIS, HRM, ACS: receive decisions and enforce rights.03Identity & security teamSource proofing, binding, purpose and evidence.
Simulate the API contractPolicies & practicesPublic trust register
Answers

Frequently asked questions

Clear boundaries for a sound implementation.

How does Trusted Palm ID differ from PalmPay?

Palm ID is the shared identity, verification and policy layer. PalmPay is a payment application consuming identity decisions.

Does it replace citizen ID or VNeID?

No. The authoritative source establishes identity. Palm supports scoped re-identification and verification.

What is the difference between 1:N and 1:1?

1:N searches an authorized population. 1:1 checks a claimed identity. Both require evaluated thresholds and exception handling.

Can a Palm ID binding be revoked?

The design can revoke bindings, disable references and support re-enrollment. This does not mean a biological palm can be changed.

How is Mobile-ID ISO/IEC 27001 presented?

The website links the published ISMS certificate SIS351224I008. Its scope and printed dates are not treated as certification of every Palm ID component.

Does this website perform live palm verification?

No. The API Explorer uses synthetic local fixtures. It captures no images or templates and connects to no production service.

How long are palm images retained?

It depends on the approved deployment and policy. The target design avoids default raw-image retention and must account for logs, replicas and temporary buffers.

Can a biometric failure prevent care?

The workflow must not do that. It needs alternatives and staff assistance. Enrollment or matching must not delay emergency care.

Start with a controlled PoC.

Define purpose, devices, risks and acceptance criteria before scaling.

Design a PoC with Mobile-IDFor integration teams →

Search Trusted Palm ID

Selected interface