[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