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

John Bradley ve7jtb at ve7jtb.com
Fri Feb 5 16:27:41 UTC 2016

Yes the problem is what if the authenticator requested is not available on the users device.   

Do you really want to return an error or have the user use the closest authenticator they have and report what the user used to authenticate.

The SP almost never really wants a user turned away.

That might mean that for some operators requesting mod-mf will only be accepted if the SP is paying.  

What we don’t want is every SP needing to code different logic for every IdP. 

As for accepting the acr that is not part of the wire protocol.   Nothing stops a IdP from having client specific rules about how they process acr. 

If a client is not registered to send mod-mf then they only get mod-pr in the response.   The user may have actually used multi-factor on the device if that is all that is installed,  but the 
IdP can always report a lower value.

If the user only has a authenticator that uses a pin on the device you don’t want the IdP to return a error if the SP only requests mod-mf.

John B.

> On Feb 5, 2016, at 1:09 PM, Lodderstedt, Torsten <t.lodderstedt at telekom.de> wrote:
> Hi Gonzalo,
> please see my comments inline.
> best regards,
> Torsten.
> Von: GONZALO FERNANDEZ RODRIGUEZ [mailto:gonzalo.fernandezrodriguez at telefonica.com <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.
> 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?
> 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
> - 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
> _______________________________________________
> Openid-specs-mobile-profile mailing list
> Openid-specs-mobile-profile at lists.openid.net <mailto:Openid-specs-mobile-profile at lists.openid.net>
> http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile <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/20160205/360bea36/attachment-0001.html>

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