I'm not sure what there would be to say in the spec about this: SQL injection is not party of the standard, but rather a feature of some implementations :)
[JFM] I agree that many of the ways that have been implemented to date are insecure and that many of the implementors would be well served by running their code bases through tools such as Ouncelabs (www.ouncelabs.com) Coverity (www.coverity.com) and others. I also believe that if the spec further defined what an identifier could look like, implementors could write validation code to make more secure. If an identifier can be anything then you can't really strongly validate. The provider authentication policy extension handles half of this already (telling you what checking the OP did). It does not cover the trust issue though, so without a pre-existing trust relationship there is no reason to believe the PAP assertions. The trust side is something that would be interesting to see addressed in future specs. [JFM] Strongly agree here. OpenID needs to be used for more than just blog sites and free email providers. If businesses who conduct commerce in a B2B scenario were to embrace, the notion of trust needs to be discussed. Likewise, it seems as if many folks here are either consultants or software vendors and having a strong enterprise story could put money into your pockets. This is already possible with OpenID 2.0: 1. make the Sun OP provide an OP identifier URL that can be used to initiate a directed identity request to authenticate any user of the OP. 2. to authenticate, the Sun employee store would initiate an OpenID request against the URL from (1) rather than asking the user to enter an identity URL. With this setup, the user need not know that they are using OpenID or know what their identity URL is. [JFM] I think the scenario I mentioned was an example and not meant to be 1 to 1. Maybe you could tell me how it would work if I had more than one Sun, say Oracle, IBM, BEA and CA. ************************************************************************* This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. ************************************************************************* _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
