Category: GAIN

Top level intro to GAIN

Posted on

The protocols underpinning GAIN

Open Banking

The foundations for the remarkable global success of Open Banking over the past 5 years were laid by the creation and implementation of a set of internationally-agreed standards, interoperable protocols and financial-grade APIs. Open Banking enables Business-to-Customer relationships that allow authorised third party applications and services to securely access and process personal financial information maintained by the customer’s bank or other financial institution.

Development of these foundational building blocks has not stopped and the OpenID Foundation, with others, are forging ahead with a number of initiatives to enhance interoperability between global financial institutions. As a major player in GAIN, OIDF will be closely involved in the 2022 Proof of Concept, which is intended to demonstrate that these interoperability enhancements provide an effective, secure and global identity layer for the Internet.

Below is an illustration of how the OpenID Connect suite is underpinned by a range of protocols that together provide a stable and resilient security foundation.

OpenID Connect Protocol Suite, source OID.net

The following tables provide more detailed information about the specifications, standards, protocols and APIs that enable OpenID Connect and will provide enhanced interoperability within the GAIN ecosystem.

  1. Those standards and protocols that provide a secure and resilient underpinning for OIDC;
  2. Those specifications that deliver the complete OIDC capability; and
  3. Those specifications, protocols and APIs than improve interoperability.

Protocol

Developed by

Purpose

OAuth allows a User to grant access to their private resources on one site (which is called the Service Provider), to another site (called Consumer). While OpenID is all about using a single identity to sign into many sites, OAuth is about giving access to your resources without sharing your identity at all (or its secret parts).

JSON (JavaScript Object Notation) is an open standard file format and data interchange format that uses human-readable text to store and transmit data objects. Derived from JavaScript, it is a common language-independent data format with diverse uses in electronic data interchange, including that of web applications with servers.

JSON Web Tokens (JWT) is a compact claims representation format intended for space constrained environments such as HTTP Authorization headers and URI query parameters. JWTs encode claims to be transmitted as a JSON object that is used as the payload of a JWS structure or as the plaintext of a JWE structure, enabling claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.

JSON Web Signature (JWS) represents content secured with digital signatures or MACs using JSON based data structures that are encoded using base64url encoding.

JSON Web Encryption (JWE) represents encrypted content using JSON based data structures and provides cryptographic mechanisms that encrypt and provide integrity protection for an arbitrary sequence of octets.

A JSON Web Key (JWK) is a JSON data structure that represents a cryptographic key. This specification also defines a JSON Web Key Set (JWK Set), a JSON data structure that represents a set of JWKs.

 JSON Web Algorithms (JWA) registers a range of cryptographic algorithms and identifiers to be used with the JWS, JWE, and JWK specifications, including SHA-256/512, ECDSA & HMAC, as defined in NIST & FIPS documentation.

The WebFinger protocol is used to discover information about people or other entities on the Internet that are identified by a Uniform Resource Identifier using standard HTTP methods over a secure transport. A WebFinger resource returns a JSON object describing the entity that is queried, which is referred to as the JSON Resource Descriptor (JRD).

Table 1: Protocols that underpin OpenID Connect

Specification

Developed by

Purpose

OIDC Core

(Minimal implementation)


OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It enables Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.

Core OIDC functionality is authentication built on top of OAuth's authorisation and the use of Claims to communicate information about the End-User and the security and privacy considerations for using OIDC.

OIDC Core is the minimal implementation for certification; there are optional add-ons (below), depending on the use case.

OIDC Discovery (Optional)

This specification defines a mechanism for an OIDC Relying Party to discover the End-User's OID Provider (OP) and obtain information needed to interact with it, including its OAuth 2.0 endpoint locations.

In order for an OIDC Relying Party to utilize OIDC services for an End-User, the RP needs to know where the OID Provider is. OIDC uses WebFinger to locate the OID Provider for an End-User.

Once the OpenID Provider has been identified, the configuration information for that OP is retrieved as a JSON document, including its OAuth 2.0 endpoint locations.

In order for an OID Relying Party to utilize OIDC services for an End-User, the RP needs to register with the OID Provider (OP) to provide the OP information about itself and to obtain information needed to use it, including an OAuth 2.0 Client ID. This specification describes how an RP can register with an OP, and how registration information for the RP can be retrieved.

This specification complements the OIDC Core by defining how to monitor the End-User's login status at the OID Provider (OP) on an ongoing basis so that the Relying Party (RP) can log out an End-User who has logged out of the OP.

Both this specification and the OIDC Front-Channel Logout use front-channel communication, which communicate logout requests from the OP to RPs via the User Agent. In contrast, the OIDC Back-Channel Logout uses direct back-channel communication between the OP and RPs being logged out. The OIDC RP-Initiated Logout complements these specifications by defining a mechanism for a RP to request that an OP log out the End-User. 

