Re: OpenID Assertion Quality Extension - Draft

2006-11-30 Thread George Fletcher
+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


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


Re: [OpenID] OpenID Assertion Quality Extension - Draft

2006-11-30 Thread Paul Madsen
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?

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?

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.

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


   

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

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


Re: [OpenID] OpenID Assertion Quality Extension - Draft

2006-11-30 Thread George Fletcher





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.


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.


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).

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



 
  



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


RE: [OpenID] OpenID Assertion Quality Extension - Draft

2006-11-30 Thread Drummond Reed
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 

Re: [OpenID] OpenID Assertion Quality Extension - Draft

2006-11-30 Thread George Fletcher




+1

Avery Glasser wrote:

  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
  



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


Re: Mailing List etiquette question.

2006-11-30 Thread Scott Kveton
+1.  Don't be shy to speak your mind.



On 11/30/06 6:48 PM, Recordon, David [EMAIL PROTECTED] wrote:

 Hi Gavin,
 As being one that often floats proposals to the list, I'd encourage people to
 voice their opinions even if it is just agreeing with someone else.  With
 silence it is hard to know if people agree with you, think you're crazy, don't
 care, or haven't read it.
 
 --David
 
 
  -Original Message-
 From:   Gavin Baumanis [mailto:[EMAIL PROTECTED]
 Sent:   Thursday, November 30, 2006 06:35 PM Pacific Standard Time
 To: [EMAIL PROTECTED]; specs@openid.net
 Subject:Mailing List etiquette question.
 
 Hi everyone,
 
 Just a quick question.
 I was about to send a reply in support of Avery's suggestion, but before I did
 thought I would ask;
 
 Is it appropriate to respond to the list with,
 Yes - I agree  - that seems like a simple / easily implemented solution
 (in essence adding support to the proposal, allowing all subscribers to gauge
 the worthiness of the suggestion - yet, not adding in any new information)
 
 On the other hand, it almost seems like spamming the list?
 
 Thanks.
 
 Gavin
 RMIT University, Melbourne, Australia.
 ___
 specs mailing list
 specs@openid.net
 http://openid.net/mailman/listinfo/specs

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