[Openid-specs-mobile-profile] Preliminary Minutes WG Call 27.1.2016

Torsten Lodderstedt torsten at lodderstedt.net
Sat Feb 6 11:04:17 UTC 2016


Hi Gonzalo,

yes we need to raise awareness on GSMA side. John made some good points 
why even SPs most likely don't want to see the consequences of such a 
strict approach.

I assume the point will be discussed as soon as we are delivering our 
spec to the GSMA.

best regards,
Torsten.

Am 06.02.2016 um 11:58 schrieb GONZALO FERNANDEZ RODRIGUEZ:
>
>
> De: <Lodderstedt>, Torsten <t.lodderstedt at telekom.de 
> <mailto:t.lodderstedt at telekom.de>>
> Fecha: viernes, 5 de febrero de 2016, 17:09
> Para: Gonzalo Fernandez Rodriguez 
> <gonzalo.fernandezrodriguez at telefonica.com 
> <mailto:gonzalo.fernandezrodriguez at telefonica.com>>, 
> "openid-specs-mobile-profile at lists.openid.net 
> <mailto:openid-specs-mobile-profile at lists.openid.net>" 
> <openid-specs-mobile-profile at lists.openid.net 
> <mailto:openid-specs-mobile-profile at lists.openid.net>>
> Asunto: AW: [Openid-specs-mobile-profile] Preliminary Minutes WG Call 
> 27.1.2016
>
> Hi Gonzalo,
>
> please see my comments inline.
>
> best regards,
>
> Torsten.
>
> *Von:*GONZALO FERNANDEZ RODRIGUEZ 
> [mailto:gonzalo.fernandezrodriguez at telefonica.com]
> *Gesendet:* Freitag, 29. Januar 2016 14:22
> *An:* Lodderstedt, Torsten; 
> openid-specs-mobile-profile at lists.openid.net 
> <mailto:openid-specs-mobile-profile at lists.openid.net>
> *Betreff:* Re: [Openid-specs-mobile-profile] Preliminary Minutes WG 
> Call 27.1.2016
>
> Hi guys,
>
> In our last call we were talking about different use cases we could 
> come across the  the MODRNA Profile spec.
>
> I have had some meetings with product business from Telefónica, and I 
> would like to share with you some of these use cases that can have 
> impact in the MODRNA profile spec.
>
> *ABILITY TO CHOOSE THE SPECIFIC AUTHENTICATOR*
>
> As per the conversations that I have had with Biz Product, they want 
> to have the ability to charge different prices to the Service 
> Providers dependant on the authenticator used to authenticate the 
> user, so it iwould be necessary that the RP would have the chance to 
> choose it in the authentication request. The current draft of the spec 
> only allows to specify “mod-pr” and “mod-mf” to request 
> phising-resistant and multi-factor authentication respectivey, without 
> taking into account the final authenticator that will be used.
>
> What ist he expected behavior, if the particular MNO does not support 
> the specific authenticator or if the particular user is not in 
> possession of the specific authenticator?
>
>
> [Gonzalo] —> When I talk about to choose the specific authenticator, I 
> mean a list in preference order, in such way that if the MNO or the 
> user don’t have one authenticator, the next one in the list will be 
> choosen. Related to the MNO’s, they (product) are thinking to specify 
> what kind of authenticators the MNO has and which of them they can use.
>
> I think that this is an important point to talk to GSMA, we need them 
> to talk with the rest of operators, personally I don’t see this point 
> clear and I don’t know if other MNO's product areas are thinking in 
> something similar.
>
> *CONTROL OF ALLOWED AUTHENTICATORS*
>
> Apart from having different prices according with the used 
> authenticator, there is another feature that they want to have,  and 
> it consist in having a control of the authenticators that a Service 
> Provider can use. They see a need to agree the authenticators to use 
> during the Service Provider onboarding process, in such way if a 
> Service Provider doesn’t hire an authenticator it must not be able to 
> use it. In such case we would need an scope or something similar to do 
> it otherwise we would need to implement something “ad-hoc”in the 
> specific MC implementation that wants to offer this feature.
>
> From what I understand, this could be part of the SP-specific client 
> policy. So the MNO knows upfront which authenticators to use/offer for 
> a certain SP. Why do you see a need for a specific scope value?
>
>
> [Gonzalo] —>You are right, it is not necessary to do it, however it 
> has impact in the implementation because it is a check that you have 
> to do in the middle of the authentication flow. I was thinking about 
> using a new scope as a way to deal with this use case in an standard 
> way and be able to return an standard error.
>
> Best,
>
> Gonza.
>
> *De: *<Lodderstedt>, Torsten <t.lodderstedt at telekom.de 
> <mailto:t.lodderstedt at telekom.de>>
> *Fecha: *jueves, 28 de enero de 2016, 8:08
> *Para: *"openid-specs-mobile-profile at lists.openid.net 
> <mailto:openid-specs-mobile-profile at lists.openid.net>" 
> <openid-specs-mobile-profile at lists.openid.net 
> <mailto:openid-specs-mobile-profile at lists.openid.net>>
> *Asunto: *[Openid-specs-mobile-profile] Preliminary Minutes WG Call 
> 27.1.2016
>
> Hi all,
>
> please find below the minutes of today’s call.
>
> best regards,
>
> Torsten.
>
> Participants:
>
> John Bradley
>
> Nat Sakimura
>
> Florian Walter
>
> Jörg Connotte
>
> Gonzalo Fernandéz
>
> Matthieu Verdier
>
> Bjorn Hjelm
>
> Torsten Lodderstedt
>
> Authentication spec
>
> - John guided us through the changes he made in the last revision
>
> - The following topics were discussed:
>
> * ACR Values: examples for security keys and difference between keys 
> and pwd/pin shall be added
>
> * AMR values: add example for amr values (e.g SIM Applet+PIN is 
> represented by “hpop” + “pin”)
>
> * short and long form of ACRs: the short shall be used by clients, 
> long form will be used to register the ACR values in the IANA registry 
> (by MODRNA WG)
>
> * order of acrs gives RP a way to express its preferences regarding 
> authentication, i.e. bring ARC values in their preferred order
>
> * we stay with two acr values for now, we could add the third (or a 
> forth) value at any time based on experiences/discussions
>
> - how to handle TBDs
>
> - 6.1. replace by reference to respective OpenID Connect Discovery
>
> - 7 length of the binding message – replace by better explanation: 
> message may be truncated
>
> - Mitigations for new security vulnerabilities
>
> - discussed different options
>
> * copy text from oauth spec
>
> * reference current oauth spec
>
> * recommend to use “code id_token” instead of “code”
>
> * general problem: discussions within OAuth WG are ongoing and outcome 
> cannot really be predicted.
>
> -> Conclusion: will pass spec to GSMA as is and discuss 
> vulnerabilities and way forward with GSMA
>
> MWC
>
> - John, Torsten will attend
>
> - Nat will probably attend as well (as he will be in Paris at that time)
>
> - Gonzalo & Matthieu would attend if we setup a meeting regarding MODRNA
>
> - Torsten will talk to GSMA
>
> ------------------------------------------------------------------------
>
>
> 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
>
>
> _______________________________________________
> 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/20160206/f3c8d759/attachment-0001.html>


More information about the Openid-specs-mobile-profile mailing list