This specification defines the Form Post Response Mode. In this mode, Authorization Response parameters are encoded as HTML form values that are auto-submitted in the User Agent, and thus are transmitted via the HTTP POST method to the Client, with the result parameters being encoded in the body using the application/x-www-form-urlencoded format.

Table 2: Listing of relevant OIDC specifications

Specification

Status

Developed by

Purpose

Financial-grade API 1.0

Published

Based on OAuth 2.0 and OpenID Connect suite of standards, but with less optionality and the requirement to use modern security best practices. Exhaustive conformance tests to allow implementers to ensure their software is secure and interoperable


Part 1: Baseline Security Profile

Part 2: Advanced Security Profile 

Financial-grade API 2.0

Implementer's draft

With a broader scope than v1.0 FAPI 2.0 aims for complete interoperability at the interface between client and authorization server as well as interoperable security mechanisms at the interface between client and resource server. It also has a more clearly defined attacker model to aid formal analysis, includes Baseline Security Profile & Attacker Model. Additional work by this WG includes FAPI2.0: Advanced Security Profile, Grant Management for OAuth 2.0 & Simple HTTP Message Integrity Protocol.

Implementer's draft

The iGov Working Group is developing a security and privacy profile of the OpenID Connect specifications that allow users to authenticate and share consented attribute information with public sector services across the globe. The resulting profile will enable standardized integration with public sector relying parties in multiple jurisdictions. The profile will be applicable to, but not exclusively targeted at, identity broker-based implementations.

Implementers draft

The eKYC and Identity Assurance (eKYC & IDA) WG is developing extensions to OIDC that will standardise the communication of assured identity information, i.e. verified claims and information about how the verification was done and how the respective claims are maintained.

The specification also defines flexible data schemas for request and response as well as communicating information relating to the assured identity data including:

  -  Which data are required
  -  How identity was verified
  -  Which entity performed the ID verification
  -  What evidence was presented
  -  When identity was verified
Planning is underway to add support for conditional claims and support for legal entity and delegated authority use cases. A major element of the WG's work is the development of interoperability between existing assurtance standards, such as NIST SP800-63-3, GPG45 and eIDAS.


Implementer's draft

MODRNA Authentication Profile 1.0 allows RPs to use high quality authentication methods, which can be provided by Mobile Network Operators (MNO). However a RP must be able to describe its demands for an authentication request and it must be able to do this in an interoperable way.

The Profile will specify how RP's request a certain level of assurance for the authentication. Additionally, it will specify an encrypted login hint token to allow for the transport of user identifiers to the OP in a privacy preserving fashion.

MODRNA will support GSMA technical development of Mobile Connect and enable Mobile Network Operators (MNOs) to become Identity Providers.

Implementer's draft

This specification extends OIDC with the concept of a Self-Issued OpenID Provider (Self-Issued OP), an OP which is within the End-User's local control. End-Users can leverage Self-Issued OPs to authenticate themselves and present claims directly to the RPs. This allows users to interact with RPs directly, without relying on third-party providers or requiring the End-User to operate their own hosted OP infrastructure.

Implementer's draft

This specification extends OIDC with support for presentation of claims via W3C Verifiable Credentials. This allows existing OpenID Connect RPs to extend their reach towards claims sources asserting claims in this format. It also allows new applications built using Verifiable Credentials to utilize OpenID Connect as integration and interoperability layer towards credential holders.

Verifiable Presentations are used to present claims along with cryptographic proofs of the link between presenter and subject of the verifiable credentials it contains.

Table 3: OIDC specifications in development

With its huge ‘install base’, OIDC is already used by millions of websites for user authorisation & authentication at the “front door”. Indeed, while a vanishingly small portion of internet users have ever heard of OIDC, it is the nuts and bolts of the most universal and familiar user flow of the contemporary commercial web, including online banking and government services.

The latest development of OIDC– Self Issued OIDC Provider, enables greater integration between OIDC and the W3C DID standard and seeks to address the problem of achieving critical mass in 3 areas – users/holders, IDPs/Issuers and RPs/Verifiers.

The vision of DID-SIOP is a way of bringing decentralised identity concepts into alignment with the ideas of “self-issued” portable identity that the original OpenID innovators had. 

Posted on

So, what has Decentralised Identity go to do with GAIN?

In order to answer that question we need to look a little more deeply at the various terms that make up the definition of Decentralized Identity.

“A globally unique persistent identifier that does not require a centralized registration authority and is often generated and/or registered cryptographically.“

