<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="en"><head><title>Draft: Financial Services – Financial API - Part 2: Read and Write API Security Profile</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="description" content="Financial Services – Financial API - Part 2: Read and Write API Security 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</td><td class="header">N. Sakimura</td></tr>
<tr><td class="header"> </td><td class="header">NRI</td></tr>
<tr><td class="header"> </td><td class="header">J. Bradley</td></tr>
<tr><td class="header"> </td><td class="header">Ping Identity</td></tr>
<tr><td class="header"> </td><td class="header">E. Jay</td></tr>
<tr><td class="header"> </td><td class="header">Illumila</td></tr>
<tr><td class="header"> </td><td class="header">May 29, 2017</td></tr>
</table></td></tr></table>
<h1><br />Financial Services – Financial API - Part 2: Read and Write API Security 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>OIDF (OpenID Foundation) is an international standardizing body comprised by over 160 participating entities (work group participants). The work of preparing international standards is carried out through OIDF work groups according to OpenID Process.  Each participants interested in a subject for which a work group has been established has the right to be represented on that work group. 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>OpenID Foundation standards are drafted in accordance with the rules given in the OpenID Process.  
</p>
<p>The main task of work group is to prepare Implementers Draft and Final Draft. Final Draft adopted by the Work Group 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.  
</p>
<p>Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. OIDF shall not be held responsible for identifying any or all such patent rights.  
</p>
<p>Financial API - Part 1: Read Only API Security Profile was prepared by OpenID Foundation Financial API Work Group.  
</p>
<p>Financial API consists of the following parts, under the general title Financial Services — Financial API: 
</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>Part 3: Open Data API 
</li>
<li>Part 4: Protected Data API and Schema - Read only 
</li>
<li>Part 5: Protected Data API and Schema - Read and Write 
</li>
</ul><p>
      
</p>
<p>This part is intended to be used with [RFC6749], [RFC6750], [RFC6736], and [OIDC].  
</p>
<h3>Introduction</h3>

<p>In many cases, Fintech services such as aggregation services use screen scraping and store user passwords. This model is both brittle and insecure. To cope with the brittleness, it should utilize an API model with structured data and to cope with insecurity, it should utilize a token model such as OAuth [RFC6749, RFC6750].  
</p>
<p>Financial API aims to rectify the situation by developing a REST/JSON model protected by OAuth. However, just asking to use OAuth is too vague as there are many implementation choices. OAuth is a framework which can cover wide range of use-cases thus some implementation choices are easy to implement but less secure and some implementation choices are harder to implement but more secure.  Financial services on the internet is a use-case that requires more secure implementation choices. That is, OAuth needs to be profiled to be used in the financial use-cases.  
</p>
<p>This document is a Part 2 of a set of document that specifies Financial API. It provides a profile of OAuth that is suitable to be used in the write access to the financial data also known as the transactional access. To achieve it, this part of the document specifies the control against such attacks like authorization request tampering, the authorization response tampering including code injection and the state injection, token request phishing, etc. More details are available in the security consideration section.
</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="#public-client">5.2.3.</a> 
Public Client<br />
        <a href="#confidential-client">5.2.4.</a> 
Confidential Client<br />
<a href="#accessing-protected-resources-using-tokens">6.</a> 
Accessing Protected Resources (Using tokens)<br />
    <a href="#introduction-2">6.1.</a> 
Introduction<br />
    <a href="#read-and-write-access-provisions">6.2.</a> 
Read and write access provisions<br />
        <a href="#protected-resources-provisions">6.2.1.</a> 
Protected resources provisions<br />
        <a href="#client-provisions">6.2.2.</a> 
Client provisions<br />
<a href="#request-object-endpoint">7.</a> 
Request object endpoint<br />
    <a href="#introduction-3">7.1.</a> 
Introduction<br />
    <a href="#request">7.2.</a> 
Request<br />
    <a href="#successful-response">7.3.</a> 
Successful response<br />
    <a href="#error-responses">7.4.</a> 
Error responses<br />
        <a href="#authorization-required">7.4.1.</a> 
Authorization required<br />
        <a href="#invalid-request">7.4.2.</a> 
Invalid request<br />
        <a href="#method-not-allowed">7.4.3.</a> 
