<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:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@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";}
/* 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.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.apple-converted-space
{mso-style-name:apple-converted-space;}
span.m2097250357939078632st
{mso-style-name:m2097250357939078632st;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@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:1944611680;
mso-list-template-ids:982577056;}
@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:;
mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@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:Symbol;}
@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:Symbol;}
@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:Symbol;}
@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:Symbol;}
@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:Symbol;}
@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:Symbol;}
@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:Symbol;}
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">The signed request object is like a JWT Assertion.<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"><a href="https://tools.ietf.org/html/rfc7523#section-3">https://tools.ietf.org/html/rfc7523#section-3</a>
<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">How about exp, nbf, iat ?<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">//Axel<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"><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"><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>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<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"> John Bradley [mailto:ve7jtb@ve7jtb.com]
<br>
<b>Sent:</b> Dienstag, 6. Juni 2017 18:43<br>
<b>To:</b> Nennker, Axel <Axel.Nennker@telekom.de><br>
<b>Cc:</b> dave.tonge@momentumft.co.uk; openid-specs-fapi@lists.openid.net; openid-specs-mobile-profile@lists.openid.net<br>
<b>Subject:</b> Re: [Openid-specs-mobile-profile] [Openid-specs-fapi] Initial review of MODRNA Client initiated Backchannel Authentication Flow 1.0<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">In the CIBA case the request object is sent in the back channel via a direct connection. <o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">If it can be stolen and reused then so can all the other authentication methods and so can the authentication for the token endpoint.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Is there something specific that you are thinking of that might cause the request object to leak?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">It could be a POP request object presented over MTLS but I suspect that might be overkill in most cases.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">We do have existing requirements <a href="http://openid.net/specs/openid-connect-core-1_0.html#RequestObject">http://openid.net/specs/openid-connect-core-1_0.html#RequestObject</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The audience requirement is inherited from the general request. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I could see adding a JTI to allow the IdP to do replay protection if required.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">John B.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On Jun 6, 2017, at 11:36 AM, <a href="mailto:Axel.Nennker@telekom.de">
Axel.Nennker@telekom.de</a> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Thanks, Dave.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Please see</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><a href="https://bitbucket.org/openid/mobile/commits/f7fd8bed04dcb6b74437f7ced0d34061ac69afd4"><span lang="EN-US" style="color:purple">https://bitbucket.org/openid/mobile/commits/f7fd8bed04dcb6b74437f7ced0d34061ac69afd4</span></a></span><span class="apple-converted-space"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span></span><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">for
a text change to authentication.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Latest version is (as always):</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><a href="https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/openid/mobile/raw/tip/draft-mobile-client-initiated-backchannel-authentication.xml?at=default#rfc.section.3.3.1"><span style="color:purple">https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/openid/mobile/raw/tip/draft-mobile-client-initiated-backchannel-authentication.xml?at=default#rfc.section.3.3.1</span></a></span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Although thinking longer about the signed request object I think that it could be stolen and reused. So we probably need to add additional requirement
on it like “freshness” and “aud == OP” and …</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">//Axel</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span class="apple-converted-space"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span></span><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">Dave
Tonge [<a href="mailto:dave.tonge@momentumft.co.uk"><span style="color:purple">mailto:dave.tonge@momentumft.co.uk</span></a>]<span class="apple-converted-space"> </span><br>
<b>Sent:</b><span class="apple-converted-space"> </span>Dienstag, 30. Mai 2017 12:18<br>
<b>To:</b><span class="apple-converted-space"> </span>Nennker, Axel <<a href="mailto:Axel.Nennker@telekom.de"><span style="color:purple">Axel.Nennker@telekom.de</span></a>><br>
<b>Cc:</b><span class="apple-converted-space"> </span>Openid-specs Fapi <<a href="mailto:openid-specs-fapi@lists.openid.net"><span style="color:purple">openid-specs-fapi@lists.openid.net</span></a>>;<span class="apple-converted-space"> </span><a href="mailto:openid-specs-mobile-profile@lists.openid.net"><span style="color:purple">openid-specs-mobile-profile@lists.openid.net</span></a><br>
<b>Subject:</b><span class="apple-converted-space"> </span>Re: [Openid-specs-fapi] Initial review of MODRNA Client initiated Backchannel Authentication Flow 1.0</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif">Hi Axel</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif">Thanks for the email.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-family:"Trebuchet MS",sans-serif">Signed Request Object</span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif">I'm glad for the change to recommend "Signed Request Object" although the current draft could be confusing for implementers, for example:</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"> </span><o:p></o:p></p>
</div>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif">The Client MUST authenticate to the Backchannel Authentication Endpoint using the authentication method registered for its client_id, as described in Section 9 of [OpenID.Core]. The RECOMMENDED
method to authenticate the Client is using an OpenID Connect Signed Request Object as described in OpenID.Core.</span><o:p></o:p></p>
</div>
</blockquote>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif">Section 9 of OIDC describes client authentication methods for the token endpoints (e.g client_secret_basic, client_secret_post, client_secret_jwt & private_key_jwt) - however it seems
that the CIBA spec is recommending simply sending a signed request object without using any of these 4 methods. I think this is fine and we are taking a similar approach in FAPI when defining the<span class="apple-converted-space"> </span><a href="https://bitbucket.org/openid/fapi/src/53d8de443d6727ea547fef173ee532858c183e14/Financial_API_WD_002.md?at=master&fileviewer=file-view-default#markdown-header-72-request"><span style="color:purple">request
object endpoint</span></a>. However, I think the current CIBA draft is confusing. Essentially we are defining a 5th method for client authentication - sending a signed request object</span>. It should be clear in both drafts that sending a signed request object
is the recommended method and can (should?) be used instead of the client authentication methods described in section 9 of OIDC.<o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b>Binding Message</b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">Thanks for the explanation, I'm glad I've understood the use case.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">PSD2 requires Strong Customer Authentication (i.e. multi-factor), but it has been established that this can be performed on a single device (e.g. a smartphone). PSD2 also requires dynamic linking - that is an "authentication code" (PSD2
term) is bound to a specific amount and a specific payee; however it doesn't need to be bound to a specific transaction. I think you are right that the format of the binding message is in the competitive space, however, I would like to explore whether there
is a requirement for the spec to support requiring the user to enter a binding message or code. <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">I agree with you that the binding message is to support the user, however, when it comes to payments, legislation shifts some of that liability from the user to the payment processor. If fraud occurred because a user didn't bother to compare
binding messages it would be hard for a bank to push that liability to the user. Therefore to get this spec adopted by banks and the like, we may need to provide the functionality to require a user to enter some sort of binding code - perhaps this is different
from the binding message.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">I'd be interested in Nat and John's view on this though.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">Thanks <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">Dave<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal">On 26 May 2017 at 14:21, <<a href="mailto:Axel.Nennker@telekom.de" target="_blank"><span style="color:purple">Axel.Nennker@telekom.de</span></a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Hi Dave,</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">thanks for the review!</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">The latest editor version in HTML of CIBA is always at this location:</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><a href="https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/openid/mobile/raw/tip/draft-mobile-client-initiated-backchannel-authentication.xml?at=default" target="_blank"><span style="color:purple">https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/openid/mobile/raw/tip/draft-mobile-client-initiated-backchannel-authentication.xml?at=default</span></a></span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">The raw xml2rfc version is here:<span class="apple-converted-space"> </span><a href="https://bitbucket.org/openid/mobile/raw/tip/draft-mobile-client-initiated-backchannel-authentication.xml" target="_blank"><span style="color:purple">https://bitbucket.org/openid/mobile/raw/tip/draft-mobile-client-initiated-backchannel-authentication.xml</span></a></span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">I created an issue regarding the Terminology Consumption Device:</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><a href="https://bitbucket.org/openid/mobile/issues/53/ciba-terminology-consumption-device" target="_blank"><span style="color:purple">https://bitbucket.org/openid/mobile/issues/53/ciba-terminology-consumption-device</span></a></span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Typo fixed by<span class="apple-converted-space"> </span><a href="https://bitbucket.org/openid/mobile/commits/be7ab6b50447b82dd7d77f4fc2044c101be44069" target="_blank"><span style="color:purple">https://bitbucket.org/openid/mobile/commits/be7ab6b50447b82dd7d77f4fc2044c101be44069</span></a></span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Regarding Client Authentication:</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">I see CIBA as a generic spec introducing back-channel to MODRNA Authentication or OIDC.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">So FAPI should reference CIBA if back-channel is used in FAPI AND profile CIBA to FAPI’s higher security needs</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">e.g. by restricting the Client Authentication Methods.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">We currently RECOMMEND a signed request object for request authentication while prohibiting alg=none.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><a href="https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/openid/mobile/raw/tip/draft-mobile-client-initiated-backchannel-authentication.xml?at=default#rfc.section.3.3.1" target="_blank"><span style="color:purple">https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/openid/mobile/raw/tip/draft-mobile-client-initiated-backchannel-authentication.xml?at=default#rfc.section.3.3.1</span></a></span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">The rationale is this: OAuth2 was specified as a simple authorization framework with client_id and client_secret as a simple form of client authentication.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">This was because developers and admins never managed to get the Liberty Alliance implementation right.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">So CIBA allows client_id and client_secret but use cases for Banks and PSPs need better security and should profile CIBA for better Client Authentication.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><a href="https://openid.net/specs/openid-connect-core-1_0.html#NeedForSignedRequests" target="_blank"><span style="color:purple">https://openid.net/specs/openid-connect-core-1_0.html#NeedForSignedRequests</span></a></span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Binding_message: Binding_message was introduced in<span class="apple-converted-space"> </span><a href="https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/openid/mobile/raw/tip/openid-connect-modrna-authentication-1_0.xml?at=default#rfc.section.7" target="_blank"><span style="color:purple">MODRNA
Authentication</span></a><span class="apple-converted-space"> </span>. Protects the user not the RP.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">If you want it to be MANDATORY for payments then please profile MODRNA Authentication and CIBA and specify FAPI.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">CIBA does not talk much about binding_message and binding_message potential use cases because CIBA is a quite generic protocol for back-channel authentication.<span class="apple-converted-space"> </span></span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><a href="https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/openid/mobile/raw/tip/draft-mobile-client-initiated-backchannel-authentication.xml?at=default#rfc.section.3.4" target="_blank"><span style="color:purple">https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/openid/mobile/raw/tip/draft-mobile-client-initiated-backchannel-authentication.xml?at=default#rfc.section.3.4</span></a></span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Payment and handling of binding_messages is out-of-scope for CIBA. If CIBA is used for payment transaction authorization then there probably should
be a contract between the OP and the PSP specifying how the binding_message looks like. I like your petrol station use case that is exactly what CIBA is designed for. Also I am not sure what PSD2 actually mandates to be shown at the Authentication Device.
The pump is showing the price and the binding_message “e.g. ‘</span><span class="m2097250357939078632st"><span lang="EN-US">Correct</span></span><span class="apple-converted-space"><span lang="EN-US"> </span></span><em><span lang="EN-US">Horse</span></em><span class="m2097250357939078632st"><span lang="EN-US">Battery</span></span><span class="apple-converted-space"><span lang="EN-US"> </span></span><em><span lang="EN-US">Staple</span></em><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">’”
and the binding_message is also displayed on the user’s AT to protect the user. Potential PIN entry is a separate issue. Reentering the binding_message at the pump does improve the pump’s assurance but might introduce an error prone UX. YMMW.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Regarding Token Request Validation:</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><a href="https://bitbucket.org/openid/mobile/commits/c2de67a23791bf8962602fd6746a66bef63e4168" target="_blank"><span style="color:purple">https://bitbucket.org/openid/mobile/commits/c2de67a23791bf8962602fd6746a66bef63e4168</span></a></span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">I did not reference 3.1.3 because we have no redirect_url</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Regarding the authentication of the OP at the Client Notification Endpoint:</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><a href="https://bitbucket.org/openid/mobile/issues/54/ciba-client-notification-endpoint" target="_blank"><span style="color:purple">https://bitbucket.org/openid/mobile/issues/54/ciba-client-notification-endpoint</span></a></span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Regarding signing results:</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><a href="https://bitbucket.org/openid/mobile/issues/55/ciba-signed-result-objects" target="_blank"><span style="color:purple">https://bitbucket.org/openid/mobile/issues/55/ciba-signed-result-objects</span></a></span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">kind regards</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Axel</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span class="apple-converted-space"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span></span><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">Openid-specs-fapi
[mailto:<a href="mailto:openid-specs-fapi-bounces@lists.openid.net" target="_blank"><span style="color:purple">openid-specs-fapi-bounces@lists.openid.net</span></a>]<span class="apple-converted-space"> </span><b>On Behalf Of<span class="apple-converted-space"> </span></b>Dave
Tonge via Openid-specs-fapi<br>
<b>Sent:</b><span class="apple-converted-space"> </span>Freitag, 26. Mai 2017 12:59<br>
<b>To:</b><span class="apple-converted-space"> </span>Openid-specs Fapi <<a href="mailto:openid-specs-fapi@lists.openid.net" target="_blank"><span style="color:purple">openid-specs-fapi@lists.openid.net</span></a>><br>
<b>Subject:</b><span class="apple-converted-space"> </span>[Openid-specs-fapi] Initial review of MODRNA Client initiated Backchannel Authentication Flow 1.0</span><o:p></o:p></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif">Hi all,</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"> </span><o:p></o:p></p>
</div>
</div>
<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.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"> </span><o:p></o:p></p>
</div>
</div>
<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<span class="apple-converted-space"> </span><a href="http://openid.net/specs/openid-connect-modrna-client-initiated-backchannel-authentication-1_0.html#rfc.section.4.1" target="_blank"><span style="color:purple">Backchannel
Authentication spec</span></a>:</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Arial",sans-serif">2. Terminology</span></b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Arial",sans-serif">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><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Arial",sans-serif">3. Overview</span></b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Arial",sans-serif">Spelling mistake - “inmediatly” -> “immediately”</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Arial",sans-serif">4.1 Authentication Request</span></b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Arial",sans-serif">Client Authentication - this should be restricted to the methods listed in FAPI (i.e. private_key_jwt or MTLS)</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Arial",sans-serif">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><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Arial",sans-serif">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><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Arial",sans-serif">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 class="apple-converted-space"> </span></span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Arial",sans-serif">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><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Arial",sans-serif">The binding message should be required and not optional for payments.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Arial",sans-serif">4.2.1 Authentication Request Validation</span></b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Arial",sans-serif">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><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Arial",sans-serif">5. OpenID Provider Obtains End-user Consent/Authorization</span></b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Arial",sans-serif">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 class="apple-converted-space"> </span></span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Arial",sans-serif">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 class="apple-converted-space"> </span></span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Arial",sans-serif">6.1 Token Request Using Polling Mechanism</span></b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Arial",sans-serif">The spec should refer back to OIDC Core - 3.1.3 - token endpoint - as all the verification steps described there should be performed.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Arial",sans-serif">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><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Arial",sans-serif">6.2 Successful Token Polling Response</span></b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Arial",sans-serif">To conform with FAPI, the tokens returned in this response should be bound to the client either using MTLS or OATB.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Arial",sans-serif">6.3.1 Succesful Token Notification</span></b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Arial",sans-serif">As per the notes on client_notification_token, I suggest that this payload is signed to ensure source authentication and integrity.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Arial",sans-serif">Other notes:</span><o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-left:36.0pt;vertical-align:baseline">
<span style="font-size:10.0pt;font-family:Symbol">·</span><span style="font-size:7.0pt"> <span class="apple-converted-space"> </span></span><span style="font-size:11.0pt;font-family:"Arial",sans-serif">No mention of what happens if the client notification
endpoint is down (e.g. retries)</span><o:p></o:p></p>
<ul style="margin-top:0cm" type="disc">
<li class="MsoNormal" style="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</span><o:p></o:p></li></ul>
</div>
<div>
<p class="MsoNormal"><br clear="all">
<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif">_________</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial",sans-serif"></span><o:p></o:p></p>
</div>
</div>
</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.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"> </span><o:p></o:p></p>
</div>
</div>
<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. </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"> </span><o:p></o:p></p>
</div>
</div>
<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. </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif">Thanks</span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal">--<o:p></o:p></p>
</div>
<div>
<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";color:#00A4B7">Dave Tonge</span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:8.5pt;font-family:"Open Sans";color:#333333">CTO</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:8.5pt;font-family:"Open Sans";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="m_2097250357939078632_x005f_x0000_i1025" src="http://content.moneyhub.co.uk/images/teal_Moneyhub-Ent_logo_200x50.png" alt="Moneyhub Enterprise"></span></a></span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:8.5pt;font-family:"Open Sans";color:#00A4B7">10 Temple Back, Bristol, BS1 6FL</span><o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><b><span style="font-size:8.5pt;font-family:"Open Sans";color:#00A4B7">t: </span></b><span style="font-size:8.5pt;font-family:"Open Sans";color:#333333">+44 (0)117 280 5120</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Open Sans";color:#616161"> </span><o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:8.0pt;font-family:"Open Sans";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";color:#00A4B7">561538</span></b><span style="font-size:8.0pt;font-family:"Open Sans";color:#333333">) at<span class="apple-converted-space"> </span><a href="http://fca.org.uk/register" target="_blank"><span style="color:purple">fca.org.uk/register</span></a>.
Momentum Financial Technology is registered in England & Wales, company registration number </span><b><span style="font-size:8.0pt;font-family:"Open Sans";color:#00A4B7">06909772</span></b><span style="font-size:8.0pt;font-family:"Open Sans";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";color:#333333"> . Momentum
Financial Technology Limited 2016. </span><span style="font-size:8.0pt;font-family:"Open Sans";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><o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<div>
<p class="MsoNormal"><br>
<br clear="all">
<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal">--<span class="apple-converted-space"> </span><o:p></o:p></p>
</div>
<div>
<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";color:#00A4B7">Dave Tonge</span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:8.5pt;font-family:"Open Sans";color:#333333">CTO</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:8.5pt;font-family:"Open Sans";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_i1026" src="http://content.moneyhub.co.uk/images/teal_Moneyhub-Ent_logo_200x50.png" alt="Moneyhub Enterprise"></span></a></span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:8.5pt;font-family:"Open Sans";color:#00A4B7">10 Temple Back, Bristol, BS1 6FL</span><o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><b><span style="font-size:8.5pt;font-family:"Open Sans";color:#00A4B7">t: </span></b><span style="font-size:8.5pt;font-family:"Open Sans";color:#333333">+44 (0)117 280 5120</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Open Sans";color:#616161"> </span><o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:8.0pt;font-family:"Open Sans";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";color:#00A4B7">561538</span></b><span style="font-size:8.0pt;font-family:"Open Sans";color:#333333">) at<span class="apple-converted-space"> </span><a href="http://fca.org.uk/register" target="_blank"><span style="color:purple">fca.org.uk/register</span></a>.
Momentum Financial Technology is registered in England & Wales, company registration number </span><b><span style="font-size:8.0pt;font-family:"Open Sans";color:#00A4B7">06909772</span></b><span style="font-size:8.0pt;font-family:"Open Sans";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";color:#333333"> . Momentum
Financial Technology Limited 2016. </span><span style="font-size:8.0pt;font-family:"Open Sans";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><o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">_______________________________________________<br>
Openid-specs-mobile-profile mailing list<br>
</span><a href="mailto:Openid-specs-mobile-profile@lists.openid.net"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif;color:purple">Openid-specs-mobile-profile@lists.openid.net</span></a><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><br>
</span><a href="http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif;color:purple">http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile</span></a><o:p></o:p></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</body>
</html>