[Openid-specs-mobile-profile] Notes from Moderna Aug 24
Torsten Lodderstedt
torsten at lodderstedt.net
Fri Sep 2 16:15:03 UTC 2016
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
> <mailto:openid-specs-mobile-profile-bounces at lists.openid.net>> on
> behalf of John Bradley <ve7jtb at ve7jtb.com <mailto:ve7jtb at ve7jtb.com>>
> Date: miércoles, 24 de agosto de 2016, 19:03
> To: Openid-specs-mobile-profile
> <openid-specs-mobile-profile at lists.openid.net
> <mailto:openid-specs-mobile-profile at 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/75eae8b8e50737059c069965c8c37e794843b510/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 list
> Openid-specs-mobile-profile at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20160902/bcc1f1d9/attachment-0001.html>
More information about the Openid-specs-mobile-profile
mailing list