[OpenID] Google discovery prototype: dual discovery paths

[Manger, James H]

If we do end up with dual discovery paths:

1.       making a GET request directly to an OpenID identifier; or

2.       following a decoupled discovery path (eg request to Google) backed by trusted signatures on the resultant XRDS files;

then an OpenID login can be compromised by either path.



A motivation for path #2 was that it is hard for a small business to make its website extremely secure from attacks that could modify web pages. However, even RPs that try path #2 will also try path #1 (unless we totally ditch OpenID 1.1 & 2.0 support!) so attacks modifying a small business’s web pages can still compromise their OpenID logins.





One way to prevent dual paths reducing security for each other would be if each path applied to different OpenID identifiers. That is, only use path #1 for http & https OpenID identifiers; and use some other form of OpenID identifier for path #2.





James Manger
James.H.Manger at team.telstra.com<mailto:James.H.Manger at team.telstra.com>
Identity and security team — Chief Technology Office — Telstra

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090717/f55cb9fe/attachment.htm>