[Openid-specs-mobile-profile] About Level of Assurance

Fri Oct 31 12:32:44 UTC 2014

Sorry - I sent this response to the wrong list (thanks Torsten for catching it)

resent…

On Oct 30, 2014, at 2:43 PM, Mike Varley <mike.varley at securekey.com> wrote:

> That is a very important question, and something everyone in the WG should consider.
> 
> If we do not specify any specific levels or terms, we are left with implementors making this decision, and a possibly fractured ecosystem.
> 
> If we do attempt to define a set of terms / LoAs, we may get distracted from the core specification… 
> 
> I think that if we are going to allow RPs to specify or exclude specific technologies from the broad strokes of an LoA definition, then there will need to be at least some standardization around the "acr/amr" terms. I would also think that the amr filed may include terms not specified in the standard (allowing for vendor extensions and future proofing).
> 
> For example:
> 
> Request:
>   ...
>   &acr_values=3,-ussd
> 
> (authenticate at LoA 3, no ussd
> 
> 
> Response (id_token):
> {
>   …
>   "acr" : "3",
>   "amr" : "sim"
>   ...
> } 
> 
> (authenticated at LoA 3, with SIM Applet)
> 
> If an IdP cannot parse an car term (i.e., does not support '-ussd') then the response may be:
> 
> {
>    …
>    "acr" : "3",
>    "amr" : "ussd"
>    …
> }
> 
> and the RP can take action with the user...
> 
> 
> 
> Q: Is it feasible to set down a base set of terms/technologies for each LoA?
> Q: what standard should we base out LoAs on? NIST? ISO/IEC 29115 ? ITSG-31? (probably not that last one, but just an example of another LOA standard :) )
> 
> MV
> 
> 
> On Oct 30, 2014, at 12:20 PM, GONZALO FERNANDEZ RODRIGUEZ <gonzalo.fernandezrodriguez at telefonica.com> wrote:
> 
>> Many thanks Mike for your commentsŠ
>> 
>> One doubtŠ. If we do (1) or (2)Š Would we need an standard way to name the
>> different authenticators in order to them have the same meaningful in
>> every OIDC provider?
>> 
>> Best,
>> Gonza.
>> 
>> El 30/10/14 14:40, "Mike Varley" <mike.varley at securekey.com> escribió:
>> 
>>> There is an "amr" field in the id_token which may provide details on how
>>> the authentication was performed, so perhaps this filed can be leveraged:
>>> 
>>> I see 2 options, off the top of my brain:
>>> (1) Add an "amr_values" to the request parameters, allowing an RP to name
>>> authentication specifically, or
>>> (2) re-jig the "acr_values" parameter in mobile connect to allow for
>>> general LoAs, and also specific authenticators.
>>> 
>>> I find option (2) may be more challenging to implement, but only slightly.
>>> 
>>> And since OIDC core does not define what an LoA means (i.e., it doesn't
>>> have to be NIST) then we can define our own terms :)
>>> 
>>> MV
>>> 
>>> 
>>> 
>>> On Oct 30, 2014, at 6:49 AM, GONZALO FERNANDEZ RODRIGUEZ
>>> <gonzalo.fernandezrodriguez at telefonica.com> wrote:
>>> 
>>>> Hi all,
>>>> 
>>>> I would like to share with the WG a concern that I have related with the
>>>> requested Level of Assurance in OIDC. There are certain particularities
>>>> in
>>>> the Mobile Connect architecture that I don't know if could be resolved
>>>> in
>>>> this WG, but at least it is good to be aware of them.
>>>> 
>>>> As defined in the Mobile Connect architecture, when an authentication
>>>> request is received and before to authenticate the user, an
>>>> authenticator
>>>> selector will analyze the request and based on the context and some
>>>> configured policies it will select the properly authenticator, that is
>>>> an
>>>> authentication method. There are some Service Providers that consider
>>>> not
>>>> secured equivalent all of the authenticators associated to the same LoA
>>>> (e.g: Banks don't think USSD pin based is secure enough, however they
>>>> think SIM applet authenticator is, and both are LoA3).
>>>> 
>>>> My concern is about how to select the properly authenticator, as far as
>>>> I
>>>> understand the protocol only allows you to select the LoA preferences
>>>> using the "acr_values" parameter but is not possible to specify an
>>>> specific authenticator, so it should be configured in the policies
>>>> database. But if we do that, there would have somehow to this
>>>> configuration will be the same for all the MNO providers.
>>>> 
>>>> Any idea? Does anyone think this is something to deal with in the Mobile
>>>> Profile WG or it is beyond the WG's scope?
>>>> 
>>>> BTW: I have never seen an OIDC request indicating acr_values, someone
>>>> can
>>>> post one?
>>>> 
>>>> Thanks in advance,
>>>> Gonza.
>>>> 
>>>> 
>>>> ________________________________
>>>> 
>>>> 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
>>> 
>> 
>> 
>> ________________________________
>> 
>> 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
> 