<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
        {font-family:Wingdings;
        panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:"Trebuchet MS";
        panose-1:2 11 6 3 2 2 2 2 2 4;}
@font-face
        {font-family:"Open Sans";
        panose-1:0 0 0 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p
        {mso-style-priority:99;
        mso-margin-top-alt:auto;
        margin-right:0cm;
        mso-margin-bottom-alt:auto;
        margin-left:0cm;
        font-size:12.0pt;
        font-family:"Times New Roman",serif;}
p.msonormal0, li.msonormal0, div.msonormal0
        {mso-style-name:msonormal;
        mso-margin-top-alt:auto;
        margin-right:0cm;
        mso-margin-bottom-alt:auto;
        margin-left:0cm;
        font-size:12.0pt;
        font-family:"Times New Roman",serif;}
span.hoenzb
        {mso-style-name:hoenzb;}
span.EmailStyle20
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri",sans-serif;
        mso-fareast-language:EN-US;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.WordSection1
        {page:WordSection1;}
/* List Definitions */
@list l0
        {mso-list-id:406270111;
        mso-list-template-ids:414376672;}
@list l0:level1
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:36.0pt;
        mso-level-number-position:left;
        text-indent:-18.0pt;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l0:level2
        {mso-level-number-format:bullet;
        mso-level-text:o;
        mso-level-tab-stop:72.0pt;
        mso-level-number-position:left;
        text-indent:-18.0pt;
        mso-ansi-font-size:10.0pt;
        font-family:"Courier New";
        mso-bidi-font-family:"Times New Roman";}
@list l0:level3
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:108.0pt;
        mso-level-number-position:left;
        text-indent:-18.0pt;
        mso-ansi-font-size:10.0pt;
        font-family:Wingdings;}
@list l0:level4
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:144.0pt;
        mso-level-number-position:left;
        text-indent:-18.0pt;
        mso-ansi-font-size:10.0pt;
        font-family:Wingdings;}
@list l0:level5
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:180.0pt;
        mso-level-number-position:left;
        text-indent:-18.0pt;
        mso-ansi-font-size:10.0pt;
        font-family:Wingdings;}
@list l0:level6
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:216.0pt;
        mso-level-number-position:left;
        text-indent:-18.0pt;
        mso-ansi-font-size:10.0pt;
        font-family:Wingdings;}
@list l0:level7
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:252.0pt;
        mso-level-number-position:left;
        text-indent:-18.0pt;
        mso-ansi-font-size:10.0pt;
        font-family:Wingdings;}
@list l0:level8
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:288.0pt;
        mso-level-number-position:left;
        text-indent:-18.0pt;
        mso-ansi-font-size:10.0pt;
        font-family:Wingdings;}
@list l0:level9
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:324.0pt;
        mso-level-number-position:left;
        text-indent:-18.0pt;
        mso-ansi-font-size:10.0pt;
        font-family:Wingdings;}
ol
        {margin-bottom:0cm;}