Method Not Allowed<br />
        <a href="#request-entity-too-large">7.4.4.</a> 
Request entity too large<br />
        <a href="#too-many-requests">7.4.5.</a> 
Too many requests<br />
<a href="#security-considerations">8.</a> 
Security Considerations<br />
    <a href="#introduction-4">8.1.</a> 
Introduction<br />
    <a href="#uncertainty-around-the-resource-servers-handling-of-the-access-token">8.2.</a> 
Uncertainty around the resource server's handling of the access token<br />
    <a href="#attacks-that-involves-the-weak-binding-of-authorization-server-endpoints">8.3.</a> 
Attacks that involves the weak binding of authorization server endpoints<br />
        <a href="#introduction-5">8.3.1.</a> 
Introduction<br />
        <a href="#client-credential-and-authorization-code-phishing-at-token-endpoint">8.3.2.</a> 
Client credential and authorization code phishing at token endpoint<br />
        <a href="#idp-mix-up-attack">8.3.3.</a> 
IdP Mix-up attack<br />
        <a href="#request-object-endpoint-phishing-resistance">8.3.4.</a> 
Request object endpoint phishing resistance<br />
        <a href="#access-token-phishing">8.3.5.</a> 
Access token phishing<br />
    <a href="#attacks-that-involves-the-modification-of-authorization-requests-and-responses">8.4.</a> 
Attacks that involves the modification of authorization requests and responses<br />
        <a href="#introduction-6">8.4.1.</a> 
Introduction<br />
        <a href="#authorization-request-parameter-injection-attack">8.4.2.</a> 
Authorization Request parameter injection attack<br />
        <a href="#authorization-response-parameter-injection-attack">8.4.3.</a> 
Authorization Response parameter injection attack<br />
    <a href="#tls-considerations">8.5.</a> 
TLS considerations<br />
    <a href="#jws-algorithm-considerations">8.6.</a> 
JWS algorithm considerations<br />
<a href="#privacy-considerations">9.</a> 
Privacy Considerations<br />
<a href="#acknowledgement">10.</a> 
Acknowledgement<br />
<a href="#bibliography">11.</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 part of the document specifies the method of 
</p>
<p></p>
<ul class="text">
<li>applications to obtain the OAuth tokens in an appropriately secure manner for financial data access; 
</li>
<li>application to utilize OpenID Connect to identify the customer; and 
</li>
<li>using the tokens to interact with the REST endpoints that provides financial data; 
</li>
</ul>

