[OpenID] OpenID Assertion Quality Extension - Draft
Avery Glasser
aglasser at vxvsolutions.com
Fri Dec 1 20:08:32 UTC 2006
Ok - final small tweak - we'll add in a request parameter
openid.aqe.multifactor_order
values: strict, nopref
Strict - Authentication must be performed in the order (factor1
before factor 2)
Nopref - Authentication can happen in any order
Optional: If not included, then it will be assumed that the RP does
not mandate a specific order (same as nopref)
- Avery
==============================
Avery Glasser
CTO
VxV Solutions, Inc.
+ 1.415.992.7264 - office
+ 1.415.290.1400 - mobile
+ 1.415.651.9218 - fax
329 Bryant Street, Suite 2D
San Francisco, CA 94107
email: aglasser at vxvsolutions.com
i-name: =avery
==============================
This e-mail (including any attachments), is confidential and intended
only
for the use of the addressee(s). It may contain information covered by
legal, professional or other privilege. If you are not an addressee,
please
inform the sender immediately and destroy this e-mail. Do not copy,
forward,
use or disclose this e-mail. Thank you.
On Dec 1, 2006, at 11:48 AM, Paul Madsen wrote:
> 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 general
mailing list