FIWARE Lab, a service platform based on a large distributed OpenStack environ...FIWARE
'FIWARE Lab, a service platform based on a large distributed OpenStack environment'.
Presentation (in Japanese) by Stefano De Panfilis, FIWARE Foundation COO.
Shown at the OpenStack Days in Tokyo (20/07/2017)
FAPI / Open Banking Test Suite #fapisum - Japan/UK Open Banking and APIs Summ...FinTechLabs.io
This document describes a test suite for OAuth and OpenID Connect protocols. It discusses the need for conformance testing to ensure interoperability between authorization servers, clients, and protected resources. The test suite is designed to test the protocols in a multi-party manner using a structured configuration, logging, and modular execution units. It aims to test both normal and error cases to avoid a false sense of security from only testing happy paths. The architecture involves conditions, modules, plans, environments, and logging to API endpoints. The goal is to make the testing fully scriptable and transparent.
Trust Frameworks and Open Banking #fapisum - Japan/UK Open Banking and APIs S...FinTechLabs.io
RAiDiAM is a consulting firm focused on identity and regulatory challenges posed by open banking and PSD2. It provides business and technical consulting services using a modular and scalable identity architecture. RAiDiAM has experience delivering services to open banking organizations, financial institutions, and software vendors. The document discusses the changing landscape in financial services due to open banking and data privacy regulations in Europe and globally. It outlines the various actors in the ecosystem and proposes a trust framework using a hub-and-spoke topology to help establish identity and authorization between parties. The Open Banking Implementation Entity in the UK established a trust framework and directory based on this approach to facilitate standard interfaces and integration between authorized banks and third parties.
Issues towards Open Banking ecosystem and how OpenID Foundation tackles them ...FinTechLabs.io
The document discusses the work of the OpenID Foundation Financial API working group (FAPI WG) to develop standards for financial-grade APIs. It describes how the FAPI WG was formed in 2016 to address the lack of API protection standards and inconsistent request/response formats. The goal of the FAPI WG is to provide JSON schemas, REST specifications, and security recommendations to enable applications to access and interact with user financial data while protecting privacy and security. The document outlines the FAPI WG's draft specifications and approaches to address password sharing requirements in a way that does not compromise user security or privacy.
Open Banking: Lessons from the UK #fapisum - Japan/UK Open Banking and APIs S...FinTechLabs.io
The document discusses the implementation of Open Banking in the UK by the Open Banking Implementation Entity (OBIE). It provides the following key details:
- OBIE was set up by the UK Competition and Markets Authority (CMA) in 2016 to deliver the Open Banking API standards and ensure consistent implementation.
- OBIE has created standards for identity, reference data, APIs, and security to enable the development of an Open Banking ecosystem in the UK.
- The timeline for the rollout of the OBIE's Open Banking API specifications includes four versions, with the full scope of payments services to be included in version 3 from 2019.
- Challenges in implementation have included varying
FAPI / Open Banking Conformance #fapisum - Japan/UK Open Banking and APIs Sum...FinTechLabs.io
The document discusses FAPI/Open Banking conformance testing. It provides an overview of the conformance suite, including what it tests and its design goals. It then describes the test process for banks, demonstrates the conformance suite, and provides tips for successful FAPI deployment, including common problems banks faced in the UK and advice for running conformance testing early in development.
The Great British API Client Bake Off #fapisum - Japan/UK Open Banking and AP...FinTechLabs.io
This document discusses the author's experience building an integration with the UK's Open Banking Directory as the CTO of Moneyhub. It provides background on the author and Moneyhub, an overview of their road to using Open Banking APIs after previously screen scraping, details on onboarding to the Directory, how they built their integration using OpenID Connect and separating by financial institution, and lessons learned around the importance of verifiable conformance and not assuming banks have automated testing.
Authlete FAPI Implementation Part 1 #fapisum - Japan/UK Open Banking and APIs...FinTechLabs.io
This document discusses Authlete's semi-hosted approach to OAuth and API security. Authlete provides an API that customers can call from their own OAuth-speaking services to handle OAuth processing and management. The API allows customers to add new features to their services over time, such as PKCE, and supports various client authentication methods including mutual TLS with certificates. For mutual TLS, the customer validates the TLS connection but Authlete verifies the certificate to act as a trust anchor.
Open Banking UK “Identity Product” Internals #fapisum - Japan/UK Open Banking...FinTechLabs.io
The document discusses RAiDiAM and its Open Banking Identity product. It summarizes:
- RAiDiAM was created to help with identity challenges of Open Banking and PSD2 regulations. It provides consulting and modular/scalable identity architecture services.
- The Open Banking Directory was developed as a trust framework "hub" to enable secure transactions between authorized financial companies using standards like OAuth2 and OIDC.
- It describes the Directory's key components, onboarding process to issue credentials to companies, and role in later transactions to validate claims between financial entities.
Open Banking for Developers #fapisum - Japan/UK Open Banking and APIs Summit ...FinTechLabs.io
The document discusses Open Banking in the UK and the role of the Open Banking Implementation Entity (OBIE). OBIE was set up by the UK Competition and Markets Authority (CMA) to deliver the Open Banking API standards and security architecture. OBIE is working to create standards around identity, reference data, APIs, and security to build an ecosystem for developers and ensure consistent implementation across the largest UK banks. The presentation outlines Open Banking's timeline and versions, how the API flows work, and how developers can access specifications and test facilities.
26. 仕様書 省略形 名称
RFC 7515 JWS JSON Web Signature
RFC 7516 JWE JSON Web Encryption
RFC 7517 JWK JSON Web Key
RFC 7518 JWA JSON Web Algorithms
RFC 7519 JWT JSON Web Token
『Special European Identity Award for Best Innovation for Security in the API Economy』
(European Identity Award - API エコノミーと最高のセキュリティ・イノベーション特別賞)
2014 年、
受賞
36. 識別子 (alg) アルゴリズム
RSA1_5 RSAES-PKCS1-v1_5
RSA-OAEP RSAES OAEP using default parameters
RSA-OAEP-256 RSAES OAEP using SHA-256 and MGF1 with SHA-256
A128KW AES Key Wrap with default initial value using 128-bit key
A192KW AES Key Wrap with default initial value using 192-bit key
A256KW AES Key Wrap with default initial value using 256-bit key
dir Direct use of a shared symmetric key as the CEK (Content Encryption Key)
ECDH-ES Elliptic Curve Diffie-Hellman Ephemeral Static key agreement using Concat KDF
ECDH-ES+A128KW ECDH-ES using Concat KDF and CEK wrapped with “A128KW”
ECDH-ES+A192KW ECDH-ES using Concat KDF and CEK wrapped with “A192KW”
ECDH-ES+A256KW ECDH-ES using Concat KDF and CEK wrapped with “A256KW”
A128GCMKW Key wrapping with AES GCM using 128-bit key
A192GCMKW Key wrapping with AES GCM using 192-bit key
A256GCMKW Key wrapping with AES GCM using 256-bit key
PBES2-HS256+A128KW PBES2 with HMAC SHA-256 and “A128KW” wrapping
PBES2-HS384+A192KW PBES2 with HMAC SHA-384 and “A192KW” wrapping
PBES2-HS512+A256KW PBES2 with HMAC SHA-512 and “A256KW” wrapping
共有鍵暗号化のアルゴリズム(RFC 7518, 4.1.)
37. 平文暗号化のアルゴリズム(RFC 7518, 5.1.)
識別子 (enc) アルゴリズム
A128CBC-HS256 AES using 128-bit IV and SHA-256
A192CBC-HS384 AES using 192-bit IV and SHA-384
A256CBC-HS512 AES using 256-bit IV and SHA-512
A128GCM AES GCM using 128-bit key
A192GCM AES GCM using 192-bit key
A256GCM AES GCM using 256-bit key
38. 読み方
The suggested pronunciation of JWT is the same as
the English word "jot".
JWT JSON Web Token
RFC 7519, Introduction
JWTとは?
JSON 形式で表現されたクレーム (claim) の
集合を JWS もしくは JWE に埋め込んだもの
→ ジョット
43. OpenID Connect Core 1.0, “2. ID Token”
ID Tokens MUST be signed using JWS and optionally both
signed and then encrypted using JWS and JWE respectively,
thereby providing authentication,integrity, non-
repudiation, and optionally, confidentiality, per Section
16.14. If the ID Token is encrypted, it MUST be signed then
encrypted, with the result being a Nested JWT, as defined
in JWT.
署名 必須
暗号化
任意。但し暗号化の際は「署名後に暗号化」
という順番が必須。
ID トークンには RFC 7519(JWT)より強い制限がかかる
45. RFC 7519, “4.1. Registered Claim Names”
クレーム名 意味 説明
iss issuer 発行者
sub subject 主体識別子
aud audience 利用者
exp expiration time 有効期限終了時刻
nbf not before 有効期限開始時刻
iat issued at 発行時刻
jti JWT ID JWT ID
48. OpenID Connect Core 1.0, “2. ID Token”
クレーム名 説明
iss ID トークン発行者(OpenID プロバイダー識別子)
sub 認証されたユーザーの一意識別子
aud 想定する ID トークン利用者(クライアント ID)
exp 有効期限終了時刻
iat ID トークン発行時刻
auth_time ユーザーが認証された時刻
nonce リプレイアタックを防ぐためのランダム文字列
acr ユーザー認証が満した認証コンテキストクラス
amr ユーザー認証方法
azp 承認された ID トークン発行対象
49. OpenID Connect Core 1.0, “5.1. Standard Claims” (1/2)
クレーム名 説明
sub ユーザーの一意識別子
name フルネーム
given_name 名
family_name 姓
middle_name ミドルネーム
nickname ニックネーム
preferred_username 好みのユーザー名
profile プロフィールページの URL
picture プロフィール画像の URL
website Web サイトやブログの URL