[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