<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">The token endpoint is used to authenticate the user in several flows.<div class=""><br class=""></div><div class="">Most notably the RO Credentials flow that is unfortunately widely used.</div><div class=""><br class=""></div><div class="">I personally still think that this use case is much closer to the JWT assertion flow that uses the token endpoint and is used by many API providers like Google.</div><div class=""><br class=""></div><div class="">In that case the client would create a signed JWT Connect request object, and send that to the token endpoint. It could then wait for a reply or get a response and poll. </div><div class=""><br class=""></div><div class="">We did discuss that option at the last face to face meeting.</div><div class=""><br class=""></div><div class="">To your question yes we could create a new response mode like “direct" that would return the response in the body like we do from the token endpoint for responses.</div><div class=""><br class=""></div><div class="">I do think that eliminating the registered redirect forces us to consider signed requests, so that we are not creating new security issues.</div><div class=""><br class=""></div><div class="">It is the openID core spec that requires exact redirect URI matching. Anything else is a violation of the spec. </div><div class=""><br class=""></div><div class="">The OAuth allows query parameters to be excluded from the match for the code flow. </div><div class=""><br class=""></div><div class="">There have been some large number of attacks that take advantage of pattern matching.</div><div class="">The OAuth WG is likely going to recommend that RP create a IdP specific redirect URI and that the IDP must do exact matching on it.</div><div class=""><br class=""></div><div class="">This was one of the outcomes of the OAuth security conference in July.</div><div class=""><br class=""></div><div class="">John B.</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Sep 2, 2016, at 2:25 PM, GONZALO FERNANDEZ RODRIGUEZ <<a href="mailto:gonzalo.fernandezrodriguez@telefonica.com" class="">gonzalo.fernandezrodriguez@telefonica.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; font-size: 14px; font-family: Calibri, sans-serif;" class="">
<div class="">
<div class="">Hi Torsten,</div>
<div class=""><br class="">
</div>
<div class="">I get you, however I don’t see such problem. It is true that the current flows are based on redirections, but it doesn’t mean that is necessary to have another different endpoint. What is the reason? Is it some consistency in the design?</div>
<div class=""><br class="">
</div>
<div class="">For me the endpoint is only an entry point and it should have a decoupled implementation depending on the flow to follow. If you consider the semantic is more clear for the RP to use the endpoint authorise instead of using the token endpoint, follow your
same argument, the token endpoint has not been designed to authenticate the user, I don’t see it as candidate. I don’t mine to use another different endpoint if we consider that is a better design.</div>
<div class=""><br class="">
</div>
<div class="">Best,</div>
<div class="">Gonza.</div>
<div class="">
<div id="MAC_OUTLOOK_SIGNATURE" class=""></div>
</div>
</div>
<div class=""><br class="">
</div>
<span id="OLK_SRC_BODY_SECTION" class="">
<div style="font-family: Calibri; font-size: 12pt; text-align: left; border-width: 1pt medium medium; border-style: solid none none; padding: 3pt 0in 0in; border-top-color: rgb(181, 196, 223);" class="">
<span style="font-weight:bold" class="">From: </span>Torsten Lodderstedt<br class="">
<span style="font-weight:bold" class="">Date: </span>Friday 2 September 2016 at 18:15<br class="">
<span style="font-weight:bold" class="">To: </span>Gonzalo Fernández, John Bradley, Openid-specs-mobile-profile<br class="">
<span style="font-weight:bold" class="">Subject: </span>Re: [Openid-specs-mobile-profile] Notes from Moderna Aug 24<br class="">
</div>
<div class=""><br class="">
</div>
<div class="">
<div text="#000000" bgcolor="#FFFFFF" class="">Hi Gonzalo,<br class="">
<br class="">
I'm a bit confused about the discussion about response mode vs response type vs scope because I understand why the client is supposed to send the requests to the authorization endpoint. This endpoint is explicitely designed for redirect-based frontchannel flow,
the exact opposite from what we are talking about in the context of backchannel authentication. The current proposal also does not comply with the current authz response.
<br class="">
<br class="">
I think it would be a better solution to either send the first request to the tokens endpoint or (even better) to use a distinct (new) endpoint to initialize the process.<br class="">
<br class="">
best regards,<br class="">
Torsten. <br class="">
<br class="">
Am 02.09.2016 um 15:35 schrieb GONZALO FERNANDEZ RODRIGUEZ:<br class="">
<blockquote cite="mid:2EB9BD09-E98D-4461-9E32-20265888DC07@telefonica.com" type="cite" class="">
<div class="">
<div class="">Hi John,</div>
<div class=""><br class="">
</div>
<div class="">First of all many thanks for the minutes.</div>
<div class=""><br class="">
</div>
<div class="">The las Wednesday we were talking about this draft in the GSMA meeting with operators and Mickäel Vasselet from Orange suggested to use the response_mode instead of the scope value openidserver for signalling the flow. I read the spec and it says</div>
<div class=""><br class="">
</div>
<div class=""><dt style="font-family: verdana, charcoal, helvetica,
arial, sans-serif; font-size: small; font-variant-ligatures:
normal; line-height: normal; orphans: 2; widows: 2;
background-color: rgb(255, 255, 255);" class="">
response_mode </dt><dd style="font-family: verdana, charcoal, helvetica, arial,
sans-serif; font-size: small; font-variant-ligatures:
normal; line-height: normal; orphans: 2; widows: 2;
background-color: rgb(255, 255, 255);" class="">
OPTIONAL. Informs the Authorization Server of the mechanism to be used for returning parameters from the Authorization Endpoint. This use of this parameter is NOT RECOMMENDED when the Response Mode that would be requested is the default mode specified for the
Response Type. </dd></div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class="">In our last call, John suggested to use a new response_type instead of a scope value, so I think we can define a default mode for the new response_type that returns id_token and access_token. Is this ok?, Anyone would like suggesting a name for the new
response_type?</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class="">Best,</div>
<div class="">Gonza.</div>
<div class=""></div>
</div>
<div class=""><br class="">
</div>
<span id="OLK_SRC_BODY_SECTION" class="">
<div style="font-family: Calibri; font-size: 12pt; text-align: left; border-width: 1pt medium medium; border-style: solid none none; padding: 3pt 0in 0in; border-top-color: rgb(181, 196, 223);" class="">
<span style="font-weight:bold" class="">From: </span>Openid-specs-mobile-profile <<a moz-do-not-send="true" href="mailto:openid-specs-mobile-profile-bounces@lists.openid.net" class="">openid-specs-mobile-profile-bounces@lists.openid.net</a>> on behalf of John Bradley <<a moz-do-not-send="true" href="mailto:ve7jtb@ve7jtb.com" class="">ve7jtb@ve7jtb.com</a>><br class="">
<span style="font-weight:bold" class="">Date: </span>miércoles, 24 de agosto de 2016, 19:03<br class="">
<span style="font-weight:bold" class="">To: </span>Openid-specs-mobile-profile <<a moz-do-not-send="true" href="mailto:openid-specs-mobile-profile@lists.openid.net" class="">openid-specs-mobile-profile@lists.openid.net</a>><br class="">
<span style="font-weight:bold" class="">Subject: </span>[Openid-specs-mobile-profile] Notes from Moderna Aug 24<br class="">
</div>
<div class=""><br class="">
</div>
<span style="mso-bookmark:_MailOriginalBody" class="">
<div class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space;
-webkit-line-break: after-white-space;" class="">
<br class="">
<div class=""><br class="">
<div class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode:
space; -webkit-line-break: after-white-space;" class="">
Bjorn
<div class="">Gonzalo</div>
<div class="">Nat</div>
<div class="">James</div>
<div class="">Shiva</div>
<div class="">Mohajeri</div>
<div class="">John </div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class="">September WS we need agenda and info to book hotels.</div>
<div class=""><br class="">
</div>
<div class="">Gonzalo Back channel draft.</div>
<div class="">New version uploaded last week.</div>
<div class=""><span style="font-family: Calibri,
sans-serif; font-size: 14px;" class=""> </span><a moz-do-not-send="true" href="https://bitbucket.org/openid/mobile/src/75eae8b8e50737059c069965c8c37e794843b510/draft-mobile-client-initiated-backchannel-authentication-01.html?at=default&fileviewer=file-view-default" style="font-family: Calibri, sans-serif;
font-size: 14px;" class=""></a><a class="moz-txt-link-freetext" href="https://bitbucket.org/openid/mobile/src/75eae8b8e50737059c069965c8c37e794843b510/draft-mobile-client-initiated-backchannel-authentication-01.html?at=default&fileviewer=file-view-default">https://bitbucket.org/openid/mobile/src/75eae8b8e50737059c069965c8c37e794843b510/draft-mobile-client-initiated-backchannel-authentication-01.html?at=default&fileviewer=file-view-default</a> </div>
<div class=""><br class="">
</div>
<div class="">Need discussion on the auth_req_id vs dymamic redirect_uri for post response</div>
<div class=""><br class="">
</div>
<div class="">Need discussion on defining a new response_type vs a scope for signalling the flow.</div>
<div class=""><br class="">
</div>
<div class="">Long discussion on poling response vs Post push.</div>
<div class=""><br class="">
</div>
<div class="">We discussed the similarity with the device flow that uses long polling and may be updated to support out of band push for consent/authentication rather as well as the current type the URI method.</div>
<div class=""><a moz-do-not-send="true" href="https://tools.ietf.org/html/draft-ietf-oauth-device-flow" class="">https://tools.ietf.org/html/draft-ietf-oauth-device-flow</a></div>
<div class=""><br class="">
</div>
<div class="">John observed that polling may be easier logic for some RP to implement, and can work with non server devices.</div>
<div class="">Posting back to the client also introduces new security considerations, if mutual TLS is not used. </div>
<div class="">The whole response may need to be signed eg include the auth_req_id inside the id_token.</div>
<div class="">Connect is defining Session ID “sid” as part of logout, that might be something we could use instead of auth_req_id to correlate in the POST case, as it will be a id_token claim.</div>
<div class=""><br class="">
</div>
<div class="">Shiva is going to get feedback from operators on the backchannel draft and circulate to the WG.</div>
<div class=""><br class="">
</div>
<div class="">John B.</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
</div>
</div>
</div>
<br class="">
</div>
</div>
</span></span><br class="">
<hr class="">
<font size="1" color="Gray" face="Arial" class=""><br class="">
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 class="">
<br class="">
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 class="">
<br class="">
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 class="">
</font><br class="">
<fieldset class="mimeAttachmentHeader"></fieldset> <br class="">
<pre wrap="" class="">_______________________________________________
Openid-specs-mobile-profile mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-mobile-profile@lists.openid.net">Openid-specs-mobile-profile@lists.openid.net</a><a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile">http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile</a></pre>
</blockquote>
<br class="">
</div>
</div>
</span><br class="">
<hr class="">
<font face="Arial" color="Gray" size="1" class=""><br class="">
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 class="">
<br class="">
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 class="">
<br class="">
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 class="">
</font>
</div>
</div></blockquote></div><br class=""></div></body></html>