Identity-BB Status for Tech Committee meeting w33

Reminder

Open

List of further enhancements to be done next quarter for your BB specifications

• Verification / Identity Verification API

  • Integration of OpenID Connect (OIDC) for Identity Verification (Authentication)

• KYC / Attributes sharing

  • Leverage OIDC profile sharing capacity and use Verifiable Credentials as envelop to provide identity related services.

  • Benefits

    • Support interoperability

    • Improve privacy by offering multiple services with data minimization approach

    • Reuse those services OIDC/VC as data exchange protocol/format for issuance of physical and digital credentials

    • Identification services responses (ie ID attributes sharing) always allow to verify information to issuer, it will leverage VC to systematicaly include the way to verify authenticity in data structure sent.

    • Build continuous chain of certified data

    • Allow asynchronous/offline use cases

    • Integrate consent mechanism in overall KYC process

• Management / ID Mapping

  • Offer publish and subscribe mechanism to allow notification of identity related events

  • Clarify and specify ID Mapping for privacy and open to federated and decentralized forms of Identity

  • Tokenization of identifiers: IDBB generate several sectorial identifiers for the same unique person

  • Use of Alias: Foreign existing identifiers can be linked to Unique Identity and later recognized

• IDBB specific interfaces (API Gateway/GUI)

  • It has been identified the need to develop IDBB interface on top of IDBB candidates implementation:

  • A User Interface for individuals (select Identity provider (IDP), collect identity credential, give consent, be informed of personal data usage) This UI would naturally run on individual User Interface.

  • An IDBB API Gateway for:

    • Managing multiple IDP (default IDP being fID)

    • Check/trigger collection of consent

    • Potentially be used for ID Mapping to solve tokens

    • Manage adaptation of candidates implementations of building blocks

  • Individual User Interface need to be inclusive and adapt to various context including low infrastructures/technologies ones.

Open

Illustration of form auto-filling flow involving UI and API Gateway.

Backlog:

• Notification API (to notify output is ready or a change in identity)

• IDBB Gateway with Integration of consent

• Identity management (to create, update an identity, manage ID Mapping, authorizations, ..)

• Credential issuance

• Auditable logs - transaction log, administrative changes log, performance log, security log

List of apis (defined/undefined) aligned to functionalities/services (defined / to be defined) currently in your BB

Prioritized first API in your BB to be targeted for testing. 

Priority 1 API/Services are targeted for coming 1-2 months, they will allow to dispose of necessary APIs for Demo and Sandbox.

Priority 2 API Services are targeted for coming quarter, they will allow to cover Federated and Decentralized identity, address various form of identity, cover more new capabilities for authentication, also asynchronous use cases (including offline).

Lower priority are targeted for next year, they will be priorized according to engaged country needs.

Note, we may identify quick-wins to be done to enable GovStack community to handle new APIs, ie v1.1 of KYC services could be a good candidate for that.

Resources needed for the above in your team (who/new, for what)

There is more than APIs definition to be done, those ones have been inserted below.

Summary:

• Jaume’s available workload too low, need to increase bandwidth from September

• Urgent need to welcome a Tech Lead for IDBB > Target October, TB supported by mutualized Tech team.

• Still need to count with a 2nd independent expert

• Need supporting resources for migration to community environment