Risk Signal Registry
Abstract
This document is the normative catalogue of risk signal types in the global domain. Each entry defines a signal type URN, the structure of its value, and any processing rules specific to that type. It carries no framework requirements: the signal envelope, the collection trigger, transport, verification, and encryption are defined by [PaSO Risk Signals], and the bundling of signal types into referencable sets is defined by risk signal profiles ([PaSO Risk Signals] Section 3).
1 Introduction
1.1 Overview
[PaSO Risk Signals] defines the mechanism by which a Wallet collects device, environment, and transaction observations and carries them to the Authorizing Party in the holder binding proof. This document defines the vocabulary those mechanisms operate on. Separating the two allows a signal type to be added, or a new domain's catalogue to be published, without amending the framework.
Signal types are referenced by risk signal profiles, which bundle them with a requirement flag and an optional freshness bound. A profile SHALL reference only signal types whose definition is published.
1.2 Scope
This document defines signal types in the global domain. It does not define the signal envelope, how collection is triggered, how signals are transported or encrypted, or how the Authorizing Party verifies them — all of which are defined by [PaSO Risk Signals]. Organisations MAY publish signal types in their own domain following the identifier structure of [PaSO Risk Signals] Section 2.1.
1.3 Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] and [RFC8174] when, and only when, they are written in all capital letters.
2 Signal Types
Each entry below defines a signal type URN and the structure of its value. The value is present if and only if status is ok, per [PaSO Risk Signals] Section 2.2.
Signal types divide into three kinds, which differ in how status and collected_at behave:
- Measured signals (Sections 2.1 to 2.4) report a sensor or platform observation. Measurement can fail or be refused, so
statusMAY beunavailableordenied, andcollected_atis the time of measurement. - Device-fact signals (Sections 2.5 and 2.6) report a property of the device platform. No permission is involved, so
statusSHALL NOT bedenied. A Wallet that implements the type SHALL reportstatusok, except that it MAY reportunavailablewhere the platform does not expose the values.collected_atis the time of reading. - Transaction-fact signals (Sections 2.7 and 2.8) report something the Wallet already knows from processing the transaction. No sensor and no permission is involved, so a Wallet that implements the type SHALL report
statusok.
2.1 Geolocation
Type: urn:paso:risk:global:geolocation:1
A measured signal. The value is an object with the following members:
| Member | Required | Description |
|---|---|---|
lat |
yes | WGS84 latitude in decimal degrees. |
lon |
yes | WGS84 longitude in decimal degrees. |
accuracy |
yes | Horizontal accuracy radius in metres. |
altitude |
no | Altitude in metres. |
source |
no | One of gnss, network, or fused. |
2.2 Call Activity
Type: urn:paso:risk:global:call_activity:1
A measured signal. The value is an object with the following members:
| Member | Required | Description |
|---|---|---|
call_state |
yes | One of idle, ringing, or active. |
direction |
no | One of incoming, outgoing, or unknown. |
call_active_since |
no | An [ISO8601] timestamp indicating when the current call became active. |
2.3 Device Orientation & Motion
Type: urn:paso:risk:global:device_motion:1
A measured signal. The value reports current device orientation and a bounded statistical summary of motion over a short sampling window. No interpretation (such as "walking") is performed by the Wallet.
| Member | Required | Description |
|---|---|---|
window_ms |
yes | Length of the sampling window in milliseconds. |
orientation |
yes | Object with pitch, roll, and yaw, each the device attitude angle in degrees. |
acceleration |
yes | Object with rms and max, each the user-acceleration magnitude in g over the window. |
rotation_rate |
yes | Object with rms and max, each the gyroscope rotation-rate magnitude in radians per second over the window. |
2.4 Screen Capture
Type: urn:paso:risk:global:screen_capture:1
A measured signal. The value reports whether the device screen was captured — recorded, mirrored, cast, shared, or screenshotted — during an observation window. The Wallet reports platform observations only; it does not identify the capturing application or the capture destination.
| Member | Required | Description |
|---|---|---|
window_ms |
yes | Length of the observation window in milliseconds, ending at collected_at. |
state |
no | One of active or inactive: whether screen capture was in progress at collected_at. |
active_in_window |
no | true if screen capture was observed active at any point in the window, false if the platform reported it inactive throughout. |
screenshot_count |
no | Number of screenshots the platform reported during the window. |
At least one of state, active_in_window, or screenshot_count SHALL be present. A value containing only window_ms is not permitted: where the platform exposes none of the three observation members, the Wallet SHALL report status unavailable instead. Where the platform exposes either of state or active_in_window, it exposes both; if one is present, the other SHALL be present as well.
The observation window SHOULD cover the period during which the transaction details were displayed to the user for consent.
The Wallet SHALL include an optional member only where the platform exposes the underlying observation, and SHALL omit it otherwise. An omitted member means the platform could not observe, not that no capture occurred; the Authorizing Party SHALL NOT interpret an omitted member as evidence that the screen was not captured.
The available member set is a function of the platform and OS version, not of the transaction. On iOS the platform reports a single capture state [Apple Screen Capture] that does not distinguish screen recording, mirroring, or sharing, and separately notifies the app of screenshots [Apple Screenshot Detection]; the Wallet SHALL report the state as given and SHALL NOT infer the capture destination. On Android, capture state is observable from Android 15 [Android Recording Detection] and screenshot events from Android 14 [Android Screenshot Detection]; on earlier versions the corresponding members are absent. The value SHALL therefore be interpreted in the context of the platform and OS version, which the Device Basics signal (Section 2.5) reports. A risk signal profile that includes this signal type SHOULD also include urn:paso:risk:global:device_basics:1.
2.5 Device Basics
Type: urn:paso:risk:global:device_basics:1
A device-fact signal. The value is an object with the following members:
| Member | Required | Description |
|---|---|---|
manufacturer |
yes | Device manufacturer as reported by the platform (e.g., Apple, samsung, Google). |
model |
yes | Platform model identifier as reported by the platform (e.g., iPhone17,1, SM-G920F, Pixel 9). |
os_name |
yes | Operating system name (e.g., iOS, Android). |
os_version |
yes | Operating system version string as reported by the platform (e.g., 21.0, 17). |
The Wallet SHALL report each value as provided by the platform and SHALL NOT map it to a marketing or product name (e.g., "iPhone 17 Pro"). Platforms do not expose marketing names uniformly, and such a mapping would require a curated lookup table inside the Wallet, making the value an interpretation rather than an observation. Resolving platform identifiers to product names is the Authorizing Party's concern.
2.6 App Vendor ID
Type: urn:paso:risk:global:app_vendor_id:1
A device-fact signal. The value is an object with the following members:
| Member | Required | Description |
|---|---|---|
id |
yes | The platform-issued vendor-scoped app identifier: on iOS the Identifier for Vendor [Apple IDFV], on Android the App Set ID [Android ASID]. |
scope |
no | The identifier's scope where the platform reports one: developer or app (the Android App Set ID scopes). |
The value identifies the Wallet vendor's app set on this device, not the vendor globally. The identifier is resettable: the platform issues a new value when the user deletes all of the vendor's apps (iOS), on factory reset, or after prolonged non-use (Android). The Authorizing Party SHALL NOT treat it as a permanent device identifier. On iOS the platform may transiently fail to provide the identifier after a device restart before first unlock; the Wallet MAY report status unavailable in that case, per the device-fact rule in Section 2.
The identifier is a stable pseudonym that enables correlation of transactions originating from the same device and Wallet vendor. An ecosystem that includes this signal type for a transaction data type used in a third-party flow ([PaSO Core] Section 3) SHOULD require encryption of the risk signals per [PaSO Risk Signals] Section 7, so that a Relying Party forwarding the proof package cannot use the value as a tracking identifier.
2.7 Response Mode
Type: urn:paso:risk:global:response_mode:1
A transaction-fact signal. The value is a string: the response_mode parameter as given or defaulted in the [OID4VP] Authorization Request.
A Wallet that implements this signal type SHALL report status ok and SHALL set collected_at to the time at which it processed the Authorization Request.
The Authorizing Party verifies this value against the Authorization Request it received, per [PaSO Proof Verify] Section 3.
2.8 Authentication Methods
Type: urn:paso:risk:global:amr:1
A transaction-fact signal. The value is a JSON array of strings reporting the authentication methods by which the user released the transaction.
Values from the IANA "Authentication Method Reference Values" registry [RFC8176] SHALL be used where applicable. Common values include pin, pwd, hwk, swk, and otp.
This document defines two additional values for biometric strength:
| Value | Criteria |
|---|---|
bio_strong |
Biometric matching in hardware-isolated environment (e.g., TEE, Secure Element); FAR ≤ 1:50,000; presentation attack detection required. |
bio_weak |
Biometric matching with FAR ≤ 1:10,000; does not meet bio_strong criteria. |
When a biometric factor is used, the Wallet SHALL include exactly one of bio_strong or bio_weak. The Wallet SHOULD additionally include the modality value (fpt, face, iris) when the platform identifies it.
When used in a [PSD2] context, the value array SHALL cover at least two different categories of authentication elements (knowledge, possession, inherence) as required by [PSD2] Article 4(30).
A Wallet that implements this signal type SHALL report status ok and SHALL set collected_at to the time at which the user completed authentication.
[PaSO Core] does not require this signal. An ecosystem that requires Strong Customer Authentication SHALL publish a risk signal profile ([PaSO Risk Signals] Section 3) that includes this signal type with required set to true, and SHOULD observe the encryption advisory in [PaSO Risk Signals] Section 7.8.
3 References
| Reference | Description |
|---|---|
| [PaSO Core] | PaSO Core |
| [PaSO Risk Signals] | PaSO Proof: Risk Signals Module |
| [PaSO Proof Verify] | PaSO Proof: Verify Module |
| [OID4VP] | OpenID for Verifiable Presentations 1.0 |
| [PSD2] | Directive (EU) 2015/2366 on payment services in the internal market |
| [Apple IDFV] | Apple Developer Documentation — identifierForVendor |
| [Android ASID] | Android Developers — Identify developer-owned apps (app set ID) |
| [Apple Screen Capture] | Apple Developer Documentation — UIScreen.isCaptured |
| [Apple Screenshot Detection] | Apple Developer Documentation — UIApplication.userDidTakeScreenshotNotification |
| [Android Recording Detection] | Android Developers — Screen recording detection (Android 15) |
| [Android Screenshot Detection] | Android Developers — Screenshot detection (Android 14) |
| [RFC2119] | RFC 2119 — Key words for use in RFCs |
| [RFC8174] | RFC 8174 — Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words |
| [RFC8176] | RFC 8176 — Authentication Method Reference Values |
| [ISO8601] | ISO 8601 — Date and time format |