Re: [OpenID] Mailing List etiquette question.
the general etiquete is to avoid me-too posts. Another general rule is that general rules are superceded by specific rules. When the question is a show of support or opposition to a proposal, brief yea/nays from all are acceptable. The question of what to think of the silence following a substantial post to a list -- was it so good that there was nothing to add, or was it so bad that it was not worth pointing that out? -- is known as "Warnock's Dilemma" after Brian Warnock, who succinctly described it on a perl 6 discussion list in 2000. (ever since I seem to be evangelizing the term, having gotten it listed in Wired Jargon Watch for instance) Warnock's dilemma is very similar, in human behavior terms, to the aspects of human nature that allow all passerby to not intervene in ongoing violence in urban settings, for instance. There's a term for that too but it's been too many years since I took that psychology course. On 11/30/06, Scott Kveton <[EMAIL PROTECTED]> wrote: > +1. Don't be shy to speak your mind. > > 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. > > On the other hand, [posting a "me too"] almost seems like spamming the list -- perl -le'1while(1x++$_)=~/^(11+)\1+$/||print' ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [OpenID] OpenID Assertion Quality Extension - Draft
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 e
Re: [OpenID] OpenID Assertion Quality Extension - Draft
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 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 3) Suggest openid.aqe.auth_factor2 MUST NOT be present unless openid.aqe.auth_factor1 is present 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" paul 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 O
