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

Fri Oct 31 13:48:20 UTC 2014

With something like 850 idp, letting them each define there own ACR and AMR would not be scalable for the RP.

There is an IANA registry for ACR  https://tools.ietf.org/html/rfc6711
(I happen to be one of the IANA designated experts for that)

These registered values are also used in SAML.

Minimally registered values with publicly documented meanings need to be used.

I do think that there needs to be a common set of ACR values that are understood (MTI) for all IdP deploying the mobile profile.

I suspect that ISO 29115 may be a starting point, it doesn't cover the strong credential pseudonymous case. (Prepaid/anonymous sim using strong multi factor)

There may also be a need for some sort of 3rd party certification at some point if these credentials are going to be accepted by national ID programs in places like the US, UK & Canada.

Using an existing trust framework that defines ACR may make that easier.  

This WG needs to define the technical mechanisms and point at a Trust framework of some sort.   It may be that there needs to be a separate process with the GSMA and OIX etc to nail down that trust framework.   That may also be where the global terms of service for registering as a RP also live.

The acr values parameter is a space separated list in the order of preference that the RP is willing to accept.
Connect dosen't have logical comparisons like better than in SAML as better and worse are concepts that IdP and RP typically have a hard time agreeing on and change depending on context.

We decided that letting the RP explicitly state it's order of preference was more likely to get implemented.

I am personally not a big fan of using amr.   in SAML specifying the context that specifically has generally caused more problems than it has solved outside of a constrained enterprise SSO environment.

RP will definitely think they want to know, but if they rely on it the first time a carrier adds a new amr like FIDO UAF v2 then RP start breaking.   It is a challenge to allow amr to be useful and extensible in a large federation.     The problem is that people think that they want it.

It may be possible if amr is defined coarsely enough,  say with 4 levels that may keep us out of trouble.   However my experience is that every multi factor vender is going to want to be listed separately.
I have had many happy discussions with OATH where they wanted HOTP (RFC 4226) tokens differentiated from TOTP (RFC 6238) and OCRA (RFC 6287) tokens.   There are people that will want to go down that slippery slope.

John B.

On Oct 31, 2014, at 5:32 AM, Mike Varley <mike.varley at securekey.com> wrote:

> 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
>> 
> 
> _______________________________________________
> Openid-specs-mobile-profile mailing list
> Openid-specs-mobile-profile at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile