<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Apr 1, 2013, at 2:34 PM, Shell &lt;<a href="mailto:cam.turn@gmail.com">cam.turn@gmail.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><blockquote type="cite" style="font-family: Monaco; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite">I propose that IUsernamePassword should be split into at least two<br>interfaces:<br><br>* IUsernamePassword, with only username and password, no methods,<br>which allows password to be used in any way<br>* Another interface, which only defines username and checkPassword() -<br>possibly just a rename of IUsernameHashedPassword, which declares a<br>similar interface<br><br>However, this has the issue that any credential checker which can use<br>the second interface would also be able to use an IUsernamePassword<br>here if there were an adapter between the two, but support for this<br>would have to go into every credential checker which supports the<br>second interface at present. Maybe the Portal could automatically<br>search for adapters if it can't find a direct match?<br></blockquote></blockquote></blockquote></div><br><div>These don't sound like bad ideas, but I think that if you're going to try to fix cred's built-in credentials, this is a pretty labor-intensive and not particularly rewarding path to go down. &nbsp;Further refining the sad username+password credential interface will provide only some internal factoring improvements to existing types of authentication, at the cost of retrofitting all of them; not to mention dealing with broad-spectrum deprecations.</div><div><br></div><div>A better use of energy would be directed at getting a generic SASL credentials implementation; in other words, fixing this fairly ancient ticket: &lt;<a href="https://twistedmatrix.com/trac/ticket/2015">https://twistedmatrix.com/trac/ticket/2015</a>&gt;.</div><div><br></div><div>A well-implemented SASL credentials interface will address these issues, as well as allowing for proper challenge-response authentication, digest auth, external auth mechanisms like TLS, et cetera.</div><div><br></div><div>Your idea about adapters is well taken though; having the portal do that when SASL-ified checkers are available seems reasonable, provided that it won't break anything.</div><div><br></div><div>-glyph</div></body></html>