ul
        {margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="DE" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">Below some harsh but unspecific critique on our UQ spec by an FAPI member.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Openid-specs-fapi [mailto:openid-specs-fapi-bounces@lists.openid.net]
<b>On Behalf Of </b>Tom Jones via Openid-specs-fapi<br>
<b>Sent:</b> Freitag, 26. Mai 2017 17:45<br>
<b>To:</b> Dave Tonge <dave.tonge@momentumft.co.uk>; Financial API Working Group List <openid-specs-fapi@lists.openid.net><br>
<b>Subject:</b> Re: [Openid-specs-fapi] Initial review of MODRNA Client initiated Backchannel Authentication Flow 1.0<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">I don't believe that the questioning spec meets any of:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">1. its own requirements, e.g. non-repudiation<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">2. strong ID of the client, the OP, the end user or the user agent are not specified.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">3. So far as I can tell the acr that it does use requires a level of sophistication by the user that is not even conceivable e. g. "Parties using this claim will need to agree upon the meanings of the values used, which may be context-specific"
 (from OpenID Connect core).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">4. The end user's consent to the questioning process is not even considered as important, let alone solved.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">5. Since the spec doesn't deal with strong IDs, I doubt it should even have been approved by Open ID in the first place.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">..tom<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Fri, May 26, 2017 at 3:59 AM, Dave Tonge via Openid-specs-fapi <<a href="mailto:openid-specs-fapi@lists.openid.net" target="_blank">openid-specs-fapi@lists.openid.net</a>> wrote:<o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif">Hi all,<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif">We discussed on the last call that it would be good to review the MODRNA backchannel auth and user questioning specs from a FAPI perspective.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif">I've started to go through them both and here are my initial thoughts on the
<a href="http://openid.net/specs/openid-connect-modrna-client-initiated-backchannel-authentication-1_0.html#rfc.section.4.1" target="_blank">
Backchannel Authentication spec</a>:<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p style="margin:0cm;margin-bottom:.0001pt"><b><span style="font-size:11.0pt;font-family:"Arial",sans-serif;color:black">2. Terminology</span></b><span style="font-family:"Trebuchet MS",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"><o:p> </o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt"><span style="font-size:11.0pt;font-family:"Arial",sans-serif;color:black">The definition for Consumption Device states that it is “most probably a browser”. It is envisaged that this will often not be the case, for
 payment APIs, e.g. the flow could be initiated via a POS device.</span><span style="font-family:"Trebuchet MS",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"><o:p> </o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt"><b><span style="font-size:11.0pt;font-family:"Arial",sans-serif;color:black">3. Overview</span></b><span style="font-family:"Trebuchet MS",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"><o:p> </o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt"><span style="font-size:11.0pt;font-family:"Arial",sans-serif;color:black">Spelling mistake - “inmediatly” -> “immediately”</span><span style="font-family:"Trebuchet MS",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"><o:p> </o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt"><b><span style="font-size:11.0pt;font-family:"Arial",sans-serif;color:black">4.1 Authentication Request
</span></b><span style="font-family:"Trebuchet MS",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"><o:p> </o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt"><span style="font-size:11.0pt;font-family:"Arial",sans-serif;color:black">Client Authentication - this should be restricted to the methods listed in FAPI (i.e. private_key_jwt or MTLS)</span><span style="font-family:"Trebuchet MS",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"><o:p> </o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt"><span style="font-size:11.0pt;font-family:"Arial",sans-serif;color:black">Client_notification_token - this is a bearer token used by the OP when notifying the client via the `client_notification_endpoint`. In the
 FAPI spec we are moving away from bearer tokens to either sender contained tokens or OATB tokens. While this token is used for OP -> client rather than client -> OP should we still consider constraining the tokens?
</span><span style="font-family:"Trebuchet MS",sans-serif"><o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt"><span style="font-family:"Trebuchet MS",sans-serif"><o:p> </o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt"><span style="font-size:11.0pt;font-family:"Arial",sans-serif;color:black">A simpler approach may be to ensure that the OP signs any payload sent to the `client_notification_endpoint`. Currently, these payloads (error
 or success) are plain JSON payloads. The success payload contains an `id_token`, but this token contains claims about the identity of the user rather than acting as a detached signature for the access token (and refresh token)</span><span style="font-family:"Trebuchet MS",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"><o:p> </o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt"><span style="font-size:11.0pt;font-family:"Arial",sans-serif;color:black">Binding_message - as I understand it the binding message is shown to the user on both the consumption and the authentication device. The spec
 then relies on the user checking that both messages are the same. If the spec were to be used for payments then I would suggest that the binding message is shown on the consumption device and entered by the user on the authentication device. This would be
 more secure than relying on the user to cross-check both messages are the same. </span>
<span style="font-family:"Trebuchet MS",sans-serif"><o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt"><span style="font-family:"Trebuchet MS",sans-serif"><o:p> </o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt"><span style="font-size:11.0pt;font-family:"Arial",sans-serif;color:black">For example, this spec could be used to support bank payments at a petrol station - the user could enter their phone number into the POS device,
 they would then receive a notification from their banking app asking them to authorise a payment. However what is to prevent someone entering the user’s phone number at the same time at the same petrol station when paying for fuel of the same amount. If the
 POS device displayed a 6 digit pin to the user, and the user entered that pin as part of the authorization flow in their banking app, then all parties would have a higher degree of confidence about the transaction.</span><span style="font-family:"Trebuchet MS",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"><o:p> </o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt"><span style="font-size:11.0pt;font-family:"Arial",sans-serif;color:black">The binding message should be required and not optional for payments.</span><span style="font-family:"Trebuchet MS",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"><o:p> </o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt"><b><span style="font-size:11.0pt;font-family:"Arial",sans-serif;color:black">4.2.1 Authentication Request Validation</span></b><span style="font-size:11.0pt;font-family:"Arial",sans-serif;color:black">
</span><span style="font-family:"Trebuchet MS",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"><o:p> </o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt"><span style="font-size:11.0pt;font-family:"Arial",sans-serif;color:black">The authentication request is a plain JSON payload, but because this is happening over a channel protected by client authentication this should
 be sufficient.</span><span style="font-family:"Trebuchet MS",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"><o:p> </o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt"><b><span style="font-size:11.0pt;font-family:"Arial",sans-serif;color:black">5. OpenID Provider Obtains End-user Consent/Authorization</span></b><span style="font-family:"Trebuchet MS",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"><o:p> </o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt"><span style="font-size:11.0pt;font-family:"Arial",sans-serif;color:black">The spec is focussed on user authentication rather than a user authorising a specific action, e.g. making a payment. The wording in this section
 could be confusing to those implementing it for a financial API. </span><span style="font-family:"Trebuchet MS",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"><o:p> </o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt"><span style="font-size:11.0pt;font-family:"Arial",sans-serif;color:black">In order to support fine-grained authorisation, the spec would need to support the OIDC claims parameter and guidance would need to be provided
 to implementers on example flows for payments and account information access. </span>
<span style="font-family:"Trebuchet MS",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"><o:p> </o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt"><b><span style="font-size:11.0pt;font-family:"Arial",sans-serif;color:black">6.1 Token Request Using Polling Mechanism</span></b><span style="font-family:"Trebuchet MS",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"><o:p> </o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt"><span style="font-size:11.0pt;font-family:"Arial",sans-serif;color:black">The spec should refer back to OIDC Core - 3.1.3 - token endpoint - as all the verification steps described there should be performed.
</span><span style="font-family:"Trebuchet MS",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"><o:p> </o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt"><span style="font-size:11.0pt;font-family:"Arial",sans-serif;color:black">In addition, it should be made clear in the spec that the `auth_req_id` MUST be bound to the client to which it was issued. At the moment it
 would seem that any client could send any `auth_req_id`.</span><span style="font-family:"Trebuchet MS",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"><o:p> </o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt"><b><span style="font-size:11.0pt;font-family:"Arial",sans-serif;color:black">6.2 Successful Token Polling Response</span></b><span style="font-family:"Trebuchet MS",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"><o:p> </o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt"><span style="font-size:11.0pt;font-family:"Arial",sans-serif;color:black">To conform with FAPI, the tokens returned in this response should be bound to the client either using MTLS or OATB.</span><span style="font-family:"Trebuchet MS",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"><o:p> </o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt"><b><span style="font-size:11.0pt;font-family:"Arial",sans-serif;color:black">6.3.1 Succesful Token Notification</span></b><span style="font-family:"Trebuchet MS",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"><o:p> </o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt"><span style="font-size:11.0pt;font-family:"Arial",sans-serif;color:black">As per the notes on client_notification_token, I suggest that this payload is signed to ensure source authentication and integrity.
</span><span style="font-family:"Trebuchet MS",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"><o:p> </o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt"><span style="font-size:11.0pt;font-family:"Arial",sans-serif;color:black">Other notes:</span><span style="font-family:"Trebuchet MS",sans-serif"><o:p></o:p></span></p>
<p style="mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:0cm;margin-left:36.0pt;margin-bottom:.0001pt;text-indent:-18.0pt;mso-list:l0 level1 lfo1;vertical-align:baseline">
<![if !supportLists]><span style="font-size:10.0pt;font-family:Symbol;color:black"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman""> 
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Arial",sans-serif;color:black">No mention of what happens if the client notification endpoint is down (e.g. retries)<o:p></o:p></span></p>
<ul type="disc">
<li class="MsoNormal" style="color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1;vertical-align:baseline">
<span style="font-size:11.0pt;font-family:"Arial",sans-serif">No mention of what acknowledgement the client should give to the OP when it receives a notification<o:p></o:p></span></li></ul>
</div>
<p class="MsoNormal"><br clear="all">
<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif">_________<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial",sans-serif">​</span><span style="font-family:"Trebuchet MS",sans-serif"><o:p></o:p></span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif">I believe that this spec could be useful for Financial APIs, however, it is more coupled to OIDC than the current FAPI drafts. It could be that we have to draft a new part to the FAPI
 spec that references this spec, but is more in line with the rest of the FAPI draft and geared towards the use-case of financial APIs.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif">I have started a review of the user questioning API and will send that to the list shortly. However, on initial inspection, it doesn't result in access tokens being issued to the client
 and would, therefore, be unsuitable for "account information" access. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif">This was my first review of the MODRNA specs and I may well have misinterpreted some of the specs. I hope that members of this group or are also members of the MODRNA group will help to
 correct any mistakes I may have made. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif">Thanks<o:p></o:p></span></p>
</div>
</div>
<div>
<p class="MsoNormal"><span style="color:#888888"><o:p> </o:p></span></p>
</div>
<p class="MsoNormal"><span class="hoenzb"><span style="color:#888888">-- </span><o:p></o:p></span></p>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:10.5pt;font-family:"Open Sans",serif;color:#00A4B7">Dave Tonge<o:p></o:p></span></b></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:8.5pt;font-family:"Open Sans",serif;color:#333333">CTO<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:8.5pt;font-family:"Open Sans",serif;color:#333333"><a href="http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A" target="_blank"><span style="color:#835EA5;text-decoration:none"><img border="0" width="200" height="50" style="width:2.0833in;height:.5208in" id="_x0000_i1025" src="http://content.moneyhub.co.uk/images/teal_Moneyhub-Ent_logo_200x50.png" alt="Moneyhub Enterprise"></span></a><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:8.5pt;font-family:"Open Sans",serif;color:#00A4B7">10 Temple Back, Bristol, BS1 6FL</span><span style="font-size:10.5pt;font-family:"Open Sans",serif;color:#333333"><o:p></o:p></span></p>
</div>
<p class="MsoNormal"><b><span style="font-size:8.5pt;font-family:"Open Sans",serif;color:#00A4B7">t: </span></b><span style="font-size:8.5pt;font-family:"Open Sans",serif;color:#333333"><a href="tel:+44%20117%20280%205120" target="_blank">+44 (0)117 280 5120</a></span><span style="font-size:10.5pt;font-family:"Open Sans",serif;color:#333333"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Open Sans",serif;color:#616161"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-size:8.0pt;font-family:"Open Sans",serif;color:#333333">Moneyhub Enterprise is a trading style of Momentum Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Momentum
 Financial Technology is entered on the Financial Services Register (FRN </span><b><span style="font-size:8.0pt;font-family:"Open Sans",serif;color:#00A4B7">561538</span></b><span style="font-size:8.0pt;font-family:"Open Sans",serif;color:#333333">) at
<a href="http://fca.org.uk/register" target="_blank">fca.org.uk/register</a>. Momentum Financial Technology is registered in England & Wales, company registration number </span><b><span style="font-size:8.0pt;font-family:"Open Sans",serif;color:#00A4B7">06909772</span></b><span style="font-size:8.0pt;font-family:"Open Sans",serif;color:#333333"> </span><span style="font-size:7.5pt;font-family:"Arial",sans-serif;color:#222222">©</span><span style="font-size:8.0pt;font-family:"Open Sans",serif;color:#333333"> . Momentum
 Financial Technology Limited 2016. </span><span style="font-size:8.0pt;font-family:"Open Sans",serif;color:#888888">DISCLAIMER: This email (including any attachments) is subject to copyright, and the information in it is confidential. Use of this email or
 of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made to ensure that any attachments are virus-free, it is the recipient's sole responsibility to scan all attachments for viruses. All calls and
 emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's business. Any opinions expressed in this email (or in any attachments) are those of the author and do not necessarily represent the opinions of
 Momentum Financial Technology Limited or of any other group company.</span><span style="font-size:10.5pt;font-family:"Open Sans",serif;color:#333333"><o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
_______________________________________________<br>
Openid-specs-fapi mailing list<br>
<a href="mailto:Openid-specs-fapi@lists.openid.net">Openid-specs-fapi@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-fapi" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-fapi</a><o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal"><br>
<br clear="all">
<br>
-- <o:p></o:p></p>
<div>
<p class="MsoNormal">..tom<o:p></o:p></p>
</div>
</div>
</div>
</body>
</html>