[Openid-specs-mobile-profile] Notes from Moderna Aug 24

[John Bradley]

Agreed

On Sep 5, 2016 3:30 PM, "Torsten Lodderstedt" <torsten at lodderstedt.net>
wrote:

> Hi all,
>
> I personally would prefer to have a dedicated, new endpoint for
> initializing a backchannel authentication transaction, like the OAuth
> device flow does (https://tools.ietf.org/html/
> draft-ietf-oauth-device-flow-03). 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).
>
> I see the following properties of the backchannel authentication endpoint:
> - HTTP method POST (only), parameters are sent in the request body
> - supports client authentication (which the authz endpoint does not!)
> using client secret or JWT assertions
> - utilizes existing OAuth/OIDC authorization/authentication requests
> parameters as needed, such as "scope" (but not "redirect_uri" or "response
> type")
> - adds further parameters needed for backchannel authentication, such as
> "callback" or "client_notification_endpoint"
> - returns auth_req_id
>
> 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. "urn:openid:params:modrna:
> grant-type:backchannel_request"). The client would use this grant type
> along with the "auth_req_id" to query the results of the authentication
> transaction.
>
> best regards,
> Torsten.
>
> Am 02.09.2016 um 22:03 schrieb John Bradley:
>
> I would base it on the RFC 7523 Authorization grant.  Using a self signed
> Connect Request Object as the grant request.
>
> The IdP performs the out of band consent to approve the grant request.
>
> 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.
>
> I think this method may allso would allow for the the collection of
> consent for transactions.
>
> 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.
>
> John B.
>
> On Sep 2, 2016, at 4:33 PM, GONZALO FERNANDEZ RODRIGUEZ <
> gonzalo.fernandezrodriguez at telefonica.com> wrote:
>
> Hi again John,
>
> 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.
>
> 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….
>
>    - Checks the sign
>    - generates the auth_req_id and
>    - sends a response to the RP with the auth_req_id to allow the RP
>    polling for the authentication response
>    - select the authenticator to authenticate the user, generate tokens
>    and send them as the poll response…..
>
>
> P.S: is there any place where the attacks to the redirect_ui with
> parameters are documented?
>
> Best,
> Gonza.
>
> From: John Bradley
> Date: Friday 2 September 2016 at 19:53
> To: Gonzalo Fernández
> Cc: Torsten Lodderstedt, Openid-specs-mobile-profile
> Subject: Re: [Openid-specs-mobile-profile] Notes from Moderna Aug 24
>
> The token endpoint is used to authenticate the user in several flows.
>
> Most notably the RO Credentials flow that is unfortunately widely used.
>
> 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.
>
> 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.
>
> We did discuss that option at the last face to face meeting.
>
> 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.
>
> I do think that eliminating the registered redirect forces us to consider
> signed requests, so that we are not creating new security issues.
>
> It is the openID core spec that requires exact redirect URI matching.
> Anything else is a violation of the spec.
>
> The OAuth allows query parameters to be excluded from the match for the
> code flow.
>
> There have been some large number of attacks that take advantage of
> pattern matching.
> 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.
>
> This was one of the outcomes of the OAuth security conference in July.
>
> John B.
>
> On Sep 2, 2016, at 2:25 PM, GONZALO FERNANDEZ RODRIGUEZ <
> gonzalo.fernandezrodriguez at telefonica.com> wrote:
>
> Hi Torsten,
>
> 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?
>
> 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.
>
> Best,
> Gonza.
>
> From: Torsten Lodderstedt
> Date: Friday 2 September 2016 at 18:15
> To: Gonzalo Fernández, John Bradley, Openid-specs-mobile-profile
> Subject: Re: [Openid-specs-mobile-profile] Notes from Moderna Aug 24
>
> Hi Gonzalo,
>
> 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.
>
> 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.
>
> best regards,
> Torsten.
>
> Am 02.09.2016 um 15:35 schrieb GONZALO FERNANDEZ RODRIGUEZ:
>
> Hi John,
>
> First of all many thanks for the minutes.
>
> 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
>
> response_mode 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.
>
>
> 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?
>
>
> Best,
> Gonza.
>
> From: Openid-specs-mobile-profile <openid-specs-mobile-profile-
> bounces at lists.openid.net> on behalf of John Bradley <ve7jtb at ve7jtb.com>
> Date: miércoles, 24 de agosto de 2016, 19:03
> To: Openid-specs-mobile-profile <openid-specs-mobile-profile@
> lists.openid.net>
> Subject: [Openid-specs-mobile-profile] Notes from Moderna Aug 24
>
>
>
> Bjorn
> Gonzalo
> Nat
> James
> Shiva
> Mohajeri
> John
>
>
> September WS we need agenda and info to book hotels.
>
> Gonzalo Back channel draft.
> New version uploaded last week.
>  https://bitbucket.org/openid/mobile/src/75eae8b8e50737059c069965c8c37e
> 794843b510/draft-mobile-client-initiated-backchannel-
> authentication-01.html?at=default&fileviewer=file-view-default
>
> Need discussion on the auth_req_id  vs dymamic redirect_uri for post
> response
>
> Need discussion on defining a new response_type vs a scope for signalling
> the flow.
>
> Long discussion on poling response vs Post push.
>
> 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.
> https://tools.ietf.org/html/draft-ietf-oauth-device-flow
>
> John observed that polling may be easier logic for some RP to implement,
> and can work with non server devices.
> Posting back to the client also introduces new security considerations, if
> mutual TLS is not used.
> The whole response may need to be signed eg include the auth_req_id inside
> the id_token.
> 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.
>
> Shiva is going to get feedback from operators on the backchannel draft and
> circulate to the WG.
>
> John B.
>
>
>
>
>
>
> ------------------------------
>
> 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.
>
> 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.
>
> 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
>
>
> _______________________________________________
> Openid-specs-mobile-profile mailing listOpenid-specs-mobile-profile at lists.openid.nethttp://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile
>
>
>
> ------------------------------
>
> 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.
>
> 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.
>
> 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
>
>
>
> ------------------------------
>
> 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.
>
> 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.
>
> 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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20160905/633d7794/attachment-0001.html>