OpenID Foundation Workshop for the GSMA
65
1 OpenID Foundation Workshop for the GSMA
Transcript of OpenID Foundation Workshop for the GSMA
1
OpenID Foundation Workshop for the GSMA
Agenda 3:00 to 3:10pm CET
Introduction by Workshop Hosts Gautam Hazarii, Helene Vigue – GSMA Dawid Wroblewski – Deutsche Telekom, Chair IDG Bjorn Hjelm - Vice-Chair OpenID Foundation
3:10-3:30 Convergence of Traditional & New Identity Paradigms
Gail Hodges - Executive Director, OpenID Foundation
3:30-3:50 OpenID Foundation MODRNA Standard • Objectives, MNO Use cases • Standard review, Current discussions/ links to GSMA work • How to join
Bjorn Hjelm - Vice-Chair OpenID Foundation
3:50-4:30 OpenID Connect for Identity Assurance • Objectives, MNO Use cases • Standard review • Reference implementation: (yes.com) • Global Assured Identity Whitepaper
Mark Haine -- Considrd Consulting & Co-chair eKYC & IDA WG To join POC: [email protected]
4:30-4:40pm Break 4:40-5:00 OpenID Connect Grant Management
• Objective: consent management • Use cases • Standard review
Dima Postnikov – Principal Identity Architect & OIDF Contributor
5:00-5:20 Shared Signals & Events • Objectives, MNO Use cases • Standard review • Reference implementation
Atul Tulshibagwale -- Google & Co-chair Shared Signals and Events WG
5:20-5:40 Open Banking & Open Data and the Financial-Grade API Security Profile • Open Banking/Data Regulation & MNO implications • FAPI as dominant security profile standard • Use cases (UK, Brazil, Australia)
Joseph Heenan – Authlete & OIDF Certification Program & Contributor
5:40-6:00pm Call to Action Questions & Wrap
Helene Vigue, Gautam Hazari, Dawid Wroblewski Bjorn Hjelm, Gail Hodges
OpenID Foundation Overview Bjorn Hjelm – Vice Chair OpenID Foundation
What is the OpenID Foundation? § Non-profit open standards body focused on identity infrastructure enables billions of
transactions per day
§ Global adoption includes:
o OpenID Connect – Verify a user and get basic user profile information to a relying party. • Wide application: web & mobile, enterprise & consumer, on prem & cloud, federated
vs user, basic claims & multiple claims • Android, Apple, AOL, Deutsche Telekom, Google, GSMA Mobile Connect, KDDI,
Microsoft, NEC, NTT, Orange, Salesforce, Softbank, Symantec, Telefónica, Verizon, Yahoo! Japan
o FAPI – A security profile for APIs to authenticate the sender, receiver, user, message while retaining confidentiality and averting phishing and replay attacks.
• Open Banking (UK, Australia, Brazil, US/Canada, Russia) • Applicable across verticals, facilitates global interoperation
What OpenID Standards can do for you
1. MNO as an Identity Service Provider
3. MNOs that want to Share Signals
2. MNO that wants to Verify Attributes
4. MNO as a Relying Party to Third Party Identity
Services
6. MNO Identity Services for Employees, Systems, &
Things
5. MNO that need to Conform to Open Banking
(Data) Regulations
Each MNO will think strategically whether to engage in (1)-(3), and how they can optimize their investments in (4)-(6)
MNO use cases that use OIDF Standards
Convergence of Traditional & New Identity Paradigms Gail Hodges – Executive Director OpenID Foundation
Convergence of Traditional & New Identity Paradigms
Physical Documents
Digital Documents
Today
Government Issued
Data Bureaus KYC/IDA Services
Private Services
Internet / Standards
Digital Platforms
Login Proliferation
Federated Identity
Standards
Assured Identity Standards
Open Banking
Open Finance/ Open Data
Wallets / Crypto Digital Wallets
Bitcoin Blockchain Verifiable
Credentials
Digital Wallets
Financial Services New / Remote Account Opening
Identity Layers Emerging
The <untrusted> Internet
Interoperable + Security Model
OpenID Connect (Billions users, millions apps)
Verifiable Credential + Blockchain Installed Base
(~100m users, 10k apps)
Dominant standard?
Multi-lingual, Interoperable End-game
Why?
What action MNOs may want
to take now…
§ A question of timing, not if multiple identity technologies will coexist. They may be interoperable to some degree, but many ecosystem participants will speak more than one “language.”
§ These services will redefine how users and businesses consume your services, and how you operate those services. Global interoperability is required, but likely to move through national/regional steps first.
§ Some advantage to solutions with mature standards, security models, and installed base of users (e.g. OIDC known to developers, drivers license/mDL understood by users, RPs and policy makers)
§ New technologies with emerging standards (e.g. verifiable credentials linked to blockchain services) may benefit from policy support, digital platform support, links to crypto/ wallets.
§ Participate in standards/ policy WGs to help build identity infrastructure foundations society & economy need § Test and learn e.g. GAIN POC hosted by OIDF; ISO 18013-5 mDL interop tests, etc.
§ Bring internal teams, executives up the learning curve to inform strategic decisions, resource investments
§ Help educate, inform policymakers on landscape
OpenID Foundation MODRNA Standard Bjorn Hjelm – Vice Chair OpenID Foundation
Purpose § Support GSMA technical development of Mobile Connect and similar
industry and standards development. § Enable Mobile Network Operators (MNOs) to become Identity Providers. § Developing (1) a profile of and (2) an extension to OpenID Connect for use
by MNOs providing identity services.
Participants and Contributors
WG Status § Approved CIBA Core
specification for Final Publication.
§ Three specifications in Implementer’s Draft status. o Authentication Profile,
Account Porting, User Questioning API.
§ Preparing MODRNA CIBA Profile specification for Implementer’s Draft.
§ Advancing remaining draft specifications towards Implementer’s Draft. o Discovery Profile and
Registration Profile. § Receiving feedback from
deployments in Europe and USA. § Planning for OpenID Certification
of several profile specifications. More information available at https://openid.net/wg/mobile/status/
MODRNA WGCollaborations and Outreach
1
2
3
Evolution of Mobile Connect architecture, functionality and identity services.
RCS (Rich Communications Services) services and MaaP support for OpenID Connect.
Configuration of device-based services with embedded SIM (ODSA, C-V2X) leveraging OpenID Connect for authentication.
3GPP Mission Critical Services 3GPP (Third Generation Partnership Project) Mission Critical (MC) services support PSA (Public Safety Agencies) and other critical communications.
Identity management is part of MC system security architecture and OpenID Connect MCX Profile defined for user authentication.
Development of SEAL (Service Enabler Architecture Layer) to support vertical applications (such as V2X) services is based on MC architecture.
Identity Management is a common capability supporting mission critical and other vertical applications.
MNO as an Identity Service Provider
MNO Best Fit Live Examples OIDF Standards
MNO services central to user’s digital life q Trusted brand q Pervasive use of services through
the MNO (e.g. payment, social media platforms)
q User sees Identity service as a natural extension
q Relying parties see MNO as a natural identity service provider
OpenID Connect + MODRNA q Three party model: MNO, User,
and Relying party, requires secure and federated exchange of identity data
q MNO specific requirements addressed in MODRNA spec
q CIBA protocol allows relying parties to exchange data direct with Identity Service provider without browser redirects
q Certification available
ZenKey q Verizon, T-Mobile, AT&T joint entity
offering identity services to relying parties
q Case study in OIDF Workshop
MNO offers user Identity Service (usually $0) and offers identity service to relying parties (usually $).
OpenID Connect for Identity Assurance Mark Haine – Considrd Consulting & Co-chair eKYC & IDA WG
OpenID Connect for Identity Assurance What is the business case?
§ Reduced friction and cost by lowering the number of validation & verification processes an end user needs to perform
§ Fewer credentials for consumers to manage
§ Data minimization for Relying Parties who are able to specify which information they need for their use case
OpenID Connect for Identity AssuranceUse Cases Presenting Digital Identity whenever the level of assurance needs to be clear § Opening an account § Account recovery § Staff onboarding § Accessing restricted services
o Government o Night Club o Alcohol/tobacco o Healthcare o etc.
§ MNO as ID Provider o Number Porting o Access other services
§ MNO as Relying Party
o Buy a SIM o Number Porting o Consumer Login o Account recovery
Open ID Connect
What is “OpenID Connect”?
A Signed Claims Passing Protocol with added verification metadata
Claims: Alice Mirror DOB: Jan 1 1970 Verified by whom Verified How Verified When Evidence Used
What is “OpenID Connect for Identity Assurance”?
OpenID for Identity Assurance flow
1. Initial consumer interaction with RP 2. RP asks IDP for specific information 3. IDP Authenticates consumer 4. IDP gets authorization to share data 5. IDP provides data to RP 6. RP provides service to consumer
Request D
ata
OpenID for IDA Response example { "verified_claims": {
"verification": { "trust_framework": "phonia_tf", "assurance_level": "substantial", "time": "2021-05-11T14:29Z", "txn": "85r3ds3254120132",
"evidence": [ { "type": "document",
"validation_method": { "type": "vri"
}, "time": "2021-04-09T14:12Z", "document_details": {
"type": "driving_permit", "date_of_expiry": "2030-12-31" }
}, { "type": "electronic_record",
"txn": "71662937582385239", "verifier": {
"organization": "Phonia" }, "procedure": "subscription_data", "score": {
"number_type": "Mobile", "blocked": false, "last_sim_swap": "2018-05-11T11:02Z", "risk_score": "low"
} } ] } }, "claims": {
"msisdn": "919825098250", "given_name": "Sarah", "family_name": "Meredyth", "address": {
"postal_code": "EH1 9GP", "country": "UK", "street_address": "122 Burns Crescent"
} } }
Link to policy domain
Transaction
Driving License document details
- verified remotely
Phone subscription information - from electronic records
Verified digital identity claims
OpenID Connect for Identity AssuranceStatus § Implementers draft 3 was recently approved § Heading to ‘final’ next § Interoperability testing event underway § Beta version of Conformance testing tool well underway § 2 production services exist today others are in progress
§ Additional features will be delivered through other drafts and profiles
§ Advanced Syntax for claims § Selective abort/omit § OpenID for Authority
§ Profiles for specific assurance standards e.g. o NIST 800-63-3 o GPG45
Global Assurance Identity Network (GAIN) Overview Dr. Torsten Lodderstedt – yes.com & Co-Chair GAIN POC
Global Assured Identity Whitepaper (GAIN) A blueprint of the business, legal and technical components needed for digital identities to be internationally interoperable. § Focused on international interoperability § Pragmatic not dogmatic § Technology agnostic § Based on open standards § Internet scale
No new standards or standards
organizations were proposed
https://xkcd.com/927/
The GAIN hypothesis for global interoperability
§ Financial crimes cost 5% global GDP
§ Those with resources benefit from anonymity
§ Everyone else is pervasively tracked, or worse, unable to participate in formal economy
The image part with relationship ID rId4 was not found in
Interoperability
GAIN Vision
The <untrusted> Internet
Trusted Networks
Islands of trust exist; GAIN is an interoperable system bridging islands
The crowdsourced paper simply suggests a start– and the means to catalyze the global community to action.
-
Identity Providers (IDPs) § Connect their own claim sources to
OpenID Connect 4 Identity Assurance API § Deliver verified user claims with the user’s
consent to RPs § OIDC for Identity Assurance certification
tests available § Natural role for banks and other regulated
entities with existing KYC infrastructure Relying Parties (RPs)
§ Use ‘IDP Chooser’ § Request and receive verified user claims
from the user selected IDP, option to request FIDO/WebAuthN authenticators
§ OIDC for Identity Assurance certification tests available to simplify interoperability
GAIN POC uses OpenID for Identity Assurance
§ OIX: rules and governance required for legal, operational and identity assurance interoperability.
§ OIDF: The new POC Community Group testing technical approaches in an open and collaborative environment.
§ CSC: cloud electronic signature standards
§ GLEIF: legal entities standards
§ IIF: network of financial services leaders
§ Other non-profits: encouraged to join
OIDF
OIX
GAIN Forum
GAIN brings together non-profits to deliver this vision
IIF CSC
Global Interoperability WG
GAIN Community Group POC
GAIN Roadmap
Time Q4 2021 Q1 2022 Q2 2022 Q3 2022 Q4 2022
Alpha POC
OIDF Working Groups
Trust Conference
‘GAIN’ Network Operational establishment >>> Commercial initiation
Participation Agreement
Contribution Agreement
Participation Agreement
Certification & Conformance
Requirements Gathering
Contract Development
Global Interoperability Requirements
Assurance Level Mapping
Trustmark
Principles
Governance
Legal & Regulatory
Scheme Requirements
Roles
OIX Guide to Trust Frameworks § Trust frameworks are complex
§ We must ‘slice the elephant’
§ Decide which areas are key for interoperability across frameworks
§ The OIX Global Interoperability Working Group will explore the requirements to define a Global Interoperability Framework
Break
OpenID Connect Grant Management Dima Postnikov – Principal Identity Architect & OIDF Contributor
Grant Management A complete security protocol requires a holistic consent management Modules: § Specify authorization (including fine grained)
o Rich Authorization Requests (https://tools.ietf.org/html/draft-ietf-oauth-rar)
§ Management of consents o Grant Management (https://bitbucket.org/openid/fapi/src/master/
Financial_API_Grant_Management.md)
§ Client awareness for complex approval processes (e.g. every data provider needs to approve) o Extension to Grant Management
Grant Management
Grant Management – why? Authorisation == Grant (in OAuth terminology) Grant:
§ the set of permissions confirmed by the owner of services or data for a certain client
§ AS issues access tokens (and refresh token) based on the grant Grant lifecycle managed by the AS only in traditional OAuth Several Open Banking initiatives (e.g. UK, BG, FDX, CDR) require grant management capabilities for clients/data recipients/tpps Use Cases
§ Establish concurrent grants § Update existing grants § Revoke grants
Grant Management – scope
§ Support concurrent, independent grants
§ Support update of grants
§ Make grant (status) accessible and manageable by clients
Grant Management
Grant Management – scope
Grant Management - example POST /token HTTP/1.1Host: www.holder.com.auContent-Type: application/x-www-form-urlencodedgrant_type=authorization_code&code=i1WsRn1uB1&code_verifier=iWsBrn1uBR&client_id=s6BhdRkqt3&HTTP/1.1 200 OKContent-Type: application/jsonCache-Control: no-cache, no-store{{
"access_token": "2YotnFZFEjr1zCsicMWpAA……..", "token_type": "bearer", "expires_in": 3600, "refresh_token": "tGzv3JOkF0XG5Qx2TlKWIA…..", "refresh_token_expires_at": "1311281970", "grant_id":"TSdqirmAxDa0_-DB_1bASQ"
}}# Decoded JWT{ "iss": "https://www.holder.com.au", "sub": "a9ebbef6-1f0b-44eb-96cf-0c5b51b37ab2", "aud": "a7AfcPcsl2", "exp": 1311281970, "scope": "openid bank:accounts.basic:read", "authorization_details": [ { "type": "cdr_sharing_v1", "sharing_duration": 7776000, "actions": [ "bank:accounts", "basic:read" ], "sharing_expires_at": 1311281970, "sharing_status": "ACTIVE" } ]}
Grant Management – part of FAPI 2 Framework
Grant Management - status
§ September 2021 – Implementer’s draft 1 has been approved by OIDF
§ Implementers have started development
§ December 2021 – Implementer’s draft 2 to be published for review and approval
Shared Signals & Events Atul Tulshibagwale -- Google & Co-chair Shared Signals and Events WG
Shared Signals & Events
§ Secure, privacy protecting framework for webhooks o Shared subject identifiers o Asynchronous publish and subscribe model o Stream management
§ Two current applications:
o Zero-Trust: Continuous Access Evaluation Protocol (CAEP) o Account Security: Risk Incident Sharing and Coordination (RISC)
§ Active participants: Google, Microsoft, AWS, Cisco, SailPoint, Thales and others
Google Cross Account Protection Service ❑ RISC events about Google Sign-In
users ❑ Millions of events per day to hundreds
of thousands of relying parties Microsoft Continuous Access Evaluation ❑ CAEP-like events between Azure AD,
Microsoft Teams and Exchange Online
MNO Best Fit Live Examples OIDF Standards
MNOs with sophisticated fraud teams ❑ MNOs that see the inherent value
in sharing data to fight cybercrime ❑ MNOs with the technical ability to
generate and exchange signals with selected partners
❑ Reduce the cost of ownership for risk data previously only generated and consumed in house (e.g. Sim swap, phone number change)
❑ Strengthening identity services for ecosystem as a whole
Shared Signals & Events
❑ Two party: Entity 1 & Entity 2 that mutually agree to share data, using standards that allows interoperability with other parties technically
❑ Standard is extensible to a wide range of ecosystem participants (e.g. digital platforms, banks, MNOs)
MNO that sees the value in sharing data with trusted 3rd parties to jointly (and collectively) mitigate fraud
Status and Next Steps: Shared Signals and Events
§ Current Status o Open Source library available today from SailPoint enables
encoding and decoding SSE events o SSE and CAEP Implementer’s Drafts approved by OIDF
§ Next Steps
o More companies working on production implementations o Working on improvements to Stream Management aspects of the
SSE Framework o Exploring open source Transmitter and Receiver implementations o RISC spec being revised for Implementer’s Draft review
Open Banking & Open Data and the Financial-Grade API Security Profile Joseph Heenan – Authlete, OIDF Certification Team & Contributor
FAPI: Financial-grade API
FinancialGeneral-Purpose High-Security API Protection Protocol based on OAuth 2.0 family of specifications.
FAPI Working Group Founded in June 2016 § Originally targeted financial use-cases § Strong support to generalise the profile so that it can be used in other
markets such as healthcare, telecommunications, utilities, transportation and others – “open data”.
§ Financial-grade API (FAPI) security profile ← Note the insertion. § FAPI is for everybody that needs to be secure
o Designed for higher security o For transactions with higher values at stake or to exchange sensitive
data o Security properties formally verified against web attacker model
Financial-grade API 1.0 – Part 1: Baseline Security Profile Financial-grade API 1.0 – Part 2: Advanced Security Profile
Why?
§ Based on OAuth 2.0 and OpenID Connect suite of standards, but with less optionality and the requirement to use modern security best practices.
§ Clear point-by-point specifications that implementers can use as a “check list”
§ Exhaustive conformance tests to allow implementers to ensure their software is secure and interoperable
Final Specifications
Financial-grade API: Client Initiated Backchannel Authentication Profile Why? To enable “decoupled” authorization flows. Financial-grade API: JWT Secured Authorization Response Mode for OAuth 2.0 (JARM) Why? To enable signed responses from the AuthZ endpoint without requiring OpenID Connect.
Implementers Drafts
Financial-grade API 2.0: Baseline Security Profile Financial-grade API 2.0: Attacker Model Why?
FAPI 2.0 has a broader scope than FAPI 1.0. It 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.
FAPI 2.0
Financial-grade API 2.0: Advanced Security Profile Grant Management for OAuth 2.0 Simple HTTP Message Integrity Protocol Why?
Preventing the wheel from being re-invented by jurisdictions implementing FAPI.
Working Group Drafts
§ RFC8705 - OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens
§ OAuth JAR - JWT Secured Authorization Request (JAR)
§ OAuth PAR - Pushed Authorization Requests § OAuth RAR - Rich Authorization Requests § OAuth DPoP - Demonstrating Proof-of-Possession at
the Application Layer § OAuth 2.0 Authorization Server Issuer Identifier in
Authorization Response
Relevant IETF Drafts
FAPI Certifications https://openid.net/certification/#FAPI_OPs
FAPI Implementations
§ Data & payment § 9 banks must be FAPI conformant & certified; no RP obligation § Data only. § Australia encourages FAPI; 40+ banks participate, 2 FAPI certified; no RP obligation § Data & payment § Largest banks certified; remaining banks by October § FAPI conformance & certification required for banks § RPs likely to have a certification mandated § FAPI security profile and CIBA selected by FDX
§ FAPI is in review by 4 markets
Bank & RP Behaviors & Impacts § Bank behaviors
o If banks are not required to implement open banking they are unlikely to do so voluntarily
o If banks are not required to implement FAPI, they rarely certify proactively
o If banks are required to conform & certify they will do so o If banks are not required to renew certifications, then
implementations start to break and bank motivation is low to remediate
o Banks are starting to build their own products as RPs
§ Relying Party behaviors o Some relying parties take a “Minimum Viable Product” approach,
developing to a single bank and not the spec, then launching production services before security and multi-bank service is in place
o Some RPs blamed bank implementations for their own RP errors
Impacts
o User experience o Security risks human
errors o People resource
wasted
o User data & experience risks
o Security risks from human errors & inexperience
o People resource wasted o Brand risks
Key Learnings
§ Open Banking is in its infancy, but it is cascading rapidly around the world
§ The FAPI security profile & certification test suite are robust, and adaptable to local requirements
§ Not all ecosystem participants are motivated to deploy high quality implementations
§ Efforts to avoid/ delay certification requirements pose significant security risks and “false economies” § Efforts to divert from global specifications will undermine global interoperability in the future
§ Any market that seeks to deploy Open Banking should require FAPI conformance and certification by banks & relying parties
MNO with Open Banking (Data) Regulation Emerging
MNO Best Fit Live Examples OIDF Standards
MNOs with existing or anticipated Open Banking (Data) regulation q Key industries required to release data
to RP/TPPs when requested by users to avoid screen scraping & enable competition
q Current laws apply to MNOs in some markets where they offer payment/ bank services
q Laws in some markets will extend to cover carrier data
q Australia, Canada and Brazil leading; underway in Russia, Saudi, Bahrain, US, Canada. Local approaches in Germany, Singapore, India.
FAPI q Secure APIs that authenticate the
sender, receiver, user, message, while retaining user confidentiality and averting phishing/and reply attacks
q Implementing FAPI as the security profile offers ecosystem participants high confidence (it is a well proven standard)
q Option of leveraging OIDF certification (mandated by some governments)
UK & Brazil Open Banking Australia Open Data US/Canada FDX v5 q FAPI standard is widely
recommended (or mandated) by governments & their open banking management partners
q FAPI enables markets to opt into global interoperability in the future
MNOs in many markets already expect Open Banking regulation to apply to their industry and expand to Open Data including MNOs
MNO Identity services for Employees, Systems, Things
MNO Best Fit Live Examples OIDF Standards
All q Need to identify employees q Often legal obligations to identify
supplier q Work from home/ take your device to
work programs distribute devices q Staff devices, IoT, fleets of cars-
distributed and networked “things”
Open ID Connect + Profiles q Depends on use case
Emerging q Watch this space!
MNOs need to identify employees, enable access to internal systems & buildings, access to things (e.g. devices, IoT), and suppliers
Call to Action
Call to Action •
§ Joint the OIDF as a Member at openid.net
§ Learn more about working groups, review specifications, & watch presentations at openid.net
§ Join the GAIN POC at [email protected]
