<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title></title>
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; font-family: Calibri, sans-serif; font-size: 14px; color: rgb(0, 0, 0);">
<div>Hi Guys,</div>
<div><br>
</div>
<div>We agreed to find out a solution for the Server initiation authentication, below you can find a first analyse with some possible solutions to discuss. I have added some diagrams to illustrate them (probably they have some errors).</div>
<div><br>
</div>
<div>Tomorrow I am travelling to Brazil and I am not sure If I will be able to attend our call, but I will try it.</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><b>SEVER INITIATION AUTH</b></div>
<div>
<div style="font-family: 'Helvetica Neue';"><br>
</div>
<div style="font-family: 'Helvetica Neue';">As the authorisation code flow is a flow based on redirections, the client need to be able to follow HTTP redirections, this is something obvious for a web browser and nowadays is not a problem for a server because
there are libraries in almost all the languages able to do it. Just using a parameter (e.g: prompt= RP or prompt= server, …) to indicate to the Identity Provider that the interaction is initiated by a sever will be sufficient to not send any html in the response
to be rendered in the client side.</div>
<span style="font-family: 'Helvetica Neue';">
<div> </div>
<div>However the key problem is when the user is being authenticated by the selected authenticator, this interaction happens with a direct call from the client to the authenticator (or adapter), and, as the authentication takes place in a mobile device, it
could takes a long time, what force us to return an HTTP 200 OK response immediately, and ends up in the redirection flow cut. When the client is a web browser this is not a problem because the 200 OK response can contain a body with a javascript code that
will be executed in the browser to continue with the interactions without needing any additional code in the server side, that is, the client is only worried about making the
<b>GET /authroize</b> request and the <b>POST /Token</b> request.</div>
<div><br>
</div>
<div>In case we don’t have a web browser in the client side but a server, we need somehow to avoid the communication cut and allow the client (server) to continue with an http flow to be able to receive the final redirection with the code and then get the token
with the <b>POST /Token</b> request. To solve this problem I would consider the follow options:</div>
<div><br>
</div>
<div><br>
</div>
<table style="border-collapse: collapse; width: 100%; table-layout: fixed; margin-left: 0px; font-size: 14px;">
<tbody>
<tr>
<td style="border-style:solid;border-width:1px;border-color:rgb(219,219,219);padding:10px;margin:0px;width:33.33%;">
<div>OPTIONS</div>
</td>
<td style="border-style:solid;border-width:1px;border-color:rgb(219,219,219);padding:10px;margin:0px;width:33.33%;">
<div>PROS</div>
</td>
<td style="border-style:solid;border-width:1px;border-color:rgb(219,219,219);padding:10px;margin:0px;width:33.33%;">
<div>CONS</div>
</td>
</tr>
<tr>
<td style="border-style:solid;border-width:1px;border-color:rgb(219,219,219);padding:10px;margin:0px;width:33.33%;">
<div><b>Extend the Authentication flow with an standard Polling endpoint</b>: we would need to standardise the initial response to an authenticator, returning a TransactionID, (maybe with more parameters like interval, instant, etc) (step 4) when the authenticator
receives the request to authenticate the user. The RP in this case shall poll the ID-GW until it gets a redirection response with the code to get the Token. The ID-GW must also not return </div>
</td>
<td style="border-style:solid;border-width:1px;border-color:rgb(219,219,219);padding:10px;margin:0px;width:33.33%;">
<div>- Easy to implement</div>
</td>
<td style="border-style:solid;border-width:1px;border-color:rgb(219,219,219);padding:10px;margin:0px;width:33.33%;">
<div>- Needs a little implementation on the Server (Relay Party)</div>
<div>- Needs to implement something on the Identity Provider (authenticators or adapters) to differentiate the server initiated case and not render any HTML.</div>
<div>- Impact on the RP server performance</div>
</td>
</tr>
<tr>
<td style="border-style:solid;border-width:1px;border-color:rgb(219,219,219);padding:10px;margin:0px;width:33.33%;">
<div><b>Extend the Authentication flow with Polling redirection</b>: in this case the ID-GW would return a redirection to automatically poll the result of the authentication, each poll request would return in turn other redirection with another poll request
in case the authentication is still ongoing or with the code to get the Token in case the authentication is already done.</div>
</td>
<td style="border-style:solid;border-width:1px;border-color:rgb(219,219,219);padding:10px;margin:0px;width:33.33%;">
<div>- Easy to implement</div>
<div>- No need any additional implementations or modifications on the </div>
</td>
<td style="border-style:solid;border-width:1px;border-color:rgb(219,219,219);padding:10px;margin:0px;width:33.33%;">
<div>- Needs to implement something on the Identity Provider (authenticators or adapters) to differentiate the server initiated case and not render any HTML.</div>
<div>- Impact on the RP server performance.</div>
</td>
</tr>
<tr>
<td style="border-style:solid;border-width:1px;border-color:rgb(219,219,219);padding:10px;margin:0px;width:33.33%;">
<div><b>Headless web-browser</b>: use a library in the server side that behaves like a web browser but without graphic interface. Here you can find an exhaust list of them: <a href="https://github.com/dhamaniasad/HeadlessBrowsers">https://github.com/dhamaniasad/HeadlessBrowsers</a>.</div>
</td>
<td style="border-style:solid;border-width:1px;border-color:rgb(219,219,219);padding:10px;margin:0px;width:33.33%;">
<div>- No need any additional implementations or modifications on the Identity Provider nor in the Relay Party</div>
</td>
<td style="border-style:solid;border-width:1px;border-color:rgb(219,219,219);padding:10px;margin:0px;width:33.33%;">
<div>- They usually have limitations: we would need them to be able to offer an API and </div>
</td>
</tr>
<tr>
<td style="border-style:solid;border-width:1px;border-color:rgb(219,219,219);padding:10px;margin:0px;width:33.33%;">
<div><b>New Authentication flow</b>: it would consist of a new Oauth flow to initiate an authorisation request with an HTTP POST request from a backend. The request would be authenticated and it would allow to return the token without needing an intermediate
code.</div>
</td>
<td style="border-style:solid;border-width:1px;border-color:rgb(219,219,219);padding:10px;margin:0px;width:33.33%;">
<div>- The Relay Party can receive the token directly without any code interchange.</div>
</td>
<td style="border-style:solid;border-width:1px;border-color:rgb(219,219,219);padding:10px;margin:0px;width:33.33%;">
<div>- New OAut 2.0 flow. It is necessary to modify an standard.</div>
<div>- Needs implementation in the server side (Relay Party)</div>
<div>- Needs implementation in the Identity Provider: the authenticators must be exposed with API’s instead of using redirections.</div>
</td>
</tr>
</tbody>
</table>
<div><br>
</div>
<div><br>
</div>
<div><b>Standardising a Polling Endpoint</b></div>
<div><br>
</div>
<div><br>
</div>
<div><img style="height: auto;" src="cid:085B653B-16CC-4BC4-AA59-679A185C78ED" data-en-img-selected="true" type="image/png" width="1200.000000" height="904.000000"></div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><b>Polling Redirection</b></div>
<div><br>
</div>
<div><img style="height: auto;" src="cid:4FAC7AFE-1DD3-4FFC-BB45-E25D51FA1EF6" data-en-img-selected="true" type="image/png" width="1200.000000" height="904.000000"></div>
<div><br>
</div>
<div><b>New Oauth 2.0 Flow</b></div>
<div><br>
</div>
<div><img style="height: auto;" src="cid:6BDE2D0D-76E8-425F-8294-2FFF94A22F08" data-en-img-selected="true" type="image/png" width="1200.000000" height="706.000000"></div>
</span></div>
<div><br>
</div>
<div>Best,</div>
<div>Gonza.</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<br>
<hr>
<font face="Arial" color="Gray" size="1"><br>
Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la
lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.<br>
<br>
The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.<br>
<br>
Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a
leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição<br>
</font>
</body>
</html>