<p>This document is applicable to higher risk use cases which includes commercial and investment banking.  
</p>
<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>[RFC7230] - Hypertext Transfer Protocol -- HTTP/1.1 [RFC7230]: https://tools.ietf.org/html/rfc7230 
</p>
<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>[RFC7636] - Proof Key for Code Exchange by OAuth Public Clients [RFC7636]: https://tools.ietf.org/html/rfc7636 
</p>
<p>[RFC5246] - The Transport Layer Security (TLS) Protocol Version 1.2 [RFC5246]: https://tools.ietf.org/html/rfc5246 
</p>
<p>[RFC6125] - Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS) [RFC6125]: https://tools.ietf.org/html/rfc6125 
</p>
<p>[RFC6819] - OAuth 2.0 Threat Model and Security Considerations [RFC6819]: https://tools.ietf.org/html/rfc6819 
</p>
<p>[RFC7519] - JSON Web Token (JWT) [RFC7519]:https://tools.ietf.org/html/rfc7519 
</p>
<p>[BCP195] - Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) [BCP195]: https://tools.ietf.org/html/bcp195 
</p>
<p>BCP NAPPS - <a href='https://tools.ietf.org/html/draft-ietf-oauth-native-apps-03'>OAuth 2.0 for Native Apps</a> 
</p>
<p>[OIDC] - OpenID Connect Core 1.0 incorporating errata set 1 [OIDC]: http://openid.net/specs/openid-connect-core-1_0.html 
</p>
<p>[OIDD] - OpenID Connect Discovery 1.0 incorporating errata set 1 [OIDD]: http://openid.net/specs/openid-connect-discovery-1_0.html 
</p>
<p>[OIDM] - OAuth 2.0 Multiple Response Type Encoding Practices [OIDM]: http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html 
</p>
<p>[X.1254] - Entity authentication assurance framework [X.1254]: https://www.itu.int/rec/T-REC-X.1254 
</p>
<p>[OAUTB] - OAuth 2.0 Token Binding [OAUTB]: https://tools.ietf.org/html/draft-ietf-oauth-token-binding-01 
</p>
<p>[MTLS] - Mutual TLS Profiles for OAuth Clients [MTLS]: https://tools.ietf.org/html/draft-ietf-oauth-mtls-00 
</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][OIDC] 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>CSRF</strong> - Cross Site Request Forgery 
</p>
<p><strong>FAPI</strong> - Financial API 
</p>
<p><strong>FI</strong> – Financial Institution 
</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 API (FAPI) is a REST API that provides JSON data representing accounts and transactional data. These APIs are protected by the OAuth 2.0 Authorization Framework that consists of [RFC6749], [RFC6750], [RFC7636], and other specifications.  
</p>
<p>There are different levels of risks associated with access to these APIs. Read and write access has a higher financial risk than read-only access. As such, the security profiles of the authorization framework protecting these APIs are also different.  
</p>
<p>This profile describes security provisions for the server and client that are appropriate for read and write access by defining the measures to mitigate the attacks that leverage on the weak binding of endpoints in [RFC6749] (e.g. Malicious Endpoints attacks, IdP Mix-up attacks) and attacks that involve modification of the authorization requests and responses that are not protected in [RFC6749] by leveraging on OpenID Connect's Hybrid Flow that returns an ID Token in the authorization response.  
</p>
<p>While the name ID Token suggests that it is something that provides the identity of the resource owner (subject), it is not necessarily so. While it does identify the authorization server by including the issuer identifier, it is perfectly fine to have ephemeral subject identifier. In this case, the ID Token acts as a detached signature of the issuer to the authorization response and it was an explicit design decision of OpenID Connect Core to make the ID Token act as a detached signature.  
</p>
<p>This document leverages on this fact and protects the authorization response by including the hash of all of the unprotected response parameters, i.e. <tt>code</tt> and <tt>state</tt>.  
</p>
<p>While the hash of the <tt>code</tt> is defined in [OIDC], the hash of the <tt>state</tt> is not defined.  Thus this document defines it as follows.  
</p>
<p>** s_hash ** 
</p>
<p>State hash value. Its value is the base64url encoding of the left-most half of the hash of the octets of the ASCII representation of the state value, where the hash algorithm used is the hash algorithm used in the <tt>alg</tt> Header Parameter of the ID Token's JOSE Header. For instance, if the alg is HS512, hash the code value with SHA-512, then take the left-most 256 bits and base64url encode them. The <tt>s_hash</tt> value is a case sensitive string.  
</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>Read and Write Access carries high financial risk, so the protection level is higher than Read-Only Access.  
</p>
<p>As a profile of The OAuth 2.0 Authorization Framework, this document mandates the following for the Read and Write API of the FAPI.  
</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 API - Part 1: Read Only API Security Profile.  
</p>
<p>In addition, the Authorization server, for the write operation, 
</p>
<p></p>
<ol class="text">
<li>shall require the <tt>request</tt> or <tt>request_uri</tt> parameter to be passed as a JWS signed JWT as in clause 6 of [OIDC]; 
</li>
<li>shall require the <tt>response_type</tt> values <tt>code id_token</tt> or <tt>code id_token token</tt>; 
</li>
<li>shall return ID Token as a detached signature to the authorization response; 
</li>
<li>shall include state hash, <tt>s_hash</tt>, in the ID Token to protect the <tt>state</tt> value; 
</li>
<li>shall only issue holder of key authorization code, access token, and refresh token for write operations; 
</li>
<li>shall support [OAUTB] or [MTLS] as a holder of key mechanism; 
</li>
<li>shall support user authentication at LoA 3 or greater as defined in [X.1254]; 
</li>
<li>shall support signed ID Tokens; and 
</li>
<li>should support signed and encrypted ID Token.  
</li>
</ol>

<a name="public-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. 
Public Client</h3>

