[Openid-specs-mobile-profile] ACR values

John Bradley jbradley at mac.com
Sat Nov 28 21:19:13 UTC 2015


Operators will certainly have some users with devices that store keys in hardware (SIM) and others that are using software, and probably some that are using the HW keychain unlocked by a biometric or a pin.  

The point I am trying to make is that a user has one device.  It will or will not have HW protection for the key.   If the RP is too specific about what it asks for all it will do is cause failed authentications.

I was counting click OK to the SIM applet as single factor (Because it is).    In the single factor case the AMR would differentiate between a SIM with click OK and a password or something else.

We can send more specific information back in the amr about what happened.

The acr in the request shouldn’t be too specific because that just forces the IdP to return an error vs something useful.

I am bading these observations on the three levels in the current document. 
Two are effectively the same from a request point of view.   Give me a authentication where the user needs to locally authenticate to the device.   The only diffrence will be how the key is protected in the hardware and that depends on the device.  The RP can’t influence that in a meaningful way during authentication.

So far I don’t see having more than two LoA in the request as being useful from the description.

What behaviour at the IdP would the third one cause different from the second?

It may be that there is something, but it is not captured in the description.  That is what I am looking for.

John B.



> On Nov 28, 2015, at 2:51 PM, Lodderstedt, Torsten <t.lodderstedt at telekom.de> wrote:
> 
> Hi John,
>  
> why doesn’t it make sense for a RP to specifically ask for HW protected keys? I could imagine some operators use software-based  keys (which should be ok in some cases) whereas the majority will store them on the SIM card. 
>  
> And by the way: It’s not just about asking the OP to perform 2nd factor authentication or accept single factor. In the case of Mobile Connect, it is also desirable to ask for certain factors (or better said prohibit knowledge alone) in the single factor case. The predominant example is inherence in the case of SIM applet (click ok).
>  
> best regards,
> Torsten.
>  
> Von: John Bradley [mailto:jbradley at mac.com] 
> Gesendet: Freitag, 27. November 2015 20:02
> An: Lodderstedt, Torsten
> Cc: openid-specs-mobile-profile at lists.openid.net
> Betreff: Re: [Openid-specs-mobile-profile] ACR values
>  
> That is true but normally the levels are not defined in a protocol document.   They would be in a trust framework document that details how to conform to them including all the legal and business practice agreements.
>  
> All we can say is that all of that is dealt with someplace else and the URI indicate the means by which the subject was most recently authenticated.
>  
> One of the hard things with LoA is that better might be subjective.  There is no guarantee in general that one is better than another as they might theoretically mitigate different risks.
>  
> For MODRNA LoA it looks like we are going to have three dimensions for what would normally all be bound up in a single loa number in 29115/SP800-63
> a) Identtiy proofed   [ “True” ,  “False”]            (can the IdP legally identify the subject)
> b) Proof of Possession [ “True” , “False”]        (in 800-63 PoP is required for LoA 4,  but we can deal with it separately in the protocol)
> c) Strength of Primary credential  [ “single factor”, “multi-factor soft-key”,  “ multi-factor hard key” ]
>  
> In the first stage we are only asserting non proofed subjects.
>  
> That gives us three levels now and eventually six to plan for.
>  
> In reality the user will have a token with a HW or software key, so as a RP asking specifically for one or the other doesn’t make much sense.
>  
> As a RP I think that you want to be able to say force the user to 2nd factor if there current login is single factor, or I will take what the user is logged in as.
>  
> Lets assume for the moment that amr in the response can differentiate between hard and soft keys.
>  
> That would leave us with two acr values to ask for.   Lets call them 1F and 2F for the moment. 
>  
> That would give us:
> [ “1F” ]  ==  Give me what the user has logged in at, don’t force step up.
> [ “2F” , "1F" ]  ==  Force the user to do two factor if there device supports it, but I will take single if that is all there device supports.
> [ “2F” ]            ==  Force the user to do two factor if there device supports it, return an error if 2F is not available.
>  
> In the response the “amr” will indicate if the authentication was with  HW or SW based keys.
>  
> It strikes me that trying to add another LoA complicates things for the RP.  
>  
> I suspect that for initial login most sites will want [ “1F” ] and do [ “2F” , "1F" ]  for step up around specific transactions.  
> Banks will want [ “2F” , "1F" ]  all the time.
> Asking for [ “2F” ]  on its own is not as useful as asking for [ “2F” , "1F" ]  at-least if you get back a LoA with “1F” then you know it is probably the correct person as opposed to any random person who could generate an error,   at that point you can guide them through some other step up or tell them to use a different device etc.  However some people may have limited RP logic and be happier with an error.
>  
> So as an example if the user has authenticated with “2F”  but the RP asks for [ “1F” ] then we would expect the IdP not to prompt (assuming max-age is ok)  and return “2F” as the acr in the response along with a amr indicating if the key was HW or SW protected. 
>  
> It might make sense in non modrna cases to have a RP specifically ask for a HW backed multi-factor.   The IdP could force the user to use a smart card with match on card biometrics on a different computer, rather than using the soft token on the phone.  How ever I don’t think that is our use-case, and having an extra thing the RP can ask for just adds to the complexity.
>  
> If we need to have three for some political reason I would have the IdP treat the two multi-factor as equivalent in the request, and only differentiated in the response.
>  
> Thoughts on paring it down to two?
>  
> John B.
>  
>  
>  
>  
> On Nov 27, 2015, at 2:19 PM, Lodderstedt, Torsten <t.lodderstedt at telekom.de <mailto:t.lodderstedt at telekom.de>> wrote:
>  
> As a RP, I would prefer to send the minimal level I would like the OP to fulfill, e.g. mc2, and I would accept if the OP did better, i.e. authenticated using mc3.
>  
> I think it is evenly important to be clear on the meaning of the levels. Otherwise, the RP does not know what to expect and the OP does not know exactly know what to implement.
>  
> Best regards,
> Torsten.
>  
> Von: John Bradley [mailto:jbradley at mac.com <mailto:jbradley at mac.com>] 
> Gesendet: Freitag, 27. November 2015 15:14
> An: Lodderstedt, Torsten
> Cc: philippe.clement at orange.com <mailto:philippe.clement at orange.com>; openid-specs-mobile-profile at lists.openid.net <mailto:openid-specs-mobile-profile at lists.openid.net>
> Betreff: Re: [Openid-specs-mobile-profile] ACR values
>  
> That is not the normal behaviour for Connect when using the query parameter.  
> We had much debate at the time. 
>  
> We can achieve that with server side policy however.   
>  
> What I think people want is to send a list in preference order  eg [ “mc-2”, “mc-3” ] 
>  
> The IdP must try to do the highest one in the list that the users device supports, if that fails then the IDP will return an error.
>  
> That is the semantic if you use make it an essential claim in the request object.
>  
> Normally if the device only supported “mc-1” or “mc-4" the IdP could try that and return it if successful.  
>  
> I suppose that we could say that if the user can be authenticated at a higher level by the IdP it can do that and return a lower level from the requested list.
>  
> This is probably more important to be clear on than the levels themselves in some ways.
>  
> Is that the behaviour we want to require of the IdP?
>  
> John B.
>  
> On Nov 27, 2015, at 8:51 AM, Lodderstedt, Torsten <t.lodderstedt at telekom.de <mailto:t.lodderstedt at telekom.de>> wrote:
>  
> >If the IdP cant supply one of the acr values by getting the user to step up then it must return a failed authentication attempt.
>  
> I think this is the desired behavior for MODRNA
> _______________________________________________
> 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>
>  
> _______________________________________________
> 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/20151128/04e530c3/attachment-0001.html>


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