Avery,

 

Paul's the one to weigh in on this option - he wrote (and lived) the book on
SAML AuthN Context. But I do like the looks of what you proposed - seems
very elegant.

 

=Drummond 

 

  _____  

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Avery Glasser
Sent: Thursday, November 30, 2006 2:22 PM
To: George Fletcher
Cc: specs@openid.net; [EMAIL PROTECTED]
Subject: Re: [OpenID] OpenID Assertion Quality Extension - Draft

 

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 
[EMAIL PROTECTED] 
http://openid.net/mailman/listinfo/general 



 

_______________________________________________

general mailing list

[EMAIL PROTECTED]

http://openid.net/mailman/listinfo/general

 

_______________________________________________
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Reply via email to