Re: [OpenID] Assertion Quality Extension = openid.importance
Manger, James H wrote: A related hassle is that when my OP supports a new authentication method (such as a strong password-authenticated key agreement scheme (eg SRP)), existing RPs will not recognize this method as strong enough for the RP’s expectations – regardless of the method’s actual strength. Consider also that non-human agents can often be both the OP and the user at the same time (they specify a URL under their own control as the OP, generate their own signature and respond) and in this case the OP knows that the user is the user without any shadow of a doubt because it *is* the user. However, this scenario would fail in any situation where a particular authentication scheme is demanded because there is *no* traditional authentication in this scenario. However, if the RP instead presents (for example) a list of keywords identifying (in vague terms) what is at stake: transaction_involves=money+personal_details ...my non-human agent can pick up that it's being used for something for which it is not intended and refuse to take part. My traditional OP, on the other hand, can present me with a set of options (with reasonable defaults) for what to do in the presence of these keywords so that anything involving money can force a re-authentication (again, for example). Whether a list of keywords is the way to go remains to be seen, but I believe this is the most sensible approach in principle. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [OpenID] Assertion Quality Extension = openid.importance
Justin S. Peavey wrote: I fully agree with you in your example above until you mention money. In the Amazon example for book purchases, the user is not the one affected by a mis-authenticated transaction, Amazon and the credit-card companies are; the user is indemnified by most credit card companies for fraudulent purchases. If the user was *actually bound* to be responsible for the transactions their identities perform, the model works - but this is not the world that I (or Amazon, or Bank of America) live in. Is anyone really expecting an OpenID identity to be used in place of a credit card number? Perhaps I'm just not seeing the advantage of this, but I would expect that most organizations carrying out credit card transactions would: * Use OpenID to authenticate the user against the account to gain access to the purchase history, returns, enquiries and such. * Demand the user's credit card before actually performing any transaction. While I'll admit that Amazon and PayPal currently store credit card details and require (in some cases) only the password to be entered, it can hardly be argued that my Amazon password is any more secure than my IdP password. In Amazon's case they still don't let you make a purchase knowing only the password in most cases; you have to provide all or part of the stored credit card number or other authentication details. But this is all beside the point given the fact that the OP *is always in control* — there is NO WAY that the RP can tell what the OP really did. The OP can lie, the OP can have a bad implementation of a given authentication scheme or the OP might not even be a traditional OP at all. I don't really see the value in presenting a protocol which gives an illusion of control to the RP; it just seems dishonest. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [OpenID] Assertion Quality Extension = openid.importance
Manger, James H wrote: The user-centric solution is not for the RP to specify a max auth age (or captcha or email verification or handbio or hardotp…), but for the RP to indicate the importance of the authentication. The user (with a little help from their OP) decides how to react (eg whether or not to login again) based on the importance/RP/auth-age/…. I like this approach a lot more. It seems a lot more honest as to what's really going on, and it leaves protecting the task of user's interests in the IdP's hands where it belongs. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [OpenID] Assertion Quality Extension = openid.importance
Paul Madsen wrote: Is there not a potential contradiction between an RP expressing both of 'this is very very important to me' and 'I leave it to you as to the specifics'? Perhaps, but that is the case in both the IdP reports and the RP suggests case: either way the IdP is calling the shots, but the RP suggests case is more honest about who is in control. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [OpenID] Assertion Quality Extension = openid.importance
The RP is not saying “this is very very important to *me*”. It is saying “in my opinion, this is likely to be very very important to *you*”. Consequently, it is not a contradiction for the RP to also say “I leave it to you as to the specifics”. Does participating in OpenID mean the RP giving up this policy control? Yes, fully participating in OpenID means the RP gives up some policy control. An RP cannot simultaneously 1) accept its users choices of OPs, and 2) get trusted assertions as to the authentication quality. The first implies accepting any OP. The second implies accepting only the small subset of OPs trusted by the RP. How many such RPs will be willing to pay this price? For most RPs there shouldn’t be a high price (if any price). When the login only gives access to the user’s own resources (be they colour preferences, reputation, personal details, money…), then any inappropriately weak authentication of the user by their OP only affects that user. The user pays a price, but not the RP. This scenario covers a lot of services: Amazon (user’s book preferences, user’s payments); hotmail (user’s inbox); flickr (user’s photos)… An RP may pay an indirect price. The law may not accept that the user was in total control of the authentication mechanism so the user (not the RP) bears all responsibility. A big scenario not covered is corporate access: the RP is a company, the user is an employee. Login gives the user access to resources, but the RP still owns the resources. Some control over the resources is delegated to the user, but not all. Solutions: a) don’t use openid, b) trust your employees, c) use openid but only accept selected OPs. Fundamentally, I don't see how acknowledging that the RP may have certain expectations of the authentication event is somehow in conflict with user-centrism. The hassle is that an RP expectation for, say, “hardotp” will prevent my spec-compliant OP software from logging me in even if I am using a triple-factor iris scan, 20-char password and smartcard to authenticate myself to my OP. A related hassle is that when my OP supports a new authentication method (such as a strong password-authenticated key agreement scheme (eg SRP)), existing RPs will not recognize this method as strong enough for the RP’s expectations – regardless of the method’s actual strength. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [OpenID] Assertion Quality Extension = openid.importance
Manger, James H wrote: For most RPs there shouldn’t be a high price (if any price). When the login only gives access to the user’s own resources (be they colour preferences, reputation, personal details, money…), then any inappropriately weak authentication of the user by their OP only affects that user. The user pays a price, but not the RP. This scenario covers a lot of services: Amazon (user’s book preferences, user’s payments); hotmail (user’s inbox); flickr (user’s photos)… I fully agree with you in your example above until you mention money. In the Amazon example for book purchases, the user is not the one affected by a mis-authenticated transaction, Amazon and the credit-card companies are; the user is indemnified by most credit card companies for fraudulent purchases. If the user was *actually bound* to be responsible for the transactions their identities perform, the model works - but this is not the world that I (or Amazon, or Bank of America) live in. The hassle is that an RP expectation for, say, “hardotp” will prevent my spec-compliant OP software from logging me in even if I am using a triple-factor iris scan, 20-char password and smartcard to authenticate myself to my OP. A related hassle is that when my OP supports a new authentication method (such as a strong password-authenticated key agreement scheme (eg SRP)), existing RPs will not recognize this method as strong enough for the RP’s expectations – regardless of the method’s actual strength. Perhaps, but I support the concept you stated earlier of not specifying the authentication method directly between the RP and OP, but agreeing on the 'importance' - what I expect will happen will be the OP and (higher-risk) RPs will first need to come to agreement (perhaps with eventual guidance/oversight from another standard or regulating body) on what types/methods/frequency of authentication equates to which 'strength'. This gets the RPs out of the gory details but still having their a$$ covered - but with the potential of shifting some of the liability to the OP e.g. failure to meet the agreement. We've already seen such authentication guidance emerging from the FFIEC, clearly the Fed does not like the concept of an authentication free-for-all for online banking. In a commercial sense, I just don't see (higher-risk) RPs accepting identities from just any mom/pop OP; the economics just don't support this. -Justin ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [OpenID] Assertion Quality Extension = openid.importance
What happened to all the concern about openid.auth_age (in early October)? I echo Kevin Turner's worry that “features like this will mislead the RP developers into thinking they have more control over the authentication protocol than they really do… when OpenID actually leaves all those controls in the hands of the user and their chosen IdP”. [http://openid.net/pipermail/specs/2006-October/000223.html] Dick Hardt’s Amazon.com use case makes sense: amazon.com may be quite happy to use an arbitrarily old authentication to personalise your browsing, but when you go to purchase something they want to make sure it is still you (and prompt you for your password). The user-centric solution is not for the RP to specify a max auth age (or captcha or email verification or handbio or hardotp…), but for the RP to indicate the importance of the authentication. The user (with a little help from their OP) decides how to react (eg whether or not to login again) based on the importance/RP/auth-age/…. Spec changes: specify an openid.importance attribute to be included in an authentication request and echoed in the response; define some standard values (eg “low”, “medium”, “high”, “session”, “transaction”, “money”, “privacy”, “corporate”, “reputation”…); encourage OPs to allow users to control how when to reauthenticate based on the importance and RP. Surely the Assertion Quality Extension (AQE) will just encourage RP to only support a small number of OPs that the RP can trust to enforce the RP’s rules. James Manger ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
