Pilot Overview
What is being tested, for whom, and how success is judged.
The pilot
Civitas ID and Tala are testing whether verified, consented credentials held in an applicant’s own wallet can open a segment Tala does not reach today. The pilot offers Tala three things: a pipeline of verified, consented applicants, assurance that each applicant is a real and unique identity, and features that add signal to thin-file underwriting. Each is judged separately.
| Value proposition | Pilot hypothesis | Required at launch |
|---|---|---|
| Lead generation | The referral pipeline delivers eligible applicants at an acceptable funnel conversion, from a segment Tala does not serve today | Yes |
| Identity assurance | Verified credentials reduce manual review, fraud losses, and duplicate or synthetic applications relative to Tala’s current onboarding | Yes |
| Credit risk | Etymos features add signal over Tala’s own thin-file benchmark, or give the same signal earlier or more cheaply | Post-launch |
The client
Tala, a regulated lender operating in Kenya. Tala retains full ownership of KYC, fraud, affordability and credit decisions throughout. Nothing in this flow decides, scores or approves on Tala’s behalf.
The problem
A thin-file applicant reaches Tala today with only the signals Tala can capture from its own app after install. Verified identity, refugee status, and any history that exists before the applicant arrives are all unavailable. Refugees are therefore assessed as new-to-credit, and are often screened out at the data-sufficiency stage of the funnel — before any credit judgement is made at all.
The solution
Referrals are sourced from the refugee community through Civitas’ ecosystem of trusted community-based and refugee-led organisations. The Civitas wallet takes the holder through the verification steps in section 2, storing the results as credentials they own. When ready, the holder consents to share that package with Tala, which runs its own onboarding and underwriting enhanced with the agreed Civitas feature set.
| Party | Role |
|---|---|
| Civitas ID | Creates and distributes the credential wallet, data orchestration and the Tala integration |
| Etymos | Transforms wallet and credential data into usable features |
| Tala | Defines eligibility, runs KYC, fraud, affordability and risk, originates and monitors any loans |
Deployment stays light. Tala’s integration with Civitas delivers access to the holder and more than five new data sources, while Tala continues using its own processes and models — and can evaluate Civitas features both against customer outcomes and against its own features.
Key metrics
Measurement depends on data Tala provides, before and during the pilot. Success is measured against Tala’s own benchmark, not asserted.
| Proposition | What Tala provides |
|---|---|
| Lead generation | Customer acquisition cost and lifetime value · funnel conversion and drop-off rationale by stage |
| Identity assurance | KYC pass and fail rates, manual-review rates and rejection categories · fraud and duplicate-application rates to compare against |
| Credit risk | Portfolio approval rates, bad rates and first-payment default rates · per-user outcomes: first-payment default and delinquency at 30, 60 and 90 days, plus final outcomes · insight into the features Tala uses in loan approval |
That last item is the one worth securing early. Knowing which features Tala already relies on, before launch, allows Etymos to engineer features proven to correlate with them — rather than discovering the overlap afterwards.
Sampling. Pilot volumes will support conclusions about verification quality, fraud-type detection and feature correlation against Tala’s own features. A statistically robust credit-uplift result requires larger volumes with outcomes, built toward over subsequent quarters.
Outstanding confirmations from Tala. Three answers are needed ahead of the technical integration meeting, and the first two can change this specification: whether Tala’s legal team accepts the Refugee ID as a KYC credential for CBK purposes, whether the proposed flow requires CBK approval or no-objection, and which minimum KYC and eligibility fields Tala requires. If the Refugee ID is not acceptable, the Document Type enum in section 4 stops being a launch decision and becomes a gating one.
The Journey
One sequence for the whole product, in business language. Steps 1–3 happen inside the app and issue nothing. Steps 4–9 are platform interactions, each with a card in section 3.
Scroll the diagram sideways to follow it across all five parties. Step 9 is the only step the holder may not finish in one sitting. Everything else completes immediately — which is why Tala must hold a Notification Id before step 9 can reach the holder at all.
Open points on the journey
Identity verification is a native SDK and profile entry is native, but email and mobile are still drawn as web view steps. It is the last inconsistency in how the app collects things, and it changes what has to be built and hosted: a web view step needs an HTTPS page and a postMessage contract, native entry needs neither.
Confirmed: this check needs building — the Civitas app does not do it today. Still open is what happens when it fails. Can the holder retry, is the submission blocked, and is anything recorded?
This gate is the only thing binding the credential package to the person presenting it, so its failure behaviour is a security decision rather than a UX one.
Interaction Cards
One card per platform interaction — this is where the technology lives. A field that does not apply reads “—”, never blank, so that decided: none is distinguishable from nobody considered it.
Step 4Verify Your Identity
| Service | Etymos |
| Mechanism | Plain interaction webhook · immediate — no manual review in the pilot |
| Initiation | Button |
| Processing policy | Sequenced |
| Requires | — |
| Required via | — |
| Web view steps | None — the Smile ID SDK runs natively in the Civitas app, capturing the document and the biometric liveness check |
| Issues | Verified ID Credential — exactly one platform limit |
| Attribute sources | All filled by the Etymos webhook from the Smile ID result. Service-attested throughout |
| Config (service) | Smile ID environment and API credentials · registry-match policy, held with Smile ID, positive-only |
| Config (interaction) | — |
| Success message | “Your identity is verified.” (placeholder — Q13) |
| Failure messages | we could not verify your document — you can try again · the selfie did not match your document · that document type is not supported yet (placeholders — Q13) |
| Deferred path | — no manual review. A failed check is a retry, not a waiting state |
| Open questions | Q03, Q04, Q05 |
The native SDK removes a platform trap. In-app camera capture does not work inside a WebView in the current wallet build — the file selector discards capture and accept, and the WebView permission handler never grants camera. A native SDK has native camera access, so that constraint is gone. It was the largest single risk to this step. It would return the moment any capture step moved into a web view.
A native SDK sits outside the platform’s own mechanisms, so its result reaches Etymos out of band. Etymos must know which subscriber and which interaction event a given Smile ID job belongs to. Options: the app passes the subscriberConnectDid into the SDK job reference, or Etymos correlates on a token minted when the interaction starts.
Whatever the answer, it must be tamper-resistant — anything that lets one holder’s SDK result attach to another holder’s event is an identity swap.
Fixed before the schema goes to the ledger, where it becomes immutable. Two decisions inside it: does the enum distinguish “document failed” from “liveness failed” — different customer messages and different fraud signals — and is the liveness attestation carried as its own attribute (drafted as Liveness Verified) or folded into Validation Result?
ISO 3166 alpha-3, or the wording printed on the document? For refugee documents these often differ, and Tala will match against one or the other.
Step 5Verify Your Email
| Service | Civitas Social Stamps |
| Mechanism | Plain interaction webhook + web view step · immediate — see Q01 |
| Initiation | Button |
| Processing policy | Sequenced |
| Requires | — |
| Required via | — |
| Web view steps | Email entry and one-time-code entry. Returns the address and the OTP result |
| Issues | Verified Email Credential — exactly one platform limit |
| Attribute sources | All filled by the webhook — service-attested, because the point of the credential is that Civitas Social Stamps vouches the address was reached |
| Config (service) | Email OTP provider credentials |
| Config (interaction) | — |
| Success message | “Your email address is verified.” (placeholder — Q13) |
| Failure messages | that code was not correct — we can send a new one · that code has expired (placeholders — Q13) |
| Deferred path | — |
| Open questions | Q01, Q11 |
Split from the source’s step 4, which issued email and mobile credentials in a single step. The platform issues exactly one credential per interaction — more is rejected with 409 credential <id> should not be issued in action <n>, and the dashboard picker is single-select. The source’s step 4 is therefore steps 5 and 6 here.
Step 6Verify Your Mobile
| Service | Civitas Social Stamps |
| Mechanism | Plain interaction webhook + web view step · immediate — see Q01 |
| Initiation | Button |
| Processing policy | Sequenced |
| Requires | — |
| Required via | — |
| Web view steps | Mobile entry and one-time-code entry. Returns the number and the OTP result |
| Issues | Verified Mobile Credential — exactly one platform limit |
| Attribute sources | All filled by the webhook, including the SIM and phone-intelligence lookup |
| Config (service) | SMS OTP provider credentials · SIM and phone-intelligence provider credentials |
| Config (interaction) | — |
| Success message | “Your mobile number is verified.” (placeholder — Q13) |
| Failure messages | that code was not correct — we can send a new one · we cannot send codes to that number (placeholders — Q13) |
| Deferred path | — |
| Open questions | Q01, Q06, Q11 |
Issuing this credential is what flips the profile’s phone number from self-attested to verified.
SIM Tenure needs a unit (months or days). SIM Swap Recency needs to state what it counts and what it holds when there has never been a swap. All three SIM attributes need a value meaning “the provider had no data” — distinct from a negative result, following the same positive-only principle the pilot applies to registry matches.
Step 7Build Your Etymos Feature Set
| Service | Etymos |
| Mechanism | Extension Etymos Feature Derivation · immediate |
| Initiation | Button |
| Processing policy | Sequenced |
| Requires | Verified ID Credential (all attributes) · Verified Email Credential (Email Address, Verification Timestamp) · Verified Mobile Credential (Phone Number, Verification Timestamp, SIM Ownership Match, SIM Tenure, SIM Swap Recency) |
| Required via | Extension credentialsRequired — not on the interaction as well (422 credential <id> is required by interaction and integration <id> if both) |
| Web view steps | — |
| Issues | Etymos Feature Set — exactly one platform limit |
| Attribute sources | All filled by the extension’s onReceivingCredentials reply |
| Config (service) | Feature policy — which features are derived and their confidence bands |
| Config (interaction) | — |
| Success message | “Your profile is ready to share with a lender.” (placeholder — Q13) |
| Failure messages | we need your verified ID before we can build your profile (placeholder — Q13) |
| Deferred path | — |
| Open questions | Q07, Q08, Q12 |
Build note. An extension needs three separate writes to go live: define it, install it on the service, attach it to the interaction. Missing any one produces silence, not an error. It also needs a default webhook key on the Etymos service, or every config read returns 500.
Held open as an explicit placeholder. Each feature needs a name, a type and a range before the schema goes to the ledger, where it is immutable — a feature added later means a new schema version, a new credential definition, and a re-issue to every holder. Worth over-declaring now rather than under-declaring.
Minting is agreed: Etymos mints the Pseudonymous Applicant Reference and carries it as an attribute here, so it travels into Tala’s hands with the presentation and can be echoed in outcome data. A DID cannot serve this purpose — a subscriberConnectDid is stable only for one customer-service pair, so the DID Etymos holds for an applicant is not the DID Tala holds for the same person.
Still open: if the Feature Set is rebuilt, does the reference survive? If it does not, a rebuilt profile becomes a new applicant and the credit measurement breaks.
Step 8Share Your Credentials with Tala
| Service | Tala |
| Mechanism | Extension Tala Onboarding · immediate — hands the assembled package to Tala’s KYC and origination systems |
| Initiation | Button |
| Processing policy | Sequenced |
| Requires | Verified ID Credential · Verified Email Credential · Verified Mobile Credential · Etymos Feature Set · Notification Id |
| Required via | Extension credentialsRequired — not on the interaction (422 if both) |
| Web view steps | — |
| Issues | — nothing. The handoff is confirmed by a notification |
| Attribute sources | — |
| Config (service) | Tala environment and API credentials |
| Config (interaction) | — |
| Success message | Notification: “Tala has your details, continue in the Tala app.” (placeholder — Q13) |
| Failure messages | Tala is not accepting applications right now (placeholder — Q13) |
| Deferred path | — the wait happens at step 9 |
| Open questions | Q02 |
A biometric liveness check runs in the app before the package is submitted, confirming the same holder is presenting it. It gates the step, is not a credential, and needs building — see Q02.
Notification Id must be received and stored here, or Tala can neither confirm the handoff nor push the decision at step 9. A holder who declined push permission has no Notification Id, gets no handoff confirmation and no decision notification — the decision still exists, but they would have to find it in the Tala app.
The referral gate is enforced by the wallet, not by the extension. The wallet will not start a step unless the holder holds every credential it requires. Tala then verifies and approves per its own policy. No gate logic lives in the Tala Onboarding extension.
Step 9Your Loan Decision
| Service | Tala |
| Mechanism | Plain interaction webhook · deferred — started by Tala once KYC, fraud, affordability and credit have run |
| Initiation | Service push |
| Processing policy | Sequenced |
| Requires | — Tala already holds the package from step 8 |
| Required via | — |
| Web view steps | — |
| Issues | Loan Offer — exactly one platform limit. Nothing is issued on a decline |
| Attribute sources | All filled by the Tala webhook |
| Config (service) | Lending policy — not specified in the source, and Tala’s to state |
| Config (interaction) | — |
| Success message | “Tala has made you a loan offer.” (placeholder — Q13) |
| Failure messages | To be confirmed — Q10 |
| Deferred path | This step is the deferred path. Nothing on the platform expires an abandoned case, so Tala must explicitly call credentials-issuing-failed on a decline, or the event waits forever |
| Open questions | Q09, Q10 |
Amount, term, rate and offer expiry are all unstated, and none may be inferred — the source deliberately leaves every product parameter to Tala. Needed before the schema is written.
This matters more than the other wording placeholders. The pilot’s premise is that refugees are currently screened out at the data-sufficiency stage, and its fairness measures include complaints and appeals. If there is an appeal route, does it appear in the wallet or only in the Tala app?
Credential Dictionary
Every credential defined exactly once, and referenced by name everywhere else. Used by is what stops a schema changing without anyone noticing who depended on it.
All Date attributes store epoch seconds and display as DD/MM/YYYY. The platform has no string date type: a Date attribute is an epoch integer in its declared units, and the wallet renders it. Storing a literal 27/08/2026 would need a Text attribute, which loses every comparison — including checking Expiry Date against today.
There is no profile credential. See 6.2.
Verified ID Credential
| Attribute | Type | Format / values | Notes |
|---|---|---|---|
| Document Type | Enum | 1 Refugee ID · 2 National ID · 3 Passport | Transmitted as the number, never the label. Reserve a value now for any fourth type |
| Document Number | Text | free text | No regex editor in the dashboard — enforce in the Etymos backend |
| Full Name | Text | as printed | Verifies the profile’s name |
| Date of Birth | Date | epoch seconds | Verifies the profile’s date of birth |
| Nationality | Text | Q05 | ISO 3166 alpha-3, or the document’s own wording |
| Issuing Authority | Text | free text | |
| Expiry Date | Date | epoch seconds | The document’s expiry. The credential expires with it |
| Validation Result | Enum | Q04 | Does it separate document failure from liveness failure? |
| Liveness Verified | Enum | Q04 | Attests a biometric liveness check was performed at issuance. Not a liveness result — see 6.3 |
| Verification Timestamp | Date | epoch seconds | When the check ran, which is what makes the liveness attestation meaningful |
No registry-match attribute: the positive-only rule is a Smile ID policy setting, so it never reaches a schema.
Verified Email Credential
| Attribute | Type | Format / values | Notes |
|---|---|---|---|
| Email Address | Text | RFC 5322 | No regex editor — enforce in the backend |
| Verification Timestamp | Date | epoch seconds | |
| Verification Method | Enum | 1 OTP | One value at launch — reserve the numbering, a schema cannot be edited later |
| Issuer | Text | Civitas Social Stamps | Kept for human readability in the wallet |
Verified Mobile Credential
| Attribute | Type | Format / values | Notes |
|---|---|---|---|
| Phone Number | Phone | E.164 | Verifies the profile’s phone number |
| Verification Timestamp | Date | epoch seconds | |
| Verification Method | Enum | 1 OTP | Same enum as Verified Email — keep the values identical across both schemas |
| SIM Ownership Match | Enum | Q06 | Needs a value meaning “provider had no data” |
| SIM Tenure | Number | Q06 | Months or days — unit must be declared |
| SIM Swap Recency | Number | Q06 | Days since last swap, and a value for “never swapped” |
| Issuer | Text | Civitas Social Stamps | Kept for human readability, matching Verified Email |
Etymos Feature Set
| Attribute | Type | Format / values | Notes |
|---|---|---|---|
| Pseudonymous Applicant Reference | Text | Q08 | Minted by Etymos. The join key for outcome data — a DID cannot serve |
| derived features | placeholder | placeholder | Q07 — held open |
| confidence levels | placeholder | placeholder | Q07 |
The source lists “Verified ID, verified email” among this credential’s own attributes. A credential cannot contain credentials. The recommendation is a derivation note with no copied values, since copying defeats the data minimisation the source argues for. Still unanswered.
Loan Offer
| Attribute | Type | Format / values | Notes |
|---|---|---|---|
| offer terms | Q09 | Q09 | Amount, term, rate and offer expiry are Tala’s to state |
Notification Id
| Attribute | Type | Format / values | Notes |
|---|---|---|---|
| Notification Id | Text | push token | A service can only push to a holder whose Notification Id it has already received and stored. Present only if the holder allowed push notifications |
Every credential here is marked revocable, so every credential definition needs a revocation registry stood up at definition time — a registry cannot be added to an existing definition afterwards. Marking them all revocable is the safe default precisely because the decision is irreversible in the wrong direction: an unused registry costs nothing, a missing one costs a re-issue to every holder.
Verified ID has an answer — manual revocation, plus expiry. The others do not. Are Verified Email and Verified Mobile revoked when the address or number stops being reachable? Is the Feature Set revoked when it is rebuilt, which would make Q08’s stability question sharper? Is a Loan Offer revoked when it expires, or left standing as the holder’s record?
Open Questions
13 open. Two gate writing anything to the ledger — Q07, the feature list, and Q11, revocation, because a revocation registry is created with the credential definition and can never be added afterwards.
Question IDs are stable. A question keeps its ID for life, a closed question’s ID is never reused, and new questions take the next free number. Closed questions move to the change audit.
| ID | Where | Question | Status |
|---|---|---|---|
| Q01 | Steps 5, 6 | Are the email and mobile OTP flows native in-app too, or still web view steps? | Open |
| Q02 | Step 8 | Failure behaviour of the pre-submission liveness check — retry, block, record? | Narrowed |
| Q03 | Step 4 | How is the native SDK result bound to the platform event, tamper-resistantly? | Open |
| Q04 | Step 4 | Validation Result enum values, and whether liveness is its own attribute | Open |
| Q05 | Step 4 | Nationality — ISO 3166 alpha-3 or the document’s wording? | Open |
| Q06 | Step 6 | SIM Tenure and Swap Recency — types, units, and no-data values | Open |
| Q07 | Step 7 | The feature list, types and ranges | Gates ledger |
| Q08 | Step 7 | Pseudonymous reference — stable across a re-issue of the Feature Set? | Held open |
| Q09 | Step 9 | Loan Offer attributes — amount, term, rate, offer expiry | Open |
| Q10 | Step 9 | Decline message, and whether an appeal route appears in the wallet | Deferred |
| Q11 | Dictionary | Who revokes each credential and on what trigger | Gates ledger |
| Q12 | Dictionary | Feature Set listing credentials as attributes — copied, referenced, or neither? | Open |
| Q13 | All cards | Customer-facing wording throughout, and the language set for Kakuma and Nairobi | Deferred |
Reference
Supporting detail behind decisions made in sections 2 to 4.
6.1 Source steps that are not platform interactions
| Source step | Why it has no card |
|---|---|
| 1 · Referral and app entry | App install and RLO assistance. Nothing runs on the platform |
| 2 · Onboarding | Passcode and profile are entered in the app and stay on the device |
| 6 · Referral gate | The wallet will not start a step whose required credentials are missing |
| 8 · Handoff to Tala | A deep link, not an interaction. The credential exchange is step 8 of this journey |
| 10 · Outcome data return | Backend API from Tala to Etymos. Never touches the wallet |
6.2 The profile is not a credential
Passcode and profile — name, date of birth, phone number — are entered in the app, held on the device, and never sent anywhere. Nothing is issued.
The profile is a view, not a credential. Each of its attributes starts self-attested and becomes verified when a credential covering it is issued: the phone number when Civitas Social Stamps issues Verified Mobile Credential, name and date of birth when Etymos issues Verified ID Credential. The profile display updates to reflect that.
There is no profile schema, no credential definition and no interaction — which is why the platform’s one-credential-per-interaction limit never applies to it.
6.3 Liveness
Liveness cuts two ways in this flow.
- At issuance. Verified ID Credential attests that a biometric liveness check was performed when the identity was verified. That attestation travels with the credential.
- At presentation. The Civitas app runs a fresh biometric liveness check before the holder submits the package to Tala, confirming the same person is submitting it. This is a wallet-side gate, not a credential and not a platform mechanism. It needs building — see Q02.
A liveness result still cannot be issued as a credential: it stales the instant it is issued, because liveness confirms presence at a moment rather than a durable fact. The credential can carry the fact that a check happened, and the app can prove presence again when it matters.
Civitas runs the presentation-time check regardless. Whether Tala also runs its own at origination is Tala’s decision. The pilot’s manual-review-reduction measure should therefore not count liveness as a saving unless Tala confirms it is dropping their own.
6.4 Platform limits applied to this flow
Recorded because they changed this specification, not as advice.
| Limit | Effect here |
|---|---|
| One issued credential per interaction | The source’s step 4 became two steps. More is rejected with 409 credential <id> should not be issued in action <n> |
| A credential may not be required by both an interaction and its extension | Required credentials are declared once, on the extensions at steps 7 and 8. Both would return 422 credential <id> is required by interaction and integration <id> |
| Revocation registries are created with the credential definition | Never added later, so Q11 gates the ledger alongside Q07 |
| Nothing expires | An undecided loan waits forever unless Tala calls credentials-issuing-failed |
| A service can only push to a holder whose Notification Id it stores | Tala collects it at step 8, or cannot reach the holder at step 9 |
| In-app camera capture fails inside a WebView | No longer applies — identity verification uses a native SDK. Would return if any capture step moved into a web view |
| Extensions need three writes — define, install, attach | Missing one produces silence, not an error. Also needs a default webhook key, or config reads return 500 |
| No attribute validation regex has a dashboard editor | Document Number, Email Address and Phone Number formats are the backends’ responsibility |
pingUrl is never called | Pilot monitoring must point at a real health endpoint |
6.5 Terminology
The source document, the Civitas dashboard and the platform backend use different words for the same things.
| This document | Backend | Source document |
|---|---|---|
| Interaction / step | action template | feature, service, journey |
| Extension | web-integration | integration |
| Event | subscriber action | — |
| Credential | credential definition | credential |
| Web view step | mini-app | — |
Change Audit
Every answer recorded, in sequence, with what it changed. Question IDs referenced here are stable and are never reused.
| Question | Answer | Change to the specification |
|---|---|---|
| Tala handoff shape | Tala runs its own Civitas service | Tala-side steps kept in the wallet. Credentials presented directly, decision returned as a credential |
| Email / mobile issuer | Civitas Social Stamps | Issuing service named throughout, replacing the placeholder “Civitas ID” |
| Selfie and liveness | Cannot be a credential — it stales on issue | Liveness removed from the shared set. Recorded that Tala cannot receive it and must run its own |
| Trigger for first step | In-app button | All steps became in-app buttons. Raised how a fresh wallet connects |
| Basic profile | Retained as self-attested, attributes lockable | Added a Basic Profile credential and its own step — later reversed, see revision 5 |
| Manual review | Not in scope | Identity verification became immediate. Dropped its Notification Id requirement |
| IDV provider | Smile ID — refugee ID coverage | Named in service config. Flagged the Android WebView camera limitation |
| Document enum | Accepted 1 / 2 / 3 | Values fixed in the dictionary, with a note to reserve a fourth |
| Registry match | A Smile ID policy, not a schema attribute | Removed from the credential. Recorded as service config |
| Verified ID revocation | Revocable manually, expires per date | Set in the dictionary. Raised revocation for the other credentials |
| SIM signals | Ownership match, tenure and swap recency | All three added as attributes. Types and units raised |
| Feature derivation | Extension | Mechanism confirmed. Recorded the three-write install sequence |
| Consent | No separate Consent credential | Presentation is the consent. No extra step |
| Handoff confirmation | A notification, not a credential | Step 8 issues nothing |
| Loan decision | Is a credential | Loan Offer added to the dictionary, attributes raised |
| Feature list | Placeholder pending | Held as a blocking gap |
| Date format | DD/MM/YYYY, seconds acceptable | Corrected — the platform has no string date type. Stored as epoch seconds, displayed DD/MM/YYYY |
| Outcome join key | Proposed the DID | Corrected — a subscriberConnectDid is stable only per customer-service pair. Etymos must mint a reference |
| Question | Answer | Change to the specification |
|---|---|---|
| Pseudonymous reference | Agreed | Minting confirmed. Stability across re-issue remained open as Q08 |
| Referral eligibility | Not a credential — the wallet blocks the holder without required credentials | Removed the Referral Eligibility credential and its step. Gate documented as a wallet behaviour |
| Notification Id trust level | “Machine generated, not self-attested” | Corrected — trust level describes who attests, not who generates. Kept self attested, confirmed at revision 4 |
| Date format | Confirmed | Epoch seconds, displayed DD/MM/YYYY |
| Question | Answer | Change to the specification |
|---|---|---|
| Revocation | Make all credentials revocable, keep flagged | Every credential set revocable. Raised to a second ledger gate, since registries cannot be added after the definition exists |
| Feature list | Keep as an explicit placeholder | Marked held open rather than awaiting a nudge |
| Pseudonymous reference | Keep open | Marked held open |
| Question | Answer | Change to the specification |
|---|---|---|
| Profile creation | Not a web view. In-app, self-attested, device-based | Removed the profile step entirely. Nothing is sent to any service |
| Profile as a credential | No one issues it. Attributes are verified individually | Removed the Basic Profile credential and schema. Documented the profile as a view whose attributes become verified as credentials land. Dissolved two questions rather than answering them |
| Identity verification | Native IDV SDK in app, not a web view | Mechanism changed to a plain webhook. Removed the Android WebView camera risk. Raised how the SDK result binds to the platform event (Q03) |
| Service connection | Services pre-loaded, holder connects during each service’s flow | Journey note added. Closed the connection question |
| Liveness at issuance | The credential can attest liveness was performed | Added the Liveness Verified attribute |
| Liveness at presentation | The app must re-check before submitting to Tala | Added a wallet-side gate at step 8 |
| Issuer attribute | Keep for human readability | Retained on both contact credentials |
| Verification method | OTP | Enum fixed at 1 OTP, numbering reserved |
| Informational push | Works without an attached credential, if push is allowed | Handoff confirmation confirmed viable. Recorded that a holder who declines push receives nothing |
| Question | Answer | Change to the specification |
|---|---|---|
| Pre-submission liveness | Needs building | Recorded. Question narrowed to failure behaviour only, retained as Q02 |
| Tala liveness | Civitas runs it regardless. Tala’s own is Tala’s choice | Closed. Recorded that the manual-review-reduction measure should not count liveness unless Tala confirms it is dropping their own |
| OTP flows native? | Keep open | Retained as Q01 |
| Remaining questions | Keep open for team discussion | Retained |
Structural changes this revision. Question IDs made stable, so an ID now means one thing for the life of the document. Steps 1–3 restored to the journey — partner referral, app onboarding and profile creation — numbered in a single sequence with the platform interactions, so the journey reads end to end. Interaction cards renumbered to match. Colour-band shading removed from the diagram in favour of plain notes, so it renders identically in every viewer. Pilot Overview added. Reference material moved to section 6. Version history moved here from the body.