I2 OpenID Provider results with OpenID Relying Parties
From OSIS Open Source Identity Systems
Legend: Works = Working as expected; Issues = Working but with identified issues; Failed = Didn't work; n/a = Not Applicable; (blank) = Not tested
Each tested entry should link to a wiki page describing the tests performed and saying who performed them.
| Interop Combination | Sxip PapeDemo RP | Sxip openidcards RP | Sxip AXDemo RP | JanRain RP |
|---|---|---|---|---|
| Sxipper | Works | n/a | Works | Works |
| Sxip openidcards STS/OP | n/a | Works | n/a | n/a |
| MyOpenID | Works | n/a | Issues | Works |
| ooTao | Issues | n/a | Issues | |
| VeriSign JPIP | Issues | n/a | Issues | Works |
| Ping SignOn.com | Works | n/a | Issues | Works |
The interoperability testing surfaced several issues that will be discussed and resolved on the appropriate mailing lists:
1 - Should an RP fail authentication if OP cannot satisfy RP requested policy? This is more of a best practices issue. The consensus on the interop list was that there may be use cases where an RP may want to allow a deprecated mode of sign-in if the security policy was not satisifed. The minority opinion was that this was more of an edge case and that the typical use case would be that the RP would not consider authentication successful if the security policy requested was not satisfied.
2 - If the OP uses stronger auth then what RP requested so that syntatctically they are not a string match, but semantically the OP satisfied/exceeded RP policy request should the OP return the policy used or the policy requested by the RP? For example, if RP requests multi-factor and OP uses pki certs stored on smart cards, should the OP return multi-factor-physical and let RP decide the policy was satisfied, or should the OP return multi-factor to let the RP know the policy was satisifed even if the policy used was actually different. The PAPE spec may need to be clarified or a best practice for purposes of interoperability defined.
3 - While phishing-resistant is defined in PAPE spec, some in the industry appear to want a weaker definition that would allow more authentication methods to be considered "phishing-resisant" -- even some that are inherently phishable! Thus, the term "phishing-resistant" seems to still be subject to interpretation in the industry. The definition of phishing-resistant needs to be clarified in the spec since presently some consider it more of a value judgement than an objective claim about the authentication mechanism.