“Globally” 

The GAIN proposal seeks to create a global community of trusted Identity Providers that will work together to implement an comprehensive identity overlay to the Internet. By founding the GAIN identity community on the existing global finance and payments ecosystem a solid and reliable basis for identity validation and verification is established.

Given that banks and international financial institutions have global reach, already operate a secure system (international payments) and are required to comply with worldwide Anti Money Laundering legislation, it is clear that they already possess many of the required building blocks for an interoperable international identity ecosystem.

As it expands, GAIN will increase decentralization by recruiting other international and national organisations that currently have a role as Identity Providers – internet, mobile and health service providers, universities, professional bodies, employers of all sorts and online shopping, to mention just a few. Last but not least, GAIN’s security profile is capable of providing sufficient assurance to enable governmental service providers to join, should they so wish.

“Unique” 

In our daily life we are completely dependent on unique identifiers in a variety of different contexts – telephone numbers, email addresses, passport numbers, National Insurance Number, driving licence number, employee number, product serial numbers, web page locators, username and password etc. Each of these identifiers needs to be unique within its’ own context so that, for example, my phone number cannot be allocated to anyone else but the same digits in the same order could actually be the serial number for a piece of equipment I own.

Currently, all identifiers are issued by ‘someone else’ and none are currently under my control; the identifiers can expire, be revoked or compromised, as was the case of my username and password being made available toscammersfollowingthe2012 security breach at LinkedIn.

The use of existing standards, protocols and APIs alongside improvements in encryption techniques now means it is possible to cryptographically prove the ‘uniqueness’ and ‘ownership’ of an identifier.

“Persistent identifier” 

A decentralized identifier not only needs to be valid and available throughout an individual’s lifespan, but it also needs to remain valid and resolvable after their death.

In many ways this is similar to the current banking requirement for account and transaction audit, however, in the future, a similar level of audit will be required for livestock, land, companies, devices and web resources, in fact anything else that needs to be identifiable long after death, upgrade or replacement.

“Does not require a centralized registration authority” 

Following the success of corporate Single Sign On, federated identity started to catch on in the consumer Internet, where it led to the introduction of ‘social’ login buttons on consumer-facing websites, such as those below.

Source: Self-Sovereign Identity 2021 

Each of these service providers was, effectively, operating as self-appointed Identity Providers with the capability of verifying the identities of individual account holders. For a number of reasons ‘social’ logins have, perhaps fortunately, failed to provide the Internet’s missing identity layer:

  • There isn’t one IDP that works with all sites, services, and apps, so users need accounts with multiple IDPs.
  • Because they need to serve so many different sites, IDPs must employ “lowest common denominator” security and privacy policies.
  • Many users—and many sites—are uncomfortable with having a “man in the middle” of all their relationships that is capable of correlating a user’s login activity across multiple sites.
  • Large IDPs represent some of the biggest honeypots for cybercrime.
  • IDP accounts are no more portable than centralized identity accounts. If you leave an IDP like Google, Facebook or Twitter, all those account logins are lost.
  • Lastly, due to security and privacy concerns, IDPs are not in a position to help us securely share some of our most valuable personal data, e.g., passports, government identifiers, health data, financial data, etc.

“Generated and/or registered cryptographically.” 

The DID standard requires the identifier be capable of cryptographically authenticating the DID Controller, who may well be, but not necessarily is, the subject of the DID. Cryptographic authentication enables an identity holder to prove who they are by demonstrating they have control of the private key bound to the identifier. Such a requirement is fulfilled by the implementation of a global decentralized public key infrastructure (DPKI), which has significant security and privacy benefits for the Internet, as a whole.

Initially the GAIN Proof of Concept, will make use of the OpenID Connect (OIDC) protocol that relies on transport layer encryption but does not, in or of itself, enable cryptographic verification of any identity information obtained by a Relying Party (RP). Further posts will explore the integration between OIDC and DID to further improve cryptographic authentication and verification.

Source developer.orange.com 

Posted on

Decentralised Identity

“A globally unique persistent identifier that does not require a centralized registration authority and is often generated and/or registered cryptographically. … A specific DID scheme is defined in a DID method specification. Many—but not all—DID methods make use of distributed ledger technology (DLT) or some other form of decentralized network.”

Decentralized Identifiers (DIDs) v1.0

By making use of the existing Internet layer for financial transactions, with its thousands of participating institutions, GAIN has the potential to deliver a decentralised identity ecosystem that offers significant benefits for those financial institutions.

  • Turning a cost-centre (KYC processes and systems) into a potential profit-centre (offering Identity Provider services);
  • Simplifying processes, such as customer onboarding, login and password recovery;
  • Enabling cross-border platforms that facilitate scale;
  • Removing barriers (e.g., data sharing within and between institutions);
  • Moving towards comparative legal and regulatory structures that will serve to expand the total opportunity.; and
  • Re-using existing interoperable protocols, such as OpenID Connect and those APIs supporting Open Banking.