<p>A Public Client shall support the provisions specified in clause 5.2.3 of Financial API - Part 1: Read Only API Security Profile.  
</p>
<p>In addition, the Public Client 
</p>
<p></p>
<ol class="text">
<li>shall support [OAUTB] as a holder of key mechanism; 
</li>
<li>shall include the <tt>request</tt> or <tt>request_uri</tt> parameter as defined in Section 6 of [OIDC] in the authentication request; 
</li>
<li>shall request user authentication at LoA 3 or greater by requesting the <tt>acr</tt> claim as an essential claim as defined in section 5.5.1.1 of [OIDC]; 
</li>
<li>shall require JWS signed ID Token be returned from endpoints; 
</li>
<li>shall verify that the <tt>acr</tt> claim in an ID Token indicates that user authentication was performed at LoA3 or greater; 
</li>
<li>shall verify that the <tt>amr</tt> claim in an ID Token contains values appropriate for the LoA indicated by the <tt>acr</tt> claim; 
</li>
<li>shall verify that the authorization response was not tampered using ID Token as the detached signature 
</li>
</ol>

<p>for write operations.  
</p>
<p>To verify that the authorization response was not tampered using ID Token as the detached signature, the client shall verify that <tt>s_hash</tt> value is equal to the value calculated from the <tt>state</tt> value in the authorization response in addition to all the requirements in 3.3.2.12 of [OIDC].  
</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.4"></a><h3>5.2.4. 
Confidential Client</h3>

<p>In addition to the provision to the Public Client and the provisions of clause 5.2.3, the Confidential Client 
</p>
<p></p>
<ol class="text">
<li>shall support [OAUTB] or [MTLS] as a holder of key mechanism; 
</li>
<li>shall require both JWS signed and JWE encrypted ID Tokens to be returned from endpoints 
</li>
</ol>

<p>for write operations.  
</p>
<a name="accessing-protected-resources-using-tokens"></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 (Using tokens)</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 FAPI endpoints are OAuth 2.0 protected resource endpoints that return various financial information for the resource owner associated with the submitted access token.  
</p>
<a name="read-and-write-access-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. 
Read and write access provisions</h3>

<a name="protected-resources-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.1"></a><h3>6.2.1. 
Protected resources provisions</h3>

<p>The protected resources supporting this document 
</p>
<p></p>
<ol class="text">
<li>shall support the provisions specified in clause 6.2.1 Financial API - Part 1: Read Only API Security Profile; 
</li>
<li>shall adhere to the requirements in [MTLS].  
</li>
</ol>

<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.2"></a><h3>6.2.2. 
Client provisions</h3>

<p>The client supporting this document shall support the provisions specified in clause 6.2.2 of Financial API - Part 1: Read Only API Security Profile.  
</p>
<a name="request-object-endpoint"></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. 
Request object endpoint</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 client may not want to send the request object by value, either because it is too large, or because it contains sensitive data and the client doesn't want to encrypt the request object. In such cases it is possible to send the request object by reference using a <tt>request_uri</tt>.  
</p>
<p>Note that <tt>request_uri</tt> can be either URL or URN.  If it is a URL, it shall be based on a cryptographic random value so that it is difficult to predict for the attacker.  
</p>
<p>The request URI can be hosted by the client or by the authorization server. The advantage of the authorization server hosting the request object is that it doesn't have to support outbound requests to a client specified request URI nor rely on the entropy of the URI for the confidentiality of the request object.  
</p>
<p>When the request object is stored at the authorization server, the <tt>request_uri</tt> value typically is a URN.  
</p>
<p>This section defines the specification for the authorization server to provide an endpoint for a client to exchange a request object for a request URI.  
</p>
<a name="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.7.2"></a><h3>7.2. 
Request</h3>

<p>The request object endpoint is a RESTful API endpoint at the authorization server that accepts a signed request object as an HTTPS POST payload. The request object needs to be signed for the client authentication and as the evidence of the client submitting the request object, which sometimes is called 'non-repudiation'.  
</p>
<p>The following is an example of such a request.  
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
POST https://as.example.com/ros/ HTTP/1.1
Host: as.example.com
Content-Type: application/jws
Content-Length: 1288

eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KICJpc3MiOiA
(... abbreviated for brevity ...)
zCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw
</pre></div>
<a name="successful-response"></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. 
Successful response</h3>

