[OpenID] OpenID Assertion Quality Extension - Draft

Paul Madsen paulmadsen at rogers.com
Fri Dec 1 19:48:17 UTC 2006


Avery, below

Avery Glasser wrote:
> Paul,
>
> My feedback to your feedback...
>
>
>> Hi Avery, some minor tweaks/comments
>>
>> 1) the line 'the first method that the RP would like the OP to 
>> perform' could be interpreted as constraining the O/IDP to  
>> performing whatever authentication mechanism is listed as the first 
>> in a temporal sequence, i.e. must do X then Y
>>
>> This could be overly restrictive
>>
>
> Actually, that is the specific intent - the RP is requesting a 
> specific order. If the OP can honor the order, that is fine. If not, 
> then the OP reports back to the RP what the order was in the response. 
> As long as the two methods are honored, then the RP should accept the 
> authentication.
If the RP specified a particular order and didn't see it come back in 
the IDP response, it has a choice, accept the assertion regardless, or 
not. If the latter, how can it indicate to the IDP in a second 
authentication request 'This time I mean it?'

I think you either say order isn't important in the request, or, if it 
is, give the IDP a mechanism to say it couldn't satisfy the order.

paul
>
>> 2) the line 'If the two modes are considered equally strong, then it 
>> is the choice of the OP regarding which one or ones to authenticate 
>> against' could confuse, as the 'or ones' would seem to allow the OP 
>> to choose multiple modes from within the openid.aqe.auth_factor2
>>
>
> Agreed. I would change that to "the one" - since each factor now 
> refers to a specific authentication method.
>
>> 3) Suggest openid.aqe.auth_factor2 MUST NOT be present unless 
>> openid.aqe.auth_factor1 is present
>>
>
> Agreed.
>
>> 4) The line 'If this is not specified, it is assumed that the RP is 
>> requesting only a single factor for authentication' in the context of 
>> openid.aqe.auth_factor2 should probably read
>>
>> "If this is not specified, it is assumed that the RP is requesting 
>> only a single factor for authentication (if openid.aqe.auth_factor2 
>> is specified ) or not requesting a particular authentication method"
>>
>
> Agreed.
>
>>
>> paul
>>
>
> Based on this, is there any other feedback, or shall we revise the 
> specification?
>
> - Avery
>
>> Avery Glasser wrote:
>>> Just to weigh in here...
>>>
>>>>
>>>> Paul Madsen wrote:
>>>>> Hi George, for your use case below, why would not the RP just ask 
>>>>> for the user to be up-authenticated at the desired higher level 
>>>>> when necessary?
>>>> So in the draft... how does the RP ask for the user to be 
>>>> "up-authenticated"?  The authentication request parameters do not 
>>>> in any way indicate a previous authentication, and the extension 
>>>> parameters also don't include any way to indicate a previous 
>>>> authentication.  That is what I really meant by the authentications 
>>>> being "standalone".  The RP may relate the two authentications in 
>>>> some way because it requested both.  Maybe that's good enough.
>>> Basically, you would require the second method with a max_age of "0" 
>>> - which, assuming the RP honors the request,  would tell the RP to 
>>> re-authenticate the user with the requested method.
>>>>>
>>>>> Are you asking whether the RP should be allowed to ask the user to 
>>>>> re-present their URI in order for this to happen? And thereby 
>>>>> effectively treating each event as disconnected/standalone?
>>>> Ideally, the user would not be able to change their URI when being 
>>>> re-challenged based on max_auth_age but I guess the RP should make 
>>>> sure to code for that edge case.
>>> Agreed - it's the RPs choice.
>>>
>>>>>
>>>>> Wrt combinations, I know from experience that the alternative to 
>>>>> allowing for RPs to specify combinations is a combinatorial 
>>>>> explosion in the number of  mechanism identifiers.
>>>> I agree that the combinations can explode... but they are also 
>>>> useful.  For example to hack my account you need both my "password" 
>>>> and my "hardotp". That's two "secrets" that need to be determined 
>>>> for my account to be compromised. (Not that this doesn't stop 
>>>> phishers).
>>>>
>>>
>>> Actually, this could be pretty simple to implement:
>>>
>>> Replace  openid.aqe.preferred_auth_mode with the following:
>>>
>>> openid.aqe.auth_factor1
>>>
>>> Optional: The method of authentication the RP would like the OP to 
>>> perform, or in the case of a multi-factor authentication, the first 
>>> method that the RP would like the OP to perform. The mode should 
>>> match one of the advertised values in the XRDS. If this is not 
>>> specified, then any authentication method is acceptable.
>>>
>>> Value: Comma-delimited list of "none", "password", "pin", 
>>> "fingerbio", "handbio", "hardotp", "irisbio", "otherbio", 
>>> "smartcard", "softotp", "voicebio"
>>>
>>> Note: The OP should attempt to authenticate the user with the most 
>>> secure mode requested. For example, if the OP has determined that 
>>> their voicebio method is stronger than their password method and the 
>>> RP requests either "voicebio or password", the OP should strive to 
>>> authenticate the user by "voicebio" when possible. If the two modes 
>>> are considered equally strong, then it is the choice of the OP 
>>> regarding which one or ones to authenticate against. OPs should note 
>>> that authenticating a user by a non-preferred method may result in 
>>> an RP denying access.
>>>
>>> openid.aqe.auth_factor2
>>>
>>> Optional: In the case of a multi-factor authentication, the second 
>>> method that the RP would like the OP to perform. The mode should 
>>> match one of the advertised values in the XRDS. If this is not 
>>> specified, then any authentication method is acceptable. If this is 
>>> not specified, it is assumed that the RP is requesting only a single 
>>> factor for authentication. The OP will not use the same method for 
>>> this factor as was used in any previous factors. For example, if the 
>>> first factor is a password, the second factor cannot also be a 
>>> password.
>>>
>>> Value: Comma-delimited list of "none", "password", "pin", 
>>> "fingerbio", "handbio", "hardotp", "irisbio", "otherbio", 
>>> "smartcard", "softotp", "voicebio"
>>>
>>> Note: The OP should attempt to authenticate the user with the most 
>>> secure mode requested. For example, if the OP has determined that 
>>> their voicebio method is stronger than their password method and the 
>>> RP requests either "voicebio or password", the OP should strive to 
>>> authenticate the user by "voicebio" when possible. If the two modes 
>>> are considered equally strong, then it is the choice of the OP 
>>> regarding which one or ones to authenticate against. OPs should note 
>>> that authenticating a user by a non-preferred method may result in 
>>> an RP denying access.
>>>
>>> openid.aqe.auth_factor3
>>>
>>> ... you can figure how it would continue. There are very few use 
>>> cases that would use more than two factors.
>>>
>>>
>>> So, in this case, if you want the user to authenticate with two 
>>> factors, first with a password and second with a securID or voice 
>>> biometric print...
>>>
>>>
>>> openid.aqe.auth_factor1 = "password"
>>>
>>> openid.aqe.auth_factor2 = "hardotp", "voicebio"
>>>
>>>
>>> conversely, if you want two factors, which could be any combination 
>>> of password, hardotp or voicebio in any combination:
>>>
>>>
>>> openid.aqe.auth_factor1 = "hardotp", "voicebio", "password"
>>>
>>> openid.aqe.auth_factor2 = "hardotp", "voicebio", "password"
>>>
>>>
>>>
>>> the response from the OP, assuming that it followed the request from 
>>> the RP would look like
>>>
>>> openid.aqe.auth_factor1 = "password"
>>>
>>> openid.aqe.auth_factor2 = "hardotp"
>>>
>>>
>>> I would think that this is clear enough that we could make the small 
>>> change to the spec to allow for this type of methodology.
>>> Thoughts?
>>>
>>> - Avery
>>>
>>>> Thanks,
>>>> George
>>>>
>>>>>
>>>>> Paul
>>>>>
>>>>> George Fletcher wrote:
>>>>>> +1 simple and straight forward
>>>>>>
>>>>>> Just curious about uses cases where the required authentication 
>>>>>> level changes over time.  For instance, a use case where to view 
>>>>>> my stock portfolio just requires "password", but doing a trade 
>>>>>> requires "voicebio".  Is the expectation that authentication 
>>>>>> events can be treated as "standalone"? or that it's the RP's 
>>>>>> responsibility to manage the combinations based on the identifier?
>>>>>>
>>>>>> One final question... Is it valuable to provide a way to request 
>>>>>> two or more authentication methods be employed in the 
>>>>>> authentication event?  For example, administrators of a site must 
>>>>>> use both "password" and "hardotp".  Everyone else just needs 
>>>>>> "password".
>>>>>>
>>>>>> Thanks,
>>>>>> George
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> general mailing list
>>>>>> general at openid.net
>>>>>> http://openid.net/mailman/listinfo/general
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>> _______________________________________________
>>>> general mailing list
>>>> general at openid.net <mailto:general at openid.net>
>>>> http://openid.net/mailman/listinfo/general
>>>
>>> ------------------------------------------------------------------------ 
>>>
>>>
>>> No virus found in this incoming message.
>>> Checked by AVG Free Edition.
>>> Version: 7.1.409 / Virus Database: 268.15.0/557 - Release Date: 
>>> 11/29/2006
>>>
>>
>> --Paul Madsen             e:paulmadsen @ ntt-at.com
>> NTT                     p:613-482-0432
>>                        m:613-302-1428
>>                        aim:PaulMdsn5
>>                        web:connectid.blogspot.com
>
>
>
> --No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.409 / Virus Database: 268.15.2/560 - Release Date: 
> 11/30/2006
>
>

-- 
Paul Madsen             e:paulmadsen @ ntt-at.com
NTT                     p:613-482-0432
                        m:613-302-1428
                        aim:PaulMdsn5
                        web:connectid.blogspot.com 




More information about the specs mailing list