[Openid-specs-mobile-profile] ACR values

Lodderstedt, Torsten t.lodderstedt at telekom.de
Mon Nov 23 17:19:39 UTC 2015


Hi John,

I agree we should definitely describe our assumptions about the recovery/administration processes. It is important to note that the respective credentials must be as strong as or stronger than the credentials used for authentication.

Regarding recovery: to be able to link a person to a certain user account is one way to make it recoverable, to use other authenticators (devices, tokens, ..., whatever) potentially in combination with risk signals is another. It is potentially also acceptable to lose access to an account under some circumstances. So to me creating the link to a person is a best practice to fulfill certain requirements but not the requirement itself. I therefore would suggest to note mention this option as an example (or best practice) in our document.

Examples: SIM applet click ok is an example of possession and single factor as well (and it is the authenticator several MNOs use and will use).

Two factor: Interesting observation - I made similar observations when discussing the topic in my team. I think one needs to strictly distinguish between authenticators and factors. There are definitely a lot of authenticators employing more than a single factor. We can note this in the spec as well.

Best regards,
Torsten.

-----Ursprüngliche Nachricht-----
Von: Openid-specs-mobile-profile [mailto:openid-specs-mobile-profile-bounces at lists.openid.net] Im Auftrag von John Bradley
Gesendet: Sonntag, 22. November 2015 21:02
An: Torsten Lodderstedt
Cc: openid-specs-mobile-profile at lists.openid.net
Betreff: Re: [Openid-specs-mobile-profile] ACR values

That is close to what I am thinking.

The question is are there other base line security requirements around being able to assert TwoFactorTamperResistant.   

If the account can be reset with a email link that can register a new HW token is that still the same level.

I think that we would at-least need to say that the account recovery/administration is also protected with at-least this level.

That is the tricky part, because the best token won’t help if the account recovery process is weak.

That was one of the original reason for identity proofing subjects in NIST SP800-63 with increasing strength at each level.  
Without knowing who the person is, it is hard to prevent account takeover.

I know we don’t want to say anything about proofed attributes,  but there needs to be some correlation to the confidence that the same person, even if pseudonymous is in control of the account.

Perhaps it is best to stick with this plus a pointer to another doc (Perhaps GSMA) that lays out the baseline business practices that need to be followed..

We probably need some examples of those levels.

For possession that would be a Fido U2F key or software client with press to confirm only.
The term two factor is going to be confusing to people because we are mostly talking about a key in hardware or software that needs to be in the users possession (on the phone) and some sort of knowledge (pin) or biometric unlock.   

That counts as two factor but looks like one authentication to people.

John B.
> On Nov 22, 2015, at 4:42 PM, Torsten Lodderstedt <torsten at lodderstedt.net> wrote:
> 
> Hi all,
> 
> based on the discussions in the last WG call, I think we are running circles again when it comes to ACR values.
> 
> What I got:
> - usage of LOA values from ISO 29115 seems to confuse people (because 
> they seem to be not as specfic as we thought and cover identification 
> as well)
> - new EU regulations use other terms and the number of authentication 
> levels differ
> 
> What do you think about the following proposal:
> 
> In the end, we want to give the RP a way to request authentication levels, which are specific to Mobile Connect/MODRNA. Why don't we define ACR value names, which exactly correspond to what we intend to use? From my perspective, Mobile Connect requires the following levels:
> - urn:openid:modrna:acr:credential:PasswordLess (meaning: posession or 
> inherence is ok)
> - urn:openid:modrna:acr:credential:TwoFactor (any two factors, 
> software-based solutions are ok)
> - urn:openid:modrna:acr:credential:TwoFactorTamperResistant (any two 
> factors, hardware token required)
> 
> Those values are intentionally MODRNA specific and could be mapped (if needed) to any other model.
> 
> What do you think?
> 
> best regards,
> Torsten.
> _______________________________________________
> Openid-specs-mobile-profile mailing list 
> Openid-specs-mobile-profile at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile

_______________________________________________
Openid-specs-mobile-profile mailing list Openid-specs-mobile-profile at lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile


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