<p>The authorization server shall verify that the request object is valid, the signature algorithm is not <tt>none</tt>, and the signature is correct as in clause 6.3 of [OIDC].  
</p>
<p>If the verification is successful, the server shall generate a request URI and return a JSON payload that contains <tt>request_uri</tt>, <tt>aud</tt>, <tt>iss</tt>, and <tt>exp</tt> claims at the top level with <tt>201 Created</tt> HTTP response code.  
</p>
<p>The value of these claims in the JSON payload shall be as follows: 
</p>
<p></p>
<ul class="text">
<li><tt>request_uri</tt> : The request URI corresponding to the request object posted.  
</li>
<li><tt>aud</tt> : A JSON string that represents the client identifier of the client that posted the request object.  
</li>
<li><tt>iss</tt> : A JSON string that represents the issuer identifier of the authorization server as defined in [RFC7519]. When a pure OAuth 2.0 is used, the value is the redirection URI. When OpenID Connect is used, the value is the issuer value of the authorization server.  
</li>
<li><tt>exp</tt> : A JSON number that represents the expiry time of the request URI as defined in [RFC7519].  
</li>
</ul>

<p>The following is an example of such a response.  
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
HTTP/1.1 201 Created
Date: Tue, 2 May 2017 15:22:31 GMT
Content-Type: application/json

{
    'iss':'https://as.example.com/',
    'aud':'s6BhdRkqt3',
    'request_uri':'urn:example:MTAyODAK',
    'exp':1493738581
}
</pre></div>
<p>The request URI shall be bound to the client identifier of the client that posted the request object. Since the request URI can be replayed, its lifetime should be short and preferably one-time use.  
</p>
<a name="error-responses"></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. 
Error responses</h3>

<a name="authorization-required"></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.1"></a><h3>7.4.1. 
Authorization required</h3>

<p>If the signature validation fails, the authorization server shall return <tt>401 Unauthorized</tt> HTTP error response.  
</p>
<a name="invalid-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.7.4.2"></a><h3>7.4.2. 
Invalid request</h3>

<p>If the request object received is invalid, the authorization server shall return <tt>400 Bad Request</tt> HTTP error response.  
</p>
<a name="method-not-allowed"></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.3"></a><h3>7.4.3. 
Method Not Allowed</h3>

<p>If the request did not use POST, the authorization server shall return <tt>405 Method Not Allowed</tt> HTTP error response.  
</p>
<a name="request-entity-too-large"></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.4"></a><h3>7.4.4. 
Request entity too large</h3>

<p>If the request size was beyond the upper bound that the authorization server allows, the authorization server shall return a <tt>413 Request Entity Too Large</tt> HTTP error response.  
</p>
<a name="too-many-requests"></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.5"></a><h3>7.4.5. 
Too many requests</h3>

<p>If the request from the client per a time period goes beyond the number the authorization server allows, the authorization server shall return a <tt>429 Too Many Requests</tt> HTTP error response.  
</p>
<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.8"></a><h3>8. 
Security Considerations</h3>

<a name="introduction-4"></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.1"></a><h3>8.1. 
Introduction</h3>

<p>As a profile of The OAuth 2.0 Authorization Framework, this specification references the security considerations defined in section 10 of [RFC6749], as well as [RFC6819] - OAuth 2.0 Threat Model and Security Considerations, which details various threats and mitigations.  
</p>
<a name="uncertainty-around-the-resource-servers-handling-of-the-access-token"></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.2"></a><h3>8.2. 
Uncertainty around the resource server's handling of the access token</h3>

<p>There is no way that the client can find out whether the resource access was granted for the Bearer token or holder of key token.  The two differ in the risk profile and the client may want to differentiate them. The protected resources that conforms to this document shall not accept a plain Bearer token. They shall only support token bound access tokens via [MTLS] or [OAUTB].  
</p>
<a name="attacks-that-involves-the-weak-binding-of-authorization-server-endpoints"></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.3"></a><h3>8.3. 
Attacks that involves the weak binding of authorization server endpoints</h3>

<a name="introduction-5"></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.3.1"></a><h3>8.3.1. 
Introduction</h3>

