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

[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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20160902/a9ec3c7f/attachment.html>