TECHNOLOGY CONFORMANCE CRITERIA
++ To establish trust, verifiability, and auditability among the trading partners involved in the OCI ecosystem, an + open, interoperable, portable, standards-based, decentralized identity framework is essential. +
++ OCI uses decentralized public key infrastructure (PKI) technology for Digital Wallets and for + electronically + signed Verifiable Credentials about the enterprises involved in the ATP verification process. +
++ The OCI conformance criteria are based on a set of identity standards (W3C standards, IETF standards, Hyperledger Aries), open API standards, and existing industry standards for PI message exchange (GS1 Lightweight + Messaging Standard for Verification of Product Identifiers). +
++ It shall be noted that the OCI Digital Wallet Conformance Criteria distinguishes between Cloud- and Edge + wallets + as + illustrated below. +
+
+ This diagram shows the basic differences between edge and Cloud wallet implementations. While public keys + and + other data are stored on the cloud, the private keys of Trading Partners and Credential Issuers may be located + either on a local edge device, or managed by a (Cloud wallet) provider. Interoperability occurs at the level of + Verifiable Presentations created and exchanged between wallets. Where potential interoperability between multiple + Wallet Providers and Credential Issuers is desired, the OCI Digital Wallet Conformance Criteria include specific + DIDcomm requirements. +
+Digital Wallet Standards
+The following is a high-level overview of the technologies used by Digital Wallet providers as part of this specification:
+| Component | +Realization and References | +
|---|---|
| Identifiers | +W3C Decentralized Identifiers (DIDs) v1.0 (W3C DIDs) | +
| Endorsed DID Methods | +Use of DID methods endorsed by OCI | +
| DID Resolution | +DID resolution using means permissible by OCI | +
| Trusted Credential Issuer Registry | +Registry for vetted, trusted Credential Issuer maintained by OCI | +
| Credential Structure | +Based on W3C Verifiable Credentials Data Model 1.0 (W3C VCs) | +
| Credential Serialization & Schemas | +OCI Credential Schema Definition (OCI Credential Schemas) | +
| Proofs & Verifications | +Cryptographic primitives used for VC creation/verification, JWT creation/verification and wallet-to-wallet + communication. | +
| Credential Issuance & Exchange | +
+ Hyperledger Aries RFCs. +
Decentralized Identity Foundation specs. +
|
+
| Revocation | ++ Directory Service (LDAP) based mechanism for revoking Verifiable Credentials (vc-status-2021-ldap) + | +
Identifiers for Enterprise Identity
++ A DID is a globally unique and location-independent identifier defined by the W3C DID + specification. DIDs enable interoperable decentralized self-sovereign identity management using standardized + Digital Wallets. +
++ Digital Wallet Providers SHALL implement DIDs as cryptographic identifiers and SHALL follow the specification on how DID documents are created and used. +
+DID documents have the following characteristics:
+-
+
- DID documents contain information associated with a DID. +
- They express verification methods, such as cryptographic public keys, and services relevant to + interactions with the DID subject (wallet-to-wallet communication). + +
- The properties present in a DID document and applicable operations to update these properties are + described in DID methods. + +
+ DID methods are the mechanism by which a particular type of DID and its associated DID + document are created, + resolved, updated, and deactivated. DID methods are defined using separate DID method + specifications as + described in the following chapter. +
+Endorsed DID Methods
++ To be resolvable to DID documents, DIDs are typically recorded on an underlying system or network of some kind. Regardless of the specific technology used, any such system that facilitates the creation, verification, + updating, and/or deactivation of decentralized identifiers and DID documents is called a verifiable + data registry (VDR). +
++ There are multiple VDRs used in today’s DID implementations that support different security protocols, + discoverability, and linkage to existing trust networks. To avoid complexity and enable interoperability, OCI + endorses selected DID methods. +
++ Digital Wallet Providers SHALL support the resolving of all DID methods endorsed by OCI, and SHALL implement + at least one such DID method, i.e. create and maintain the resulting DIDs. OCI endorses the following DID methods: +
+| # | +DID Method | +Reference | +VDR | +
|---|---|---|---|
| 1 | +did:ethr | +did:ethr + Method Specification | +Ethereum Mainnet | +
| 2 | +did:web | +did:web Method Specification | +Secure data store maintained by the implementer | +
Securing did:web
++ Implementers of the DID method SHALL implement measures to cover the security and privacy + considerations outlined in the + + did:web method specification. + This includes possible attack vectors for man-in-the-middle attacks, DNS record spoofing, DID + document integrity, and in-transit security. Providers of did:web VDRs SHALL not correlate usage + of another subjects DID during resolution for credential verification for privacy reasons. +
++ Due to the centralized nature of this DID method, implementors SHALL make sure that the VDR + is highly available and resilient to availability attacks. If DID resolutions fails, digital wallets + are unable to verify credentials and trading partner ATP statuses. +
+Securing did:ethr
++ Implementers of the DID method SHALL implement measures to cover common security attacks. This + includes private key hijacking on the wallet, man-in-the-middle attacks, and in-transit security while + communicating with an Ethereum node. Self-hosted or OCI-owned Ethereum nodes SHOULD be used to mitigate + some of those attack vectors. Enterprise-grade blockchain infrastructure-as-a-service platforms MAY be used. +
+Due to DID document related metadata being persisted on the Ethereum-blockchain, measures to make the + DID document generally available NEED NOT to be employed.
+DID Resolution
++ Digital Wallet Providers SHALL integrate DID resolver functionality for resolving DID documents. The + DID resolver SHALL support all DID methods endorsed by OCI. It SHALL be a + trusted open source DID resolver with broad community participation (e.g. DIF Universal Resolver, Veramo, or + DIDKit) vetted against the non-functional conformance criteria outlined in this document. Wallet providers SHALL NOT use public instances of resolvers, instead using their own implementations. +
+Trusted Credential Issuer Registry
++ To enable Digital Wallet Providers to accept credentials issued from a vetted Credential Issuer only, OCI + maintains a Trusted Credential Issuer registry. Digital Wallet Providers SHALL be able to process and verify credentials issued by any vetted + Credential Issuer that is endorsed via the OCI registry. +
++ The trust placed in Credential Issuers is a key aspect of the OCI ecosystem. In order to + ensure that this key role is not exploited, the trust is anchored + in a decentralized and cryptographically verifiable way. The crucial information of which issuers, who have satisfied OCI’s Credential Issuer Conformance Criteria, are to be trusted is stored in the Trusted Issuer Registry, which is managed through Ethereum Smart Contracts. +
++ OCI maintains multiple versions of the Trusted Issuer Registry for production and demo/testing purposes. + You can find the deployed contracts at these addresses: +
+-
+
- + Development STK-INT (Goerli) + +
- + Development WLT-INT (Goerli) + +
- + Development PBL-INT (Goerli) + +
+ The development environments are deployed on an Ethereum test network. STK-INT mirrors the production + environment and should only be used for testing purposes by approved OCI statekeepers. WLT-INT should be used + only by OCI digital wallets for testing purposes without voting processes. PBL-INT is generally open without + any restrictions to make quick testing easy. +
+In addition to readily deployed versions of the contracts, OCI has also published the source code as well as + implementation guidelines on GitHub: Trusted Issuer Registry. +
+Verifying the Credential Issuer
++ At each generation and verification of a Verifiable Presentation, a Digital Wallet SHALL check if the respective Verifiable + Credential has indeed been issued by a Trusted Issuer. To accomplish this, a wallet SHALL + call one of the following contract method signatures to verify the status of the Credential Issuer: +
+-
+
-
+ Retrieve the full list of all Trusted Issuer DIDs.
+
-
+
-
+ Signature:
+
+ function getTrustedIssuers() public view returns (string[] memory) ++
+ -
+ Returns a string array:
+
+ ["did:ethr:0xf3beac30c498d9e26865f34fcaa57dbb935b0d74", "did:web:example.com", "did:key:0c498d9e26865f34fcaa50c498d9e26865f34fcaa5"] ++
+
+ -
+ Signature:
+
-
+ Retrieve the Trusted Issuer status of given a supplied DID.
+
-
+
-
+ Signature:
+
+ function isTrustedIssuer(string memory _DID) public view returns (bool) ++
+ -
+ Returns a boolean:
+
+ true/false ++
+
+ -
+ Signature:
+
+ A Digital Wallet MAY also subscribe to changes on the Trusted Issuer Registry by listening to events emitted + by the contract. This way, the wallet can be notified of changes to the Trusted Issuer Registry and update + its local state accordingly. +
++ By deriving this information from the contract, the Digital Wallet SHALL check that the issuer stated within the claims of the respective + Stakeholder credential matches one of those trusted issuers recorded in the Trusted Issuer Registry. +
++ The Digital Wallet SHALL have measures in place to request other Ethereum nodes in case the requested node is down or does + not respond in a reasonable amount of time. +
+Credential Structure
++ Working groups at the W3C author, host, and maintain the W3C + Verifiable Credential Data Model specification. + The structure of a VC is an important component of interoperability. +
++ OCI relies on an implementation of a common standard for the credential structure. Digital Wallet Providers + SHALL implement Verifiable Credential Data Model 1.0. +
+Credential Serialization & Schemas
++ Credentials that are issued by the Credential Issuer are created in accordance with the W3C JSON-LD format for + schema serialization. To ensure processing, validation, and interpretation of Verifiable Credentials by + different implementers, JSON-LD schemas for identity and Stakeholder credentials are introduced. Digital + Wallet + Providers SHALL support the JSON-LD format and SHALL support JSON-LD schema validation. +
++ The Digital Wallet provider SHALL have mechanisms in place to support multiple valid versions of + credential + schemas endorsed and published by OCI. Such a mechanism will allow handling transition periods when new + credential schema versions are released and the industry has to adopt changes to schemas. It shall be + understood that there can be multiple schema versions active, decommissioned, and revised versions can have an + expiration date. Decommissioned schema versions SHALL return an error by the ATP credential + verification API. +
++ OCI documents and publishes approved (active), revised, and decommissioned versions of the + Identity and Stakeholder credential schemas on https://open-credentialing-initiative.github.io/schemas/. +
++ Digital Wallet Providers SHALL support the OCI approved credential schema for processing, validation, and interpretation that are published on the OCI + Github for: +
+-
+
- + Identity + Credential + +
- + DSCSA + ATP Credential + +
- + DSCSA + ATP Equivalent Credential + +
- + DSCSA + Authority Credential + +
+ Digital Wallet Providers SHALL be capable of managing the Identity Credential, and of managing at least one of the three Stakeholder Credential types indicated above. +
+Proofs & Verifications
++ Electronic signatures are captured in three places during a digital transaction to verify its authorization. + The Digital Wallet Provider SHALL implement the following signature suites and algorithms for signing + and + verification: +
+| # | +Signing Entity | +Use Cases | +Proof and Verification | +
|---|---|---|---|
| 1 | +Credential Issuer: Credential Issuance | +
+ + Issuance of a Verifiable Credential from Credential Issuer’s wallet to a Trading Partner’s wallet via + DIDComm protocol. + +
|
+
+ + Verifiable Credential’s proof SHALL be generated and verified in conformance with + Ed25519Signature2018 + or + + EcdsaSecp256k1RecoverySignature2020. + + |
+
| 2 | +Trading Partner: ATP PI Verify Workflow | ++ Generation and Verification of a Verifiable Presentation that proves the possession of “DSCSA ATP + Credential” in the context of the GS1 Lightweight Messaging Standard. + | ++ Verifiable Presentations SHALL be encoded as JSON Web Tokens [[RFC7519]] per vc-data-model and signed using + JSON Web Algorithm ES256K and verified accordingly. See [[RFC7518]] Section 3 for more information + on the + ES256K Digital Signature. + | +
| 3 | +Trading Partner: Direct Presentation Exchange | +
+ + Presentation of a Verifiable Presentation between Stakeholder wallets or from Stakeholder’s + wallet to Credential Issuer’s wallet via DIDComm protocol. + +
|
+ + Verifiable Presentation’s proof SHALL be generated and verified in conformance with JSON Web Signature 2020 Linked-Data Signature Suite. + | +
Credential Issuance & Exchange
++ Communication between Credential Issuer’s Digital Wallet and Stakeholder’s Digital Wallet or + between trading parties for the exchange of credentials may be required to issue and exchange credentials. +
+DIDComm
++ The DIDComm Messaging Specification is a secure method for credential issuance based on a set of + interoperable and DID method-agnostic Aries RFCs are working items of the Hyperledger and + Decentralized + Identity Foundation (DIF) that define technical standards specifications. It may be used to support + wallet-to-wallet communication between organizations (e.g. Credential Issuer and Digital Wallet + Provider), + or facilitate secure message exchange within an organization. +
++ Digital Wallet Providers SHALL implement DIDComm capabilities to meet the functional requirements outlined + in the OCI Digital Wallet Conformance Criteria. +
++ This high-level chart may be used as guidance for the subject workflow for credential issuance and exchange. +
+
+ + Beyond this, the DSCSA Stakeholder SHOULD be able to exchange Verifiable Presentations of their Identity + Credentials with other Stakeholders using DIDComm. This is important when a trading partner receives a + Stakeholder Credential from a previously unknown trading partner and wishes to request the + corresponding Identity + Credential. Having established a trusted communication channel between Stakeholder wallets, + future use + cases that require exchanging credentials can be facilitated more easily. +
+| # | +Specification Source | +Specifications | +
|---|---|---|
| 1 | +Hyperledger Aries RFCs | ++ + | +
| 2 | +Decentralized Identity Foundation Specifications | +
+
|
+
+ Note: OCI has not yet standardized direct wallet-to-wallet communication. This is an overview of + technologies OCI expects to be used for direct wallet-to-wallet communication in the near future. + Refer to the OCI Conformance Program + for more details. +
+Credential Revocation
++ OCI supports a revocation management method based on LDAP Credential Revocation Lists. Consequently, Digital Wallet Providers SHALL implement API calls to the LDAP server(s) of the Credential Issuer(s) to check the revocation status for determining whether a Verifiable Credential has been revoked. +
++ A Digital Wallet Provider MAY implement a caching mechanism for Credential revocation data to + cache LDAP data for up to 24 hours. +
++ It shall be understood that existing cached data can be used when the Revocation List is not available + for an update of the local cache due to a technical downtime. A Digital Wallet Provider SHALL store + communication request data when the Revocation List is not available to establish an audit trail. Revocation + data older than 24 hours SHALL be considered invalid and result in a failed credential verification. +
++ To mitigate man-in-the-middle attack vectors, Digital Wallet Providers SHALL implement + LDAPS, which is LDAP secured by communication over Transport Layer Security (TLS) protocol. +
+Cloud Wallet Interfaces and OpenAPI Integration
++ OCI wallet providers that provide a cloud wallet SHALL implement the interfaces and Open API integration defined + below. +
+| ID | +Specification Source | +Bidirectional Communication | +
|---|---|---|
| IF001 | +Interface for Human Users | +Digital Wallet Solution ⬄ Wallet Administrator | +
| IF002 | +API Integration with VRS Provider | +Digital Wallet Solution ⬄ VRS Provider | +
| IF003 | +API Integration with Revocation DB | +Digital Wallet Solution ⬄ Revocation DB of Credential Issuer | +
| IF004 | +API Integration with VDR | +Digital Wallet Solution ⬄ Verifiable Data Registry (VDR) | +
| IF005 | +API Integration with Credential Issuer | +Digital Wallet Solution ⬄ Credential Issuer | +
+
+
| + | + |
|---|---|
| ID | +IF001 | +
| Description | +Interface for Human Users | +
| Type | +Manual interface, Connection: HTTPS | +
| Information Flow Direction | +Bidirectional: Human User ⬄ Enterprise Digital Wallet | +
| Input Data | +Enterprise Digital Wallet Administration Data, User and Role Management Data, Onboarding Data for + Credential acquisition + | +
| Output Data | +Stakeholder Monitoring Data (list of connections with Stakeholder counterparties, identity credentials of Stakeholder + counterparties, status of VPs, Stakeholder validation of individual PI verify requests), Wallet + Administration Data + (users and roles, my company/organization identity and Stakeholder credentials). | +
+
+
| + | + |
|---|---|
| ID | +IF002 | +
| Description | +API Integration with VRS Provider, API Interface for creating and verifying Stakeholder Credential Presentations + | +
| OpenAPI Specification | +https://open-credentialing-initiative.github.io/api-specifications/v2.0.0/#/VerifiablePresentation/postVerfiablePresentationVerification> + | +
| Type | +REST API, authentication via OAuth2.0 bearer token, Encryption: SSL TLS v1.2+, Connection: REST on HTTPS + | +
| Information Flow Direction | +Bidirectional, VRS ⬄ Enterprise Digital Wallet | +
| Input Data | +Request creation of Stakeholder Credential Presentation, Verify Stakeholder Credential Presentation | +
| Output Data | +Stakeholder Credential Presentation (JWT), Stakeholder credential presentation verification response. | +
+
+
| + | + |
|---|---|
| ID | +IF003 | +
| Description | +API Integration with Credential Issuer Revocation Database | +
| Specification | +https://spherity.github.io/vc-status-2021-ldap/ + | +
| Type | +REST API, public API with no authentication, Encryption: SSL TLS v1.2+, Connection: REST on HTTPS | +
| Information Flow Direction | +Bidirectional, Credential Issuer Revocation DB ⬄ Enterprise Digital Wallet | +
| Input Data | +Request VC revocation status | +
| Output Data | +Response VC revocation status | +
+
+
| + | + |
|---|---|
| ID | +IF004 | +
| Description | +DID Transactions with DID Registry on Public Ledger, DID document read transactions + via a universal + resolver | +
| Type | +DLT RPC calls, VDR , no authentication required | +
| Information Flow Direction | +Bidirectional, VDR ⬄ Enterprise Digital Wallet | +
| Input Data | +DID transactions: creation, revocation, update | +
| Output Data | +DID transaction (creation, revocation, update) confirmations or DID documents | +
+
+
| + | + |
|---|---|
| ID | +IF005 | +
| Description | +Requesting Verifiable Credential issuance from Credential Issuer | +
| Type | +REST API, wallet-to-wallet communication | +
| Information Flow Direction | ++ Bidirectional, Credential Issuer Wallet ⬄ Enterprise Digital Wallet, Encryption: SSL TLS v1.2+, Connection: + Issuance of Credentials via DIDcomm with Encrypted Messaging Envelope as specified in the DIDComm Messaging Specification based on Aries Protocols. + | +
| Input Data | +Request identity or Stakeholder credential issuance | +
| Output Data | +Identity or Stakeholder Credential | +
+ APIs implemented for IF002 SHALL follow the OCI OpenAPI specification for + Digital Wallet Providers. See OpenAPI specification for further details. +
++ The Digital Wallet Provider SHALL provide API concepts for: +
+-
+
- + Authentication: Endpoints of the Digital Wallets require authentication that is secured via a + JWT. To + obtain a + token and start making requests, the implementer SHALL provide an authentication provider that can process + requests to obtain authentication token. + +
- + Status Codes: Digital Wallets SHALL use HTTP status codes to indicate the success or failure of + API + requests. + If a request fails, it returns an error using the appropriate status code. + +
+ Implementers MUST conform to [[RFC7231]] and [[RFC2616]] when processing and returning HTTP Status Codes to a + requesting client. From RFC7231 Section 6 + - Response Status Codes: +
++++
+- + 1xx (Informational): The request was received, continuing process +
+- + 2xx (Successful): The request was successfully received, understood, and accepted +
+- + 3xx (Redirection): Further action needs to be taken in order to complete the request +
+- + 4xx (Client Error): The request contains bad syntax or cannot be fulfilled +
+- + 5xx (Server Error): The server failed to fulfill an apparently valid request +
+
+ Functional Wallet Features +
+Wallet User Management
++ A solution SHALL integrate an Identity and Access Management (IAM) solution for User and Role + Management into + the Digital Wallet infrastructure. A solution SHALL support user on-boarding, off-boarding and user + Credential + management features and workflows. +
+-
+
- + On-boarding includes a secure process to assign a role to a verified user. This process SHOULD include secure + provisioning of 2FA or multi-factor authentication access credentials to a given user. + +
- + Off-boarding includes an authorized process where an existing user's access to the Digital Wallet is + removed. + +
- + User Credential management includes a secure process to reset and/or rescind access credentials and + change + user roles (where multiple user roles exist). + +
+ The wallet MAY be integrated with existing trading partner identity and access management (IAM) + solutions. + Implementers of solutions for smaller trading partners MAY simplify the user management solution by merging + administrator and user roles, as users and administrators can be the same person. +
+Identity & DSCSA Stakeholder Credential Management
++ A solution SHALL provide a process workflow for acquiring identity and at least one of the three Stakeholder credential types from a vetted + Credential Issuer. +
++ A solution SHOULD provide a feature for users of the Stakeholder to request and log identity credentials + from another counterparty. +
++ A solution SHALL provide a data store for storing identity and Stakeholder credentials and transaction log data + to + support analysis, archive and auditing requirements for DSCSA. +
+Non-functional Wallet Features
++
+
| + | + |
|---|---|
| ID | +NFR001 | +
| NFR Type | +Authentication & Authorization | +
| Description | ++ Only an authorized user can manually access the Digital Wallet application. + | +
| Rationale | +
+
|
+
| Conformance Criteria | ++ Two-Factor Authentication (2FA) SHOULD be implemented. For operational systems, single sign-on with + enterprise IAMs or identity providers MAY be integrated. Role-based access control MAY be configured for + user role-based access. + | +
| Measurement | ++ Above-mentioned authentication mechanisms when users access the application + | +
+
+
| + | + |
|---|---|
| ID | +NFR002 | +
| NFR Type | +Security - Data Authorization & Encryption | +
| Description | ++ Data at rest and in transit shall be protected + | +
| Rationale | ++ Any sensitive data must be encrypted and protected + | +
| Conformance Criteria | +
+
|
+
| Measurement | ++ Functional testing + | +
+
+
| + | + |
|---|---|
| ID | +NFR003 | +
| NFR Type | +Security - Non-repudiation | +
| Description | ++ The system collects evidence of user actions to prove the origin and authenticity of data in the event of a future dispute. + | +
| Rationale | ++ Common compliance requirement that supports accountability and data integrity + | +
| Conformance Criteria | ++ The wallet solution SHALL record user authentication and actions by registered users. + The solution SHOULD record the entity for each credential-related transaction, + including non-repudiable digital signatures for all ATP Credential transactions. + The Wallet Provider SHALL be capable of transferring or making available such auditable records to + the Trading Partner or another party with legitimate interest and right to obtain such data. + | +
| Measurement | ++ Activity logs and, if applicable, archives can be retrieved, made accessible, and can be processed. + | +
+
+
| + | + |
|---|---|
| ID | +NFR004 | +
| NFR Type | +Security - Key Management & Rotation | +
| Description | ++ Key rotation best practices applied to regularly change signing and encryption keys. + | +
| Rationale | ++ Protect application against theft and misuse of signing keys + | +
| Conformance Criteria | +
+
|
+
| Measurement | ++ Application security testing against these features + | +
+
+
| + | + |
|---|---|
| ID | +NFR005 | +
| NFR Type | +Security – Platform & Network Security | +
| Description | ++ The system must adhere to platform security requirements. + | +
| Rationale | ++ Cloud architecture should ensure VRS and Stakeholder systems are secured from attack. Since the system + handles business critical data, the measures taken to protect data need to be defined. Privileged access to + system components is minimized and strictly controlled. + | +
| Conformance Criteria | +
+ + Security is critical to a solution deployed as Cloud Service. Implementers SHALL focus on security + features: + +
|
+
| Measurement | ++ Application security testing against these features + | +
+
+
| + | + |
|---|---|
| ID | +NFR006 | +
| NFR Type | +High Availability | +
| Description | ++ Digital Wallet and credentialing solution systems must be resilient to single points of failure or + outages + | +
| Rationale | ++ When integrated into operations, Stakeholder credentialing is a critical business system + | +
| Conformance Criteria | ++ DevOps infrastructure and cloud services SHALL + be designed in a redundant manner so that the system will continue to + work in production mode (i.e., no degraded performance) if one + component fails. Digital Wallet Providers SHOULD aim for 99.5% + availability + | +
| Measurement | ++ Infrastructure designed for high availability, + resilience and failover with ability to monitor and report on availability + | +
+
+
| + | + |
|---|---|
| ID | +NFR007 | +
| NFR Type | +Maximum system response time | +
| Description | ++ The maximum time taken by the system as a whole to send any information back to the end user who triggered a + query (and out of the transit/transmission overhead). + | +
| Rationale | ++ Solution should be easily scalable to handle high volumes of Product Identifier Verification Requests and + Responses as well as a high number of trading partners without making changes to the overall architecture. + | +
| Conformance Criteria | ++ Solution SHALL provide low-latency APIs so that the average time for performing the two API calls to + generate and verify ATP VPs is in total less than 1500 ms and the maximum time for both calls is + in total less than 3000 ms. Solution MAY apply caching methods (e.g., revocation lists, DID + documents, credential verification events) where technically and legally possible to reduce throughput times + of processing the APIs. Cached data SHALL be valid no longer than 48 hours. Note that other parts of these + Conformance Criteria may set shorter validity times for particular types of cached data. + | +
| Measurement | ++ Average and maximum duration of API calls + | +
+
+
| + | + |
|---|---|
| ID | +NFR008 | +
| NFR Type | +Disaster recovery | +
| Description | ++ The solution must survive a critical data center incident and large scale outage events. + | +
| Rationale | ++ ISMS Standards dictate disaster recovery solution + | +
| Conformance Criteria | ++ The solution SHOULD be replicated in an alternative datacenter. It SHOULD provide back-up and restore + mechanisms. + | +
| Measurement | ++ Recurring disaster recovery tests + | +
+
+
| + | + |
|---|---|
| ID | +NFR009 | +
| NFR Type | +Audit Support | +
| Description | ++ The solution provides auditable granular transaction logs + | +
| Rationale | ++ Data and industry regulations require support for investigations and compliance. + | +
| Conformance Criteria | ++ The Wallet solution SHALL be capable of providing detailed records of all verifiable presentation (VP) generation and + verification events for each Trading Partner. These records SHALL include the corrUUID so that transactions are correlatable across + systems. + | +
| Measurement | ++ Detail of transaction logs and, if applicable, archive. + | +
+
+
| + | + |
|---|---|
| ID | +NFR010 | +
| NFR Type | +Archiving | +
| Description | ++ The solution can archive auditable transaction logs + | +
| Rationale | ++ Data and industry regulations require support for investigations and compliance of current and historical transactions data. + Transaction logs constitute an audit trail to be used, for example, in the event of an investigation into + credential-related activities. + | +
| Conformance Criteria | ++ The Wallet solution SHALL have the capability of keeping detailed records of all VP generation and verification events + to enable the Trading Partner to comply with regulatory data storage requirements. + The Wallet Provider SHALL be capable of transferring or making available such auditable records to + the Trading Partner or another party with legitimate interest and right to obtain such data. + | +
| Measurement | ++ Archived data can be retrieved, are accessible and can be processed. + | +