<p dir="ltr">I meant "I don't understand why the client is supposed to send the requests to the authorization endpoint."</p>
<p dir="ltr">Sent by <a href=http://www.mail-wise.com/installation/2>MailWise</a> – See your emails as clean, short chats.</p>
<br><br>-------- Ursprüngliche Nachricht --------<br>Von: Torsten Lodderstedt <torsten@lodderstedt.net><br>Gesendet: Friday, September 2, 2016 06:15 PM<br>An: GONZALO FERNANDEZ RODRIGUEZ <gonzalo.fernandezrodriguez@telefonica.com>,John Bradley <ve7jtb@ve7jtb.com>,Openid-specs-mobile-profile <openid-specs-mobile-profile@lists.openid.net><br>Betreff: Re: [Openid-specs-mobile-profile] Notes from Moderna Aug 24<br><br>
Hi Gonzalo,<br>
<br>
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>
<br>
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>
<br>
best regards,<br>
Torsten. <br>
<br>
Am 02.09.2016 um 15:35 schrieb GONZALO FERNANDEZ RODRIGUEZ:<br>
<blockquote
cite="mid:2EB9BD09-E98D-4461-9E32-20265888DC07@telefonica.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div>
<div>Hi John,</div>
<div><br>
</div>
<div>First of all many thanks for the minutes.</div>
<div><br>
</div>
<div>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><br>
</div>
<div><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);">
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);">
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><br>
</div>
<div><br>
</div>
<div>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><br>
</div>
<div><br>
</div>
<div>Best,</div>
<div>Gonza.</div>
<div>
</div>
</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:12pt;
text-align:left; color:black; BORDER-BOTTOM: medium none;
BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT:
0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid;
BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>Openid-specs-mobile-profile
<<a moz-do-not-send="true"
href="mailto:openid-specs-mobile-profile-bounces@lists.openid.net">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">ve7jtb@ve7jtb.com</a>><br>
<span style="font-weight:bold">Date: </span>miércoles, 24 de
agosto de 2016, 19:03<br>
<span style="font-weight:bold">To: </span>Openid-specs-mobile-profile
<<a moz-do-not-send="true"
href="mailto:openid-specs-mobile-profile@lists.openid.net">openid-specs-mobile-profile@lists.openid.net</a>><br>
<span style="font-weight:bold">Subject: </span>[Openid-specs-mobile-profile]
Notes from Moderna Aug 24<br>
</div>
<div><br>
</div>
<span style="mso-bookmark:_MailOriginalBody">
<div>
<div style="word-wrap: break-word; -webkit-nbsp-mode: space;
-webkit-line-break: after-white-space;" class="">
<br class="">
<div><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 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></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>
<hr>
<font size="1" color="Gray" face="Arial"><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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
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>