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

Lodderstedt, Torsten t.lodderstedt at telekom.de
Fri Feb 5 16:09:06 UTC 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
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?

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?

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


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