GlobalContact
Menu

Identity engineering

Identity engineering from identifier to wallet.

UrbanID advises on the architecture and engineering of privacy-preserving identifiers, MobileID credentials and verification services. The work joins protocol detail to the institutions and operations that must support it.

Capabilities describe engineering and consultancy scope. They do not imply that every profile or service is deployed as an UrbanID product.

Engineering scope

Digital identity is a connected system: authoritative records establish claims; credential services package them; wallets protect holder keys and mediate presentation; verifiers make decisions against a defined trust framework. We help organisations design these boundaries and plan integrations that can be operated and assured.

  • Identity tokenisationScoped identifiers, token lifecycle, mediated resolution, protected mappings and sector-specific integration.
  • MobileID and wallet architectureCredential issuance, Android and iOS wallet behaviour, device binding, user consent, recovery and lifecycle.
  • Credential and verifier servicesIssuance and presentation profiles, verifier identity, trust decisions, status checks and relying-party integration.
  • Identity middlewareAPIs, event flows, civil-registration connectors, migration boundaries and service orchestration.
  • Privacy and security engineeringData flows, trust domains, key custody, purpose limitation, threat models and operational controls.
  • Interoperability and assuranceProfile selection, test vectors, negative cases, implementation review and cross-platform validation.
Identity tokenisation

Keep the foundational identifier out of routine circulation.

Identity tokenisation separates the identifier used to establish uniqueness from the identifiers used by individual sectors and services. A well-designed system scopes tokens to a purpose, limits who can resolve them, and records the authority and reason for each resolution. It reduces the ability to join records by a shared national number; it does not make personal attributes anonymous.

Consultancy can cover the token model, issuance and replacement lifecycle, mapping-register controls, cryptographic key management, consent and lawful-basis pathways, verifier identity, audit evidence and integration with existing identity systems. Design choices must reflect the legal mandate, service model and threat environment.

Identity tokenisation limits identifier exposureA protected identity authority sends an authorised request to a tokenisation service. The service issues a sector-scoped token to a sectoral record. A controlled mapping register and purpose, legal-basis and audit controls sit beneath the service.PROTECTED AUTHORITYIdentity registerroot ID and attributesToken servicemediated operationScoped identifiersector-specific tokenService recordminimum necessary dataControlled token mappingrandom reference · mediated lookup · logged authorityPurpose · legal basis · consent where required · audit
  1. Identity registerRoot identifier and verified attributes
  2. Token serviceMediated, authorised operation
  3. Scoped identifierToken specific to a sector or purpose
  4. Service recordMinimum necessary data
Controlled token mappingRandom reference, mediated lookup and logged authority
Decision controlsPurpose, legal basis, consent where required and audit
Identity tokenisation reference flow

The foundational identifier remains inside the protected authority boundary. A mediated service issues or resolves scoped tokens against a controlled mapping. Tokenisation reduces identifier linkage; it does not anonymise attributes or remove the need for legal authority, access controls and audit.

Sectoral identifiers should not become a second universal identifier. Their scope, rotation, recovery and resolution rules must be explicit, independently reviewable and tested against both authorised and abusive access paths.

MobileID and credentials

Mobile credentials need an ecosystem, not just an app.

MobileID programmes depend on agreement between issuers, wallet providers, relying parties, trust-list operators and support teams. The wallet experience must make the verifier and request understandable; the protocol must bind the response to the right session; and the verifier must validate signatures, certificate paths, credential status and policy against the correct trust source.

Mobile credential issuance and verification flowAn issuer creates a signed credential, a mobile wallet holds it and presents selected claims after user review, and a verifier checks the presentation against the applicable trust and status policies. Separate issuer-trust and verifier-authorisation inputs are shown beneath the flow.Issuerauthority signs credentialMobile walletkey and credentialPresentationpurpose and selected claimsVerifierchecks proof and policyTRUST AND LIFECYCLE INPUTSIssuer trust and credential statusissuer chain · validity · revocation policyVerifier identity and authorisationregistered source · permitted profile · purpose
  1. IssuerAuthorised body signs a credential
  2. Mobile walletHolds credential and protects keys
  3. PresentationUser reviews purpose and selected claims
  4. VerifierChecks proof, identity and policy
Issuer trust and statusIssuer chain, credential validity and revocation policy
Verifier trust and authorisationApproved identity, permitted profile and stated purpose
MobileID issuance and presentation

A MobileID service is an ecosystem: issuer authority, wallet and device controls, verifier identity, profile-specific presentation rules, and status or revocation services. Issuer trust and verifier authorisation are separate decisions; the scheme profile defines which apply.

UrbanID’s MobileID consultancy covers platform and wallet architecture, issuance and presentation services, device-bound keys, recovery, proximity and offline constraints, verifier infrastructure, trust distribution and operational readiness. Relevant profiles may include ISO/IEC 18013-5 and 18013-7, ICAO DTC and VDS-NC, OpenID4VCI and OpenID4VP, SD-JWT VC, EUDI wallet profiles and W3C Verifiable Credentials, according to the programme’s agreed scope.

Cross-platform acceptance should compare approved business logic and protocol behaviour across Android and iOS, including error handling, consent, localisation and negative security cases. A named protocol class or a successful build is not evidence of interoperability.

Review the standards and profiles
Engagements

From architecture review to implementation assurance.

Engagements can define a target architecture, assess an implementation, specify APIs and trust contracts, establish test and acceptance gates, or support an integration team through delivery. Findings are tied to evidence, accountable owners and tests that demonstrate closure.

See identity consulting services