<p>In [RFC6749] and [RFC6750], the endpoints that the authorization server offers are not tightly bound together. There is no notion of authorization server identifier (issuer identifier) and it is not indicated in the authorization response unless the client uses different redirection URI per authorization server. While it is assumed in the OAuth model, it is not explicitly spelled out and thus many clients use the same redirection URI for different authorization servers exposing attack surface. Several attacks are identified by now and many of them are explained in more details in [RFC6819] in more detail.  
</p>
<a name="client-credential-and-authorization-code-phishing-at-token-endpoint"></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.3.2"></a><h3>8.3.2. 
Client credential and authorization code phishing at token endpoint</h3>

<p>In this attack, the client developer is social engineered into believing that the token endpoint has changed to the URL that is controlled by the attacker. As the result, the client sends the <tt>code</tt> and the client secret to the attacker, which will be replayed subsequently.  
</p>
<p>When the FAPI client uses [MTLS] or [OAUTB], the authorization code is bound to the TLS channel, any phished client credentials and authorization codes submitted to the token endpoint cannot be used since the authorization code is bound to a particular TLS channel.  
</p>
<a name="idp-mix-up-attack"></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.3.3"></a><h3>8.3.3. 
IdP Mix-up attack</h3>

<p>In this attack, the client has registered multiple IdPs and one of them is a rogue IdP that returns the same <tt>client_id</tt> that belongs to one of the honest IdPs. When a user clicks on a malicious link or visits a compromised site, an authorization request is sent to the rogue Idp. The rogue Idp then redirects the client to the honest IdP that has the same <tt>client_id</tt>. If the user is already logged on at the honest IdP, then the authentication may be skipped and a code is generated and returned to the client.  Since the client was interacting with the rogue IdP, the code is sent to the rogue IdP's token endpoint. At the point, the attacker has a valid code that can be exchanged for an Access Token at the honest IdP.  
</p>
<p>This is mitigated by the use of Hybrid flow in which the Honest IdP's issuer identifier is included as the value of <tt>iss</tt>. The client then sends the <tt>code</tt> to the token endpoint that is associated with the issuer identifier thus it will not get to the attacker.  
</p>
<a name="request-object-endpoint-phishing-resistance"></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.3.4"></a><h3>8.3.4. 
Request object endpoint phishing resistance</h3>

<p>An attacker can use social engineering to have the administrator of the client set the request object endpoint to a URL under the attacker's control. In this case, sensitive information included in the request object will be revealed to the attacker. To prevent this, the authorization server should communicate to the client developer the proper change process repeatedly to help client developers to be less susceptible to such social engineering.  
</p>
<a name="access-token-phishing"></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.3.5"></a><h3>8.3.5. 
Access token phishing</h3>

<p>When the FAPI client uses [MTLS] or [OAUTB], the access token is bound to the TLS channel, it is access token phishing resistant as the phished access tokens cannot be used.  
</p>
<a name="attacks-that-involves-the-modification-of-authorization-requests-and-responses"></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.4"></a><h3>8.4. 
Attacks that involves the modification of authorization requests and responses</h3>

<a name="introduction-6"></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.4.1"></a><h3>8.4.1. 
Introduction</h3>

<p>In [RFC6749] the authorization request and responses are not integrity protected. Thus, an attacker can modify them.  
</p>
<a name="authorization-request-parameter-injection-attack"></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.4.2"></a><h3>8.4.2. 
Authorization Request parameter injection attack</h3>

<p>In [RFC6749], the authorization request is sent as query parameter. Although [RFC6749] mandates the user of TLS, the TLS is terminated in the browser and thus not protected within the browser. Leveraging on it, an attacker can tamper the authorization request and insert his own parameter values.  
</p>
<p>Attacks like Malicious Endpoint Attack requires this property to succeed.  
</p>
<p>The use of a <tt>request</tt> object or <tt>request_uri</tt> in the authorization request will prevent tampering with the request parameters.  
</p>
<p>IdP confusion attack reported in <a href='https://www.nds.rub.de/media/ei/veroeffentlichungen/2017/01/30/oidc-security.pdf'>SoK: Single Sign-On Security – An Evaluation of OpenID Connect</a> is this kind of attack.  
</p>
<a name="authorization-response-parameter-injection-attack"></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.4.3"></a><h3>8.4.3. 
Authorization Response parameter injection attack</h3>

