[Openid-specs-mobile-profile] ACR values

Torsten Lodderstedt torsten at lodderstedt.net
Sun Nov 29 18:30:39 UTC 2015

Hi John,

I understand your argument. It's always a trade off between being 
specific (and risking failed authentication attempts) and being to 
generic (and loose control). I think there is no difference between 
having two LOAs + 2 AMRs on one side or having 3 LOAs, if the AMR is 
required from a RP's perspective to assess the authentication. But let's 
assume we go with two LOAs for single and 2 factor authn.

I think just single factor won't be enough, as Mobile Connect (according 
to my understanding/interpretation) is about password-less single factor 
authentication. So I assume we need to have a certain special single 
factor authentication ACR value.

best regards,

Am 28.11.2015 um 22:19 schrieb John Bradley:
> 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 <mailto: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 
>> <mailto: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]
>>     *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
>>         authenticationattempt.
>>         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
>>     _______________________________________________
>>     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
> _______________________________________________
> Openid-specs-mobile-profile mailing list
> Openid-specs-mobile-profile at lists.openid.net
> 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/20151129/d2c66964/attachment-0001.html>

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