<p dir="ltr">Agreed</p>
<div class="gmail_extra"><br><div class="gmail_quote">On Sep 5, 2016 3:30 PM, "Torsten Lodderstedt" <<a href="mailto:torsten@lodderstedt.net">torsten@lodderstedt.net</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
Hi all,<br>
<br>
I personally would prefer to have a dedicated, new endpoint for
initializing a backchannel authentication transaction, like the
OAuth device flow does
(<a href="https://tools.ietf.org/html/draft-ietf-oauth-device-flow-03" target="_blank">https://tools.ietf.org/html/<wbr>draft-ietf-oauth-device-flow-<wbr>03</a>). I
consider this the cleanest and easiest way (for both OP and client
implementors) to solve our use case. It would allow us to define
parameters and processing rules in a way suitable for backchannel
authentication (without imposing limitations/constraints originating
from frontchannel authentication onto implementors). <br>
<br>
I see the following properties of the backchannel authentication
endpoint:<br>
- HTTP method POST (only), parameters are sent in the request body<br>
- supports client authentication (which the authz endpoint does
not!) using client secret or JWT assertions<br>
- utilizes existing OAuth/OIDC authorization/authentication requests
parameters as needed, such as "scope" (but not "redirect_uri" or
"response type")<br>
- adds further parameters needed for backchannel authentication,
such as "callback" or "client_notification_endpoint" <br>
- returns auth_req_id<br>
<br>
If we want to offer pull style processing, we could (again) follow
the pattern proposed by the OAuth device flow and introduce a new
grant type to the tokens endpoint for that purpose (e.g.
<a>"urn:openid:params:modrna:<wbr>grant-type:backchannel_<wbr>request"</a>). The
client would use this grant type along with the "auth_req_id" to
query the results of the authentication transaction.<br>
<br>
best regards,<br>
Torsten.<br>
<br>
<div>Am 02.09.2016 um 22:03 schrieb John
Bradley:<br>
</div>
<blockquote type="cite">
I would base it on the RFC 7523 Authorization grant. Using a self
signed Connect Request Object as the grant request.
<div><br>
</div>
<div>The IdP performs the out of band consent to approve
the grant request.</div>
<div><br>
</div>
<div>If the request is signed the RP could specify any
URI it likes as a post back location if you are not polling or
blocking.</div>
<div><br>
</div>
<div>I think this method may allso would allow for the
the collection of consent for transactions.</div>
<div><br>
</div>
<div>I would prefer not to wind up with two separate
extensions for backchannel authentication (Really consent to
login as it is not authenticating the front channel) and consent
for transactions.</div>
<div><br>
</div>
<div>John B. <br>
<div>
<div>
<blockquote type="cite">
<div>On Sep 2, 2016, at 4:33 PM, GONZALO
FERNANDEZ RODRIGUEZ <<a href="mailto:gonzalo.fernandezrodriguez@telefonica.com" target="_blank">gonzalo.fernandezrodriguez@<wbr>telefonica.com</a>>
wrote:</div>
<br>
<div>
<div style="word-wrap:break-word;font-size:14px;font-family:Calibri,sans-serif">
<div>
<div>Hi again John,</div>
<div><br>
</div>
<div>Is true the the RO credentials flow
authenticate the user, but in this case the RP
knows the user credentials (user/password) and it
is not your case, we only knows the MSISDN and we
need somehow to specify an ac_value to
authenticate the user, we would also need to
extend it.</div>
<div><br>
</div>
<div>If I understand well, what you propose
is not sending the parameters in the POST’s body
in clear but send a GET with a unique parameter
that is a signed JWT, it could be send to the
Token endpoint or to another endpoint. Let’s say
we use the Token endpoint, whenever a request is
received is should….</div>
<ul>
<li>Checks the sign</li>
<li>generates the auth_req_id and</li>
<li>sends a response to the RP with the
auth_req_id to allow the RP polling for the
authentication response</li>
<li>select the authenticator to
authenticate the user, generate tokens and send
them as the poll response…..</li>
</ul>
<div><br>
</div>
<div>P.S: is there any place where the
attacks to the redirect_ui with parameters are
documented?</div>
<div><br>
</div>
<div>Best,</div>
<div>Gonza.</div>
<div>
</div>
</div>
<div><br>
</div>
<span>
<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)">
<span style="font-weight:bold">From: </span>John
Bradley<br>
<span style="font-weight:bold">Date: </span>Friday
2 September 2016 at 19:53<br>
<span style="font-weight:bold">To: </span>Gonzalo
Fernández<br>
<span style="font-weight:bold">Cc: </span>Torsten
Lodderstedt, Openid-specs-mobile-profile<br>
<span style="font-weight:bold">Subject: </span>Re:
[Openid-specs-mobile-profile] Notes from Moderna
Aug 24<br>
</div>
<div><br>
</div>
<div>
<div style="word-wrap:break-word">
The token endpoint is used to authenticate the
user in several flows.
<div><br>
</div>
<div>Most notably the RO Credentials
flow that is unfortunately widely used.</div>
<div><br>
</div>
<div>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><br>
</div>
<div>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><br>
</div>
<div>We did discuss that option at the
last face to face meeting.</div>
<div><br>
</div>
<div>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><br>
</div>
<div>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><br>
</div>
<div>It is the openID core spec that
requires exact redirect URI matching.
Anything else is a violation of the spec. </div>
<div><br>
</div>
<div>The OAuth allows query parameters
to be excluded from the match for the code
flow. </div>
<div><br>
</div>
<div>There have been some large number
of attacks that take advantage of pattern
matching.</div>
<div>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><br>
</div>
<div>This was one of the outcomes of
the OAuth security conference in July.</div>
<div><br>
</div>
<div>John B.</div>
<div><br>
<div>
<blockquote type="cite">
<div>On Sep 2, 2016, at 2:25 PM,
GONZALO FERNANDEZ RODRIGUEZ <<a href="mailto:gonzalo.fernandezrodriguez@telefonica.com" target="_blank"><a href="mailto:gonzalo.fernandezrodriguez@telefonica.com" target="_blank">gonzalo.fernandezrodriguez@<wbr>telefonica.com</a></a>>
wrote:</div>
<br>
<div>
<div style="word-wrap:break-word;font-size:14px;font-family:Calibri,sans-serif">
<div>
<div>Hi Torsten,</div>
<div><br>
</div>
<div>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><br>
</div>
<div>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><br>
</div>
<div>Best,</div>
<div>Gonza.</div>
<div>
</div>
</div>
<div><br>
</div>
<span>
<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)">
<span style="font-weight:bold">From: </span>Torsten
Lodderstedt<br>
<span style="font-weight:bold">Date: </span>Friday 2
September 2016 at 18:15<br>
<span style="font-weight:bold">To: </span>Gonzalo
Fernández, John Bradley,
Openid-specs-mobile-profile<br>
<span style="font-weight:bold">Subject: </span>Re:
[Openid-specs-mobile-profile]
Notes from Moderna Aug 24<br>
</div>
<div><br>
</div>
<div>
<div text="#000000" bgcolor="#FFFFFF">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 type="cite">
<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;line-height:normal;background-color:rgb(255,255,255)">
response_mode </dt>
<dd style="font-family:verdana,charcoal,helvetica,arial,sans-serif;font-size:small;line-height:normal;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><br>
</div>
<span>
<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)">
<span style="font-weight:bold">From: </span>Openid-specs-mobile-profile
<<a href="mailto:openid-specs-mobile-profile-bounces@lists.openid.net" target="_blank"><a href="mailto:openid-specs-mobile-profile-bounces@lists.openid.net" target="_blank">openid-specs-mobile-profile-<wbr>bounces@lists.openid.net</a></a>>
on behalf of John Bradley
<<a href="mailto:ve7jtb@ve7jtb.com" target="_blank"><a href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a></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 href="mailto:openid-specs-mobile-profile@lists.openid.net" target="_blank"><a href="mailto:openid-specs-mobile-profile@lists.openid.net" target="_blank">openid-specs-mobile-profile@<wbr>lists.openid.net</a></a>><br>
<span style="font-weight:bold">Subject: </span>[Openid-specs-mobile-profile]
Notes from Moderna Aug 24<br>
</div>
<div><br>
</div>
<span>
<div>
<div style="word-wrap:break-word">
<br>
<div><br>
<div>
<div style="word-wrap:break-word">
Bjorn
<div>Gonzalo</div>
<div>Nat</div>
<div>James</div>
<div>Shiva</div>
<div>Mohajeri</div>
<div>John </div>
<div><br>
</div>
<div><br>
</div>
<div>September
WS we need
agenda and
info to book
hotels.</div>
<div><br>
</div>
<div>Gonzalo
Back channel
draft.</div>
<div>New
version
uploaded last
week.</div>
<div><span style="font-family:Calibri,sans-serif;font-size:14px"> </span><a href="https://bitbucket.org/openid/mobile/src/75eae8b8e50737059c069965c8c37e794843b510/draft-mobile-client-initiated-backchannel-authentication-01.html?at=default&fileviewer=file-view-default" target="_blank"><a href="https://bitbucket.org/openid/mobile/src/75eae8b8e50737059c069965c8c37e794843b510/draft-mobile-client-initiated-backchannel-authentication-01.html?at=default&fileviewer=file-view-default" target="_blank">https://bitbucket.org/openid/<wbr>mobile/src/<wbr>75eae8b8e50737059c069965c8c37e<wbr>794843b510/draft-mobile-<wbr>client-initiated-backchannel-<wbr>authentication-01.html?at=<wbr>default&fileviewer=file-view-<wbr>default</a></a> </div>
<div><br>
</div>
<div>Need
discussion on
the
auth_req_id
vs dymamic
redirect_uri
for post
response</div>
<div><br>
</div>
<div>Need
discussion on
defining a new
response_type
vs a scope for
signalling the
flow.</div>
<div><br>
</div>
<div>Long
discussion on
poling
response vs
Post push.</div>
<div><br>
</div>
<div>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><a href="https://tools.ietf.org/html/draft-ietf-oauth-device-flow" target="_blank"><a href="https://tools.ietf.org/html/draft-ietf-oauth-device-flow" target="_blank">https://tools.ietf.org/html/<wbr>draft-ietf-oauth-device-flow</a></a></div>
<div><br>
</div>
<div>John
observed that
polling may be
easier logic
for some RP to
implement, and
can work with
non server
devices.</div>
<div>Posting
back to the
client also
introduces new
security
considerations,
if mutual TLS
is not used. </div>
<div>The
whole response
may need to be
signed eg
include the
auth_req_id
inside the
id_token.</div>
<div>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><br>
</div>
<div>Shiva
is going to
get feedback
from operators
on the
backchannel
draft and
circulate to
the WG.</div>
<div><br>
</div>
<div>John
B.</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
</div>
</div>
<br>
</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></fieldset>
<br>
<pre>______________________________<wbr>_________________
Openid-specs-mobile-profile mailing list
<a href="mailto:Openid-specs-mobile-profile@lists.openid.net" target="_blank">Openid-specs-mobile-profile@<wbr>lists.openid.net</a><a href="http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile" target="_blank">http://lists.<wbr>openid.net/mailman/listinfo/<wbr>openid-specs-mobile-profile</a></pre>
</blockquote>
<br>
</div>
</div>
</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></div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</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>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
</div>
</blockquote></div></div>