<p>This attack occurs when the victim and attacker use the same relying party client. The attacker is somehow able to capture the authorization code and state from the victim's authorization response and uses them in his own authorization response.  
</p>
<p>This can be mitigated by using hybrid flow where the <tt>c_hash</tt>, <tt>at_hash</tt>, and <tt>s_hash</tt> can be used to verify the validity of the authorization code, access token, and state parameters. The server can verify that the state is the same as what was stored in the browser session at the time of the authorization request.  
</p>
<a name="tls-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.5"></a><h3>8.5. 
TLS considerations</h3>

<p>As confidential information is being exchanged, all interactions shall be encrypted with TLS (HTTPS).  
</p>
<p>The recommendations for Secure Use of Transport Layer Security in BCP195 shall be followed, with the following additional requirements: 
</p>
<p></p>
<ol class="text">
<li>Only the following 4 cipher suites shall be permitted: 
<ul class="text">
<li><tt>TLS_DHE_RSA_WITH_AES_128_GCM_SHA256</tt> 
</li>
<li><tt>TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256</tt> 
</li>
<li><tt>TLS_DHE_RSA_WITH_AES_256_GCM_SHA384</tt> 
</li>
<li><tt>TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384</tt> 
</li>
</ul> 
</li>
<li>TLS version 1.2 or later shall be used for all communications.  
</li>
<li>A TLS server certificate check shall be performed, as per [RFC6125].  
</li>
</ol>

<a name="jws-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.8.6"></a><h3>8.6. 
JWS algorithm considerations</h3>

<p>JWS signatures shall use the <tt>PS256</tt> or <tt>ES256</tt> algorithms for signing.  
</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.9"></a><h3>9. 
Privacy Considerations</h3>

<p></p>
<ul class="text">
<li>If the client is to be used by a single user, the client certificate will provide the means for the websites that belong to different administrative domains to collude and correlate the user's access. For this reason, public clients that reside on a user's terminal should avoid [MTLS] and use [OAUTB] instead.  
</li>
<li>When claims related to the subject are returned in the ID Token in the front channel, implementations should consider encrypting the ID Token to lower the risk of personal information disclosure.  
</li>
</ul>

<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.10"></a><h3>10. 
Acknowledgement</h3>

<p>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 (Momentum Financial Technology) -- UK Implementation Entity Liaison 
</li>
<li>Paul A. Grassi (NIST) -- X9 Liaison 
</li>
<li>Joseph Heenan (Authlete) 
</li>
<li>Sascha H. Preibisch (CA) 
</li>
<li>John Bradley (Ping Identity) 
</li>
<li>Henrik Bearing (Peercraft) 
</li>
<li>Tom Jones (Independent) 
</li>
<li>Axel Nenker (deutsche telekom) 
</li>
<li>Torsten Lodderstedt (YES) 
</li>
<li>Ralph Bragg (Raidiam) 
</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.11"></a><h3>11. 
Bibliography</h3>

<p></p>
<ul class="text">
<li>[OFX2.2] Open Financial Exchange 2.2 
</li>
<li>[HTML4.01] “HTML 4.01 Specification,” World Wide Web Consortium Recommendation REC-html401-19991224, December 1999 
</li>
<li>[RFC7662] OAuth 2.0 Token Introspection 
</li>
<li>[DDA] Durable Data API, (2015), FS-ISAC 
</li>
<li>[SoK] Mainka, C., Mladenov, V., Schwenk, J., and T. Wich: SoK: Single Sign-On Security – An Evaluation of OpenID Connect 
</li>
</ul>

<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">Nat Sakimura</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Nomura Research Institute, Ltd.</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:n-sakimura@nri.co.jp">n-sakimura@nri.co.jp</a></td></tr>
<tr><td class="author" align="right">URI: </td>
<td class="author-text"><a href="http://nat.sakimura.org/">http://nat.sakimura.org/</a></td></tr>
<tr cellpadding="3"><td> </td><td> </td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">John Bradley</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:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a></td></tr>
<tr><td class="author" align="right">URI: </td>
<td class="author-text"><a href="http://www.thread-safe.com/">http://www.thread-safe.com/</a></td></tr>
<tr cellpadding="3"><td> </td><td> </td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Edmund Jay</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Illumila</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:ejay@mgi1.com">ejay@mgi1.com</a></td></tr>
<tr><td class="author" align="right">URI: </td>
<td class="author-text"><a href="http://illumi.la/">http://illumi.la/</a></td></tr>
</table>
</body></html>