Critical developments in decentralised identity

The mission of the W3C’s Decentralized Identifier Working Group is to standardize the DID Unique Resource Identifier (URI) scheme, which includes the data model and syntax of DID Documents and DID Methods. The purpose of the DID document is to describe the public keys, authentication protocols, and service endpoints necessary to bootstrap cryptographically-verifiable interactions with the identified entity. The DID Method specification defines how a DID and DID document are created, resolved, and managed on a specific blockchain or “target system” and also defines, as a minimum, the Create, Read, Update, Delete operations for the DID.

Formed in 2017, the Decentralized Identity Foundation (DIF) promotes the interests of the decentralized identity community, including performing research and development to advance “pre-competitive” technical foundations towards established interoperable, global standards. DIF maintains an incredibly useful general-purpose knowledgebase, in the form of FAQs.

Originally proposed in 2015 the DID model was updated to include significant developments in distributed databases, cryptography and decentralized networks. This work led to the creation of another fundamental standard – Verifiable Credentials (VC) that together with the DID specification became the underpinning standards for Self-Sovereign Identity (SSI).

Self Sovereign Identity

See my previous post “Federated vs Self Sovereign Identity” to find out more about the fundamentals of SSI and the way in which it differs from Federated Identity.

The definition of SSI – “a person’s identity that is neither dependent on nor subject to any other power or state”, has given rise to two myths about SSI, which have, to some degree, cast a cloud over the adoption of the term.

  1. Self-sovereign identity is not ‘self-asserted identity’, it is just as dependent on information provided by trusted sources as one’s identity is in the real world e.g. the issue of a ;physical passport.
  2. Self-sovereign identity is not ‘just for people’, it is equally applicable to organisations and things.

More recently the term decentralised identity has made something of a resurgence with Microsoft throwing it’s considerable weight behind the term in this recent blog post.

Objections to Decentralised Identity

In October 2021, Google, Apple and Mozilla lodged formal objections to W3C approval of the Decentralized Identifiers (DIDs) 1.0 specification; the substance of which relates to concerns over

  • Interoperability,
  • Divergence rather than convergence of DID methods,
  • Centralized DID methods are not excluded, and
  • The impact on the environment by the reliance on blockchain.

Discussions continue and we all look forward to an early resolution of the issues raised.

Posted on

GAIN – Background

According to the late, lamented, Kim Cameron in his seminal 2005 blog, The Laws of Identity, the Internet was designed and implemented without an identity layer and has developed ever since as a patchwork of identity workarounds and one-offs.

In the November 2019 BBC Dimbleby Lecture, Tim Berners Lee, inventor of the World Wide Web, proposed a mid-course correction for the Web by decoupling data from the application. This, he argued, would give users complete control of their personal data and enable them to make use of decentralized data stores called Pods, developed using the Solid specification.

The GAIN (Global Assured Identity Network) proposal has the potential to deliver both an identity layer for the Internet and this mid-course correction. GAIN addresses the patchwork of identity workarounds and implements a global identity system that enables a shift towards a user-centric and high-trust identity paradigm for the Internet.

The genesis of GAIN

GAIN builds on the remarkable success of the worldwide payments’ ecosystem, implemented by the international financial community and delivering global payments schemes such as Swift, Mastercard and Visa. This financial ecosystem is based on open standards and financial-grade APIs; it can be envisioned as a financial overlay to the Internet.

Trust in the international payments system is underpinned by formal compliance with international banking regulation, such as Sarbanes-Oxley, the Basel Framework, ‘Know Your Customer’ (KYC), Anti-Money Laundering (AML) legislation and PCI-DSS. Financial institutions that are members of the international payments’ ecosystem must provide evidence of:

  • implementing all the required technical controls;
  • applying the rules of the various compliance schemes; and
  • submitting themselves to a process of regular certification.

Membership, technical controls, scheme rules and regular certification are just four of the methods by which trust is maintained between members of the payments’ ecosystem and between financial institutions and their customers. In effect, financial institutions are already required to operate within a global financial payments Trust Framework.

Islands of trust exist GAIN is an interoperable system bridging islands

By catalysing a decentralised and interoperable global network, as has been achieved for payments, Financial Institutions will offer high-trust identity assurance within a safe, sufficiently regulated environment: a major step toward Digital Trust.

GAIN DIGITAL TRUST White Paper
Proudly powered by WordPress