<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="en"><head><title>Draft-01: Financial-grade API: Client Initiated Backchannel Authentication Profile</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="description" content="Financial-grade API: Client Initiated Backchannel Authentication Profile">
<meta name="generator" content="xml2rfc v1.36 (http://xml2rfc.ietf.org/)">
<style type='text/css'><!--
        body {
                font-family: verdana, charcoal, helvetica, arial, sans-serif;
                font-size: small; color: #000; background-color: #FFF;
                margin: 2em;
        }
        h1, h2, h3, h4, h5, h6 {
                font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif;
                font-weight: bold; font-style: normal;
        }
        h1 { color: #900; background-color: transparent; text-align: right; }
        h3 { color: #333; background-color: transparent; }

        td.RFCbug {
                font-size: x-small; text-decoration: none;
                width: 30px; height: 30px; padding-top: 2px;
                text-align: justify; vertical-align: middle;
                background-color: #000;
        }
        td.RFCbug span.RFC {
                font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
                font-weight: bold; color: #666;
        }
        td.RFCbug span.hotText {
                font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
                font-weight: normal; text-align: center; color: #FFF;
        }

        table.TOCbug { width: 30px; height: 15px; }
        td.TOCbug {
                text-align: center; width: 30px; height: 15px;
                color: #FFF; background-color: #900;
        }
        td.TOCbug a {
                font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif;
                font-weight: bold; font-size: x-small; text-decoration: none;
                color: #FFF; background-color: transparent;
        }

        td.header {
                font-family: arial, helvetica, sans-serif; font-size: x-small;
                vertical-align: top; width: 33%;
                color: #FFF; background-color: #666;
        }
        td.author { font-weight: bold; font-size: x-small; margin-left: 4em; }
        td.author-text { font-size: x-small; }

        /* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
        a.info {
                /* This is the key. */
                position: relative;
                z-index: 24;
                text-decoration: none;
        }
        a.info:hover {
                z-index: 25;
                color: #FFF; background-color: #900;
        }
        a.info span { display: none; }
        a.info:hover span.info {
                /* The span will display just on :hover state. */
                display: block;
                position: absolute;
                font-size: smaller;
                top: 2em; left: -5em; width: 15em;
                padding: 2px; border: 1px solid #333;
                color: #900; background-color: #EEE;
                text-align: left;
        }

        a { font-weight: bold; }
        a:link    { color: #900; background-color: transparent; }
        a:visited { color: #633; background-color: transparent; }
        a:active  { color: #633; background-color: transparent; }

        p { margin-left: 2em; margin-right: 2em; }
        p.copyright { font-size: x-small; }
        p.toc { font-size: small; font-weight: bold; margin-left: 3em; }
        table.toc { margin: 0 0 0 3em; padding: 0; border: 0; vertical-align: text-top; }
        td.toc { font-size: small; font-weight: bold; vertical-align: text-top; }

        ol.text { margin-left: 2em; margin-right: 2em; }
        ul.text { margin-left: 2em; margin-right: 2em; }
        li      { margin-left: 3em; }

        /* RFC-2629 <spanx>s and <artwork>s. */
        em     { font-style: italic; }
        strong { font-weight: bold; }
        dfn    { font-weight: bold; font-style: normal; }
        cite   { font-weight: normal; font-style: normal; }
        tt     { color: #036; }
        tt, pre, pre dfn, pre em, pre cite, pre span {
                font-family: "Courier New", Courier, monospace; font-size: small;
        }
        pre {
                text-align: left; padding: 4px;
                color: #000; background-color: #CCC;
        }
        pre dfn  { color: #900; }
        pre em   { color: #66F; background-color: #FFC; font-weight: normal; }
        pre .key { color: #33C; font-weight: bold; }
        pre .id  { color: #900; }
        pre .str { color: #000; background-color: #CFF; }
        pre .val { color: #066; }
        pre .rep { color: #909; }
        pre .oth { color: #000; background-color: #FCF; }
        pre .err { background-color: #FCC; }

        /* RFC-2629 <texttable>s. */
        table.all, table.full, table.headers, table.none {
                font-size: small; text-align: center; border-width: 2px;
                vertical-align: top; border-collapse: collapse;
        }
        table.all, table.full { border-style: solid; border-color: black; }
        table.headers, table.none { border-style: none; }
        th {
                font-weight: bold; border-color: black;
                border-width: 2px 2px 3px 2px;
        }
        table.all th, table.full th { border-style: solid; }
        table.headers th { border-style: none none solid none; }
        table.none th { border-style: none; }
        table.all td {
                border-style: solid; border-color: #333;
                border-width: 1px 2px;
        }
        table.full td, table.headers td, table.none td { border-style: none; }

        hr { height: 1px; }
        hr.insert {
                width: 80%; border-style: none; border-width: 0;
                color: #CCC; background-color: #CCC;
        }
--></style>
</head>
<body>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1">
<tr><td class="header">Draft-01</td><td class="header">D. Tonge</td></tr>
<tr><td class="header"> </td><td class="header">Moneyhub</td></tr>
<tr><td class="header">Draft-01</td><td class="header">J. Heenan</td></tr>
<tr><td class="header"> </td><td class="header">Authlete</td></tr>
<tr><td class="header"> </td><td class="header">T. Lodderstedt</td></tr>
<tr><td class="header"> </td><td class="header">Yes</td></tr>
<tr><td class="header"> </td><td class="header">B. Campbell</td></tr>
<tr><td class="header"> </td><td class="header">Ping Identity</td></tr>
<tr><td class="header"> </td><td class="header">June 26, 2019</td></tr>
</table></td></tr></table>
<h1><br />Financial-grade API: Client Initiated Backchannel Authentication Profile</h1>

<h3>Warning</h3>

<p>This document is not an OIDF International Standard. It is distributed for review and comment. It is subject to change without notice and may not be referred to as an International Standard.  
</p>
<p>Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.  
</p>
<h3>Copyright notice</h3>

<p>The OpenID Foundation (OIDF) grants to any Contributor, developer, implementer, or other interested party a non-exclusive, royalty free, worldwide copyright license to reproduce, prepare derivative works from, distribute, perform and display, this Implementers Draft or Final Specification solely for the purposes of (i) developing specifications, and (ii) implementing Implementers Drafts and Final Specifications based on such documents, provided that attribution be made to the OIDF as the source of the material, but that such attribution does not indicate an endorsement by the OIDF.
</p>
<p>The technology described in this specification was made available from contributions from various sources, including members of the OpenID Foundation and others. Although the OpenID Foundation has taken steps to help ensure that the technology is available for distribution, it takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this specification or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any independent effort to identify any such rights. The OpenID Foundation and the contributors to this specification make no (and hereby expressly disclaim any) warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to this specification, and the entire risk as to implementing this specification is assumed by the implementer. The OpenID Intellectual Property Rights policy requires contributors to offer a patent promise not to assert certain patent claims against other contributors and against implementers. The OpenID Foundation invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology that may be required to practice this specification.
</p>
<h3>Foreword</h3>

<p>The OpenID Foundation (OIDF) promotes, protects and nurtures the OpenID community and technologies. As a non-profit international standardizing body, it is comprised by over 160 participating entities (workgroup participants). The work of preparing implementer drafts and final international standards is carried out through OIDF workgroups in accordance with the OpenID Process. Participants interested in a subject for which a workgroup has been established has the right to be represented in that workgroup. International organizations, governmental and non-governmental, in liaison with OIDF, also take part in the work. OIDF collaborates closely with other standardizing bodies in the related fields.
</p>
<p>Final drafts adopted by the Workgroup through consensus are circulated publicly for the public review for 60 days and for the OIDF members for voting. Publication as an OIDF Standard requires approval by at least 50 % of the members casting a vote. There is a possibility that some of the elements of this document may be the subject to patent rights. OIDF shall not be held responsible for identifying any or all such patent rights.
</p>
<p>Financial-grade API consists of the following parts:
</p>
<p>
        </p>
<ul class="text">
<li>Part 1: Read-Only API Security Profile 
</li>
<li>Part 2: Read and Write API Security Profile 
</li>
<li>Client Initiated Backchannel Authentication Profile
</li>
<li>Financial-grade API: JWT Secured Authorization Response Mode for OAuth 2.0 (JARM)
</li>
<li>Financial-grade API: Pushed Request Object
</li>
</ul><p>
      
</p>
<p>Future parts may follow.
</p>
<p>This parts is intended to be used with [RFC6749], [RFC6750], [RFC7636], [OIDC], and [CIBA].
</p>
<h3>Introduction</h3>

<p>The Financial-grade API Standard provides a profile for OAuth 2.0 suitable for use in financial services. The standard OAuth method for the client to send the resource owner to the authorization server is to use an HTTP redirect. Parts 1 and 2 of this specification support this interaction model and are suitable for use cases where the resource owner is interacting with the client on a device they control that has a web browser. There are however many use-cases for initiating payments where the resource owner is not interacting with the client in such a manner. For example, the resource owner may want to authorize a payment at a "point of sale" terminal at a shop or fuel station.
</p>
<p>This document is a profile of the OpenID Connect Client Initiated Backchannel Authentication Flow [CIBA] that supports this decoupled interaction method. The CIBA spec allows a client that gains knowledge of an identifier for the user to obtain tokens from the authorization server. The user consent is given at the user's Authentication Device mediated by the authorization server. This document profiles the CIBA specification to bring it in line with the other FAPI parts and provides security recommendations for its use with APIs that require financial-grade security.
</p>
<p>Although it is possible to code an OpenID Provider and Relying Party from first principles using this specification, the main audience for this specification is parties who already have a certified implementation of OpenID Connect and want to achieve a higher level of security. Implementors are encouraged to understand the security considerations contained in section 7.5 before embarking on a 'from scratch' implementation.
</p>
<h3>Notational conventions</h3>

<p>The keywords "shall", "shall not", "should", "should not", "may", and "can" in this document are to be interpreted as described in ISO Directive Part 2 [ISODIR2]. These keywords are not used as dictionary terms such that any occurrence of them shall be interpreted as keywords and are not to be interpreted with their natural language meanings.
</p><a name="toc"></a><br /><hr />
<h3>Table of Contents</h3>
<p class="toc">
<a href="#scope">1.</a> 
Scope<br />
<a href="#normative-references">2.</a> 
Normative references<br />
<a href="#terms-and-definitions">3.</a> 
Terms and definitions<br />
<a href="#symbols-and-abbreviated-terms">4.</a> 
Symbols and Abbreviated terms<br />
<a href="#read-and-write-api-security-profile">5.</a> 
Read and Write API Security Profile<br />
    <a href="#introduction">5.1.</a> 
Introduction<br />
    <a href="#read-and-write-api-security-provisions">5.2.</a> 
Read and Write API Security Provisions<br />
        <a href="#introduction-1">5.2.1.</a> 
Introduction<br />
        <a href="#authorization-server">5.2.2.</a> 
Authorization Server<br />
        <a href="#confidential-client">5.2.3.</a> 
Confidential Client<br />
            <a href="#general-provisions">5.2.3.1.</a> 
General Provisions<br />
    <a href="#extensions-to-ciba-authentication-request">5.3.</a> 
Extensions to CIBA authentication request<br />
<a href="#accessing-protected-resources">6.</a> 
Accessing Protected Resources<br />
    <a href="#introduction-2">6.1.</a> 
Introduction<br />
    <a href="#client-provisions">6.2.</a> 
Client Provisions<br />
<a href="#security-considerations">7.</a> 
Security Considerations<br />
    <a href="#introduction-3">7.1.</a> 
Introduction<br />
    <a href="#authentication-sessions-started-without-a-users-knowledge-or-consent">7.2.</a> 
Authentication sessions started without a users knowledge or consent<br />
    <a href="#reliance-on-user-to-confirm-binding-messages">7.3.</a> 
Reliance on user to confirm binding messages<br />
    <a href="#loss-of-fraud-markers-to-openid-provider">7.4.</a> 
Loss of fraud markers to OpenID provider<br />
    <a href="#incomplete-or-incorrect-implementations-of-the-specifications">7.5.</a> 
Incomplete or incorrect implementations of the specifications<br />
    <a href="#jwsjwe-algorithm-considerations">7.6.</a> 
JWS/JWE Algorithm considerations<br />
    <a href="#authentication-device-security">7.7.</a> 
Authentication Device security<br />
    <a href="#ciba-token-delivery-modes">7.8.</a> 
CIBA token delivery modes<br />
<a href="#privacy-considerations">8.</a> 
Privacy Considerations<br />
<a href="#acknowledgement">9.</a> 
Acknowledgement<br />
<a href="#bibliography">10.</a> 
Bibliography<br />
<a href="#rfc.authors">§</a> 
Authors' Addresses<br />
</p>
<br clear="all" />

<a name="scope"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.1"></a><h3>1. 
Scope</h3>

<p>This document specifies the method for an application to: 
</p>
<p></p>
<ul class="text">
<li>obtain OAuth tokens via a backchannel authentication flow in an appropriately secure manner for financial data access and other similar situations where the risk is higher; 
</li>
<li>use tokens to interact with protected data via REST endpoints.  
</li>
</ul>

<a name="normative-references"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2"></a><h3>2. 
Normative references</h3>

<p>The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applied. For undated references, the latest edition of the referenced document (including any amendments) applies.  
</p>
<p>[ISODIR2] - ISO/IEC Directives Part 2 [ISODIR2]: http://www.iso.org/sites/directives/2016/part2/index.xhtml 
</p>
<p>[CIBA] - OpenID Connect Client Initiated Backchannel Authentication Core [CIBA]: http://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html 
</p>
<p>[FAPI1] - FAPI Read Only API Security Profile [FAPI1]: https://openid.net/specs/openid-financial-api-part-1.html 
</p>
<p>[FAPI2] - FAPI Read Write API Security Profile [FAPI2]: https://openid.net/specs/openid-financial-api-part-2.html 
</p>
<p>[FAPILI] - FAPI Lodging Intent [FAPILI]: https://bitbucket.org/openid/fapi/src/master/Financial_API_Pushed_Request_Object.md 
</p>
<a name="terms-and-definitions"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3"></a><h3>3. 
Terms and definitions</h3>

<p>For the purpose of this standard, the terms defined in RFC6749, RFC6750, RFC7636, OpenID Connect Core and OpenID Connect Client Initiated Backchannel Authentication Core apply.  
</p>
<a name="symbols-and-abbreviated-terms"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4"></a><h3>4. 
Symbols and Abbreviated terms</h3>

<p><strong>API</strong> – Application Programming Interface 
</p>
<p><strong>FAPI</strong> - Financial-grade API 
</p>
<p><strong>HTTP</strong> – Hyper Text Transfer Protocol 
</p>
<p><strong>OIDF</strong> - OpenID Foundation 
</p>
<p><strong>REST</strong> – Representational State Transfer 
</p>
<p><strong>TLS</strong> – Transport Layer Security 
</p>
<a name="read-and-write-api-security-profile"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5"></a><h3>5. 
Read and Write API Security Profile</h3>

<a name="introduction"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5.1"></a><h3>5.1. 
Introduction</h3>

<p>The OIDF Financial-grade API (FAPI) is a REST API that provides JSON data representing higher risk data. These APIs are protected by the OAuth 2.0 Authorization Framework that consists of [RFC6749], [RFC6750], [RFC7636], and other specifications.  
</p>
<p>The Client Initiated Backchannel Authentication Flow [CIBA] specifies an alternate method of users granting access to their resources whereby the flow is started from a consumption device, but authorized on an authentication device.  
</p>
<p>The following sections specify a profile of CIBA that is suited for financial-grade APIs.  
</p>
<a name="read-and-write-api-security-provisions"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5.2"></a><h3>5.2. 
Read and Write API Security Provisions</h3>

<a name="introduction-1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5.2.1"></a><h3>5.2.1. 
Introduction</h3>

<p>This profile applies to both Read-Only APIs and Read-and-Write APIs.  
</p>
<p>This spec should be read in conjunction with OpenID Connect Client Initiated Backchannel Authentication Core [CIBA] and with parts 1 [FAPI1] and 2 [FAPI2] of the Financial-grade API specification.  
</p>
<a name="authorization-server"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5.2.2"></a><h3>5.2.2. 
Authorization Server</h3>

<p>The Authorization Server shall support the provisions specified in clause 5.2.2 of Financial-grade API - Part 1 and clause 5.2.2 of Financial-grade API - Part 2.  
</p>
<p>In addition the Authorization server, for all operations, 
</p>
<p></p>
<ol class="text">
<li>shall only support Confidential Clients for Client Initiated Backchannel Authentication flows; 
</li>
<li>shall ensure unique authorization context exists in the authorization request or require a binding_message in the authentication request; 
</li>
<li>shall not support CIBA push mode; 
</li>
<li>shall support CIBA poll mode; 
</li>
<li>may support CIBA ping mode; 
</li>
<li>shall require Backchannel Authentication Endpoint requests to be signed as described in [CIBA] 7.1.1; 
</li>
<li>shall require user authentication to an appropriate level for the operations the client will be authorized to perform on behalf of the user; 
</li>
<li>shall, if it supports the acr claim and the client has requested acr, return an 'acr' claim in the resulting ID token; 
</li>
<li>shall require the Signed Authentication Request to contain <tt>nbf</tt> and <tt>exp</tt> claims that limit the lifetime of the request to no more than 60 minutes; 
</li>
<li>may require clients to provide a <tt>request_context</tt> claim as defined in section 5.3 of this profile; and 
</li>
<li>should not use the login_hint or login_hint_token to convey "intent ids" or any other authorization metadata 
</li>
</ol>

<p><strong>NOTE:</strong> As per [CIBA], <tt>login_hint</tt>, <tt>login_hint_token</tt> and <tt>id_token_hint</tt> are used only to determine who the user is. In scenarios where complex authorization parameters need to be conveyed from the Client to the AS, implementers should consider the "lodging intent" pattern described in [FAPILI]. The use of parameterized scope values or the use of an additional request parameter are both supported by this specification. Examples of both patterns are shown in [FAPILI].  
</p>
<p><strong>NOTE:</strong> The binding message is required to protect the user by binding the session on the consumption device with the session on the authentication device. An example use case is when a user is paying at POS terminal. The user will enter their user identifier to start the [CIBA] flow, the terminal will then display a code, the user will receive a notification on their phone (the authentication device) to ask them to authenticate and authorize the transaction, as part of the authorization process the user will be shown a code and will be asked to check that it is the same as the one shown on the terminal.  
</p>
<p><strong>NOTE:</strong> The FAPI CIBA profile only supports CIBA ping and poll modes, therefore it is only possible to retrieve access tokens and optionally refresh tokens from the token endpoint. The same security requirements for the token endpoint as detailed in [FAPI1] and [FAPI2] apply.  
</p>
<p><strong>NOTE:</strong> Given that the CIBA flow places an added level of trust on the Client, the FAPI CIBA profile requires the use of Signed Authentication Requests. This will enable the Authorization Server to store such requests, in an easily verifiable form, for future auditing purposes.  
</p>
<p><strong>NOTE:</strong> While the format of the <tt>login_hint</tt> and <tt>login_hint_token</tt> parameters are not defined by [CIBA] or this profile, implementers may wish to consider https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers for a standards based method of communicating user identifiers.  
</p>
<a name="confidential-client"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5.2.3"></a><h3>5.2.3. 
Confidential Client</h3>

<a name="general-provisions"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5.2.3.1"></a><h3>5.2.3.1. 
General Provisions</h3>

<p>A Confidential Client shall support the provisions specified in clause 5.2.4 of Financial-grade API - Part 1 [FAPI1] and clause 5.2.4 of Financial-grade API - Part 2 [FAPI2].  
</p>
<p>In addition, the Confidential Client 
</p>
<p></p>
<ol class="text">
<li>shall only send Signed Authentication Requests as defined in [CIBA] 7.1.1 to the Backchannel Authentication Endpoint; 
</li>
<li>shall ensure sufficient authorization context exists in authorization request or shall include a binding_message in the authentication request; and 
</li>
<li>shall ensure the Authorization Server has authenticated the user to an appropriate level for the client's intended purpose.  
</li>
</ol>

<a name="extensions-to-ciba-authentication-request"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5.3"></a><h3>5.3. 
Extensions to CIBA authentication request</h3>

<p>This profile defines the following extensions to the authentication request defined in [CIBA] section 7.1.  
</p>
<p></p>
<ol class="text">
<li><tt>request_context</tt>: OPTIONAL. a JSON object (the contents of which are not defined by this specification) containing information to inform fraud and threat decisions.  For example, an ecosystem may require relying parties to provide geolocation for the consumption device.  
</li>
</ol>

<a name="accessing-protected-resources"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.6"></a><h3>6. 
Accessing Protected Resources</h3>

<a name="introduction-2"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.6.1"></a><h3>6.1. 
Introduction</h3>

<p>The provisions detailed in Parts 1 and 2 of the Financial-grade API specification apply fully. The benefit of the CIBA specification is that once tokens are issued they can be used in the same manner as tokens issued via authorization code flows.  
</p>
<a name="client-provisions"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.6.2"></a><h3>6.2. 
Client Provisions</h3>

<p>In situations where the client does not control the consumption device, the client 
</p>
<p></p>
<ol class="text">
<li>shall not send <tt>x-fapi-customer-ip-address</tt> or <tt>x-fapi-auth-date</tt> headers; and 
</li>
<li>should send metadata about the consumption device, for example geolocation and device type.  
</li>
</ol>

<a name="security-considerations"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.7"></a><h3>7. 
Security Considerations</h3>

<a name="introduction-3"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.7.1"></a><h3>7.1. 
Introduction</h3>

<p>The [CIBA] specification introduces some new attack vectors not present in OAuth 2 redirect based flows. This profile aims to help implementers of [CIBA] for financial-grade APIs to reduce or eliminate these attack vectors. There are however further security considerations that should be taken into account when implementing this specification.  
</p>
<a name="authentication-sessions-started-without-a-users-knowledge-or-consent"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.7.2"></a><h3>7.2. 
Authentication sessions started without a users knowledge or consent</h3>

<p>As this specification allows the client to initiate an authentication request it is important for the authorization server to know whether the user is aware and has consented to the authentication process. If widely known user identifiers (e.g.  phone numbers) are used as the <tt>login_hint</tt> in the authentication request then this risk is worsened. An attacker could start unsolicited authentication sessions on large numbers of authentication devices, causing distress and potentially enabling fraud. For this reason this profile highly recommends <tt>login_hint</tt> to have the properties of a nonce with the expectation being that it will be generated from an authorization server owned client authentication device. Given the high levels of friction that this may impose it's anticipated that Authorization Servers may have to accept an <tt>id_token_hint</tt> as an alternative mechanism for Client Subject identification.  
</p>
<p>If a client wishes to store the <tt>id_token</tt> returned from an authorization server for later use as an <tt>id_token_hint</tt>, care must be taken to ensure that the customer identification mechanism used to retrieve the <tt>id_token</tt> is appropriate for the channel being used. For illustration a QR code on a 'club card' may be an appropriate identifier when using a POS terminal under CCTV but it might not be an appropriate identifier when used in online ecommerce.  
</p>
<p>In addition, [CIBA] provides an optional <tt>user_code</tt> mechanism to specifically mitigate this issue, it may be appropriate to require the use of <tt>user_code</tt> in certain deployments.  
</p>
<a name="reliance-on-user-to-confirm-binding-messages"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.7.3"></a><h3>7.3. 
Reliance on user to confirm binding messages</h3>

<p>Depending on the hint used to identify the user and the Client's user authentication processes, it may be possible for a fraudster to start a malicious [CIBA] flow at the same time as a genuine flow, with both flows using the genuine user’s identifier. If the scope of access requested is similar then the only way to ensure that a user is authorizing the correct transaction is for the user to compare the binding messages on the Authentication and Consumption devices.  
</p>
<p>If this risk is deemed unacceptable then implementers should either consider alternative mechanisms of verifying the binding message (e.g. conveying it to the Authentication device via a QR code), or use ephemeral user identifiers generated on the Authentication device.  
</p>
<a name="loss-of-fraud-markers-to-openid-provider"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.7.4"></a><h3>7.4. 
Loss of fraud markers to OpenID provider</h3>

<p>In a redirect-based flow, the authorization server can collect useful fraud markers from the user-agent. In a [CIBA] flow the separation of consumption and authentication devices reduces the data that can be collected. This could reduce the effectiveness of any fraud detection system.  
</p>
<a name="incomplete-or-incorrect-implementations-of-the-specifications"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.7.5"></a><h3>7.5. 
Incomplete or incorrect implementations of the specifications</h3>

<p>To achieve the full security benefits, it is important the implementation of this specification, and the underlying OpenID Connect and OAuth specifications, are both complete and correct.  
</p>
<p>The OpenID Foundation provides tools that can be used to confirm that an implementation is correct: 
</p>
<p>https://openid.net/certification/ 
</p>
<p>The OpenID Foundation maintains a list of certified implementations: 
</p>
<p>https://openid.net/developers/certified/ 
</p>
<p>Deployments that use this specification should use a certified implementation.  
</p>
<a name="jwsjwe-algorithm-considerations"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.7.6"></a><h3>7.6. 
JWS/JWE Algorithm considerations</h3>

<p>CIBA Authorization Servers and Clients shall follow the guidance around JWT signing and encryption Algorithms in [FAPI2] 8.6 and 8.6.1.  
</p>
<a name="authentication-device-security"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.7.7"></a><h3>7.7. 
Authentication Device security</h3>

<p>This profile and the underlying specifications do not specify how the Authorization Server should initiate and perform user authentication and authorization of consent on the authentication device.  
</p>
<p>Implementors must use appropriately strong methods to communicate with the authentication device and to authenticate the end user.  
</p>
<a name="ciba-token-delivery-modes"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.7.8"></a><h3>7.8. 
CIBA token delivery modes</h3>

<p>[CIBA] defines 3 ways that tokens can be delivered to the client.  
</p>
<p>The <tt>push</tt> mode is not permitted by this specification as it delivers tokens to the client by calling an endpoint owned by the client. This substantially differs from the established pattern of retrieving tokens by presenting client authentication to the token endpoint, and it may have security concerns that are currently unknown.  
</p>
<p>The <tt>poll</tt> and <tt>ping</tt> modes both follow the established convention of retrieving tokens from the token endpoint and hence do not have this concern.  
</p>
<p>The <tt>ping</tt> mode delivers a notification to an endpoint owned by the client. The information contained in this notification is limited to the <tt>auth_req_id</tt> for the request, as described in [CIBA] 10.2. The bearer token used by the authorization server to access this resource is not sender constrained. If the <tt>backchannel_client_notification_endpoint</tt>, the <tt>auth_req_id</tt> and the <tt>client_notification_token</tt> are known to an attacker, they may be able to force the client to call the token endpoint repeatedly or before the authentication has completed.  For most deployments this is not a significant issue.  
</p>
<a name="privacy-considerations"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.8"></a><h3>8. 
Privacy Considerations</h3>

<p>There are no additional privacy considerations beyond those in [CIBA] 15.  
</p>
<a name="acknowledgement"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.9"></a><h3>9. 
Acknowledgement</h3>

<p>The following people contributed heavily towards this document: 
</p>
<p></p>
<ul class="text">
<li>Nat Sakimura (Nomura Research Institute) -- Chair, Editor 
</li>
<li>Anoop Saxana (Intuit) -- Co-chair, FS-ISAC Liaison 
</li>
<li>Anthony Nadalin (Microsoft) -- Co-chair, SC 27 Liaison 
</li>
<li>Edmund Jay (Illumila) -- Co-editor 
</li>
<li>Dave Tonge (Moneyhub) -- Co-chair, UK Implementation Entity Liaison 
</li>
<li>Brian Campbell (Ping Identity) 
</li>
<li>John Bradley (Yubico) 
</li>
<li>Henrik Biering (Peercraft) 
</li>
<li>Axel Nennker (Deutsche Telekom) 
</li>
<li>Ralph Bragg (RAiDiAM) 
</li>
<li>Joseph Heenan (Authlete) 
</li>
<li>Torsten Lodderstedt (yes.com) 
</li>
<li>Takahiko Kawasaki (Authlete) 
</li>
</ul>

<a name="bibliography"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.10"></a><h3>10. 
Bibliography</h3>

<p>[RFC6749] - The OAuth 2.0 Authorization Framework [RFC6749]: https://tools.ietf.org/html/rfc6749 
</p>
<p>[RFC6750] - The OAuth 2.0 Authorization Framework: Bearer Token Usage [RFC6750]: https://tools.ietf.org/html/rfc6750 
</p>
<p>[OIDC] - OpenID Connect Core 1.0 incorporating errata set 1 [OIDC]: http://openid.net/specs/openid-connect-core-1_0.html 
</p>
<a name="rfc.authors"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<h3>Authors' Addresses</h3>
<table width="99%" border="0" cellpadding="0" cellspacing="0">
<tr><td class="author-text"> </td>
<td class="author-text">Dave Tonge</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Moneyhub</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:dave.tonge@moneyhub.com">dave.tonge@moneyhub.com</a></td></tr>
<tr><td class="author" align="right">URI: </td>
<td class="author-text"><a href="http://moneyhubenterprise.com">http://moneyhubenterprise.com</a></td></tr>
<tr cellpadding="3"><td> </td><td> </td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Josep Heenan</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Authlete</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:joseph@authlete.com">joseph@authlete.com</a></td></tr>
<tr><td class="author" align="right">URI: </td>
<td class="author-text"><a href="https://www.authlete.com/">https://www.authlete.com/</a></td></tr>
<tr cellpadding="3"><td> </td><td> </td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Torsten Lodderstedt</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">YES</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:torsten@lodderstedt.net">torsten@lodderstedt.net</a></td></tr>
<tr><td class="author" align="right">URI: </td>
<td class="author-text"><a href="http://yes.com">http://yes.com</a></td></tr>
<tr cellpadding="3"><td> </td><td> </td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Brian Campbell</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Ping Identity</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:bcampbell@pingidentity.com">bcampbell@pingidentity.com</a></td></tr>
<tr><td class="author" align="right">URI: </td>
<td class="author-text"><a href="http://www.pingidentity.com/">http://www.pingidentity.com/</a></td></tr>
</table>
</body></html>