I like your adjustment, Peter.<div><br clear="all">--<br>Andrew Arnott<br>"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - Voltaire<br>
<br><br><div class="gmail_quote">On Wed, Feb 11, 2009 at 7:38 AM, Peter Watkins <span dir="ltr"><<a href="mailto:peterw@tux.org">peterw@tux.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
On Tue, Feb 10, 2009 at 04:03:52PM -0800, Andrew Arnott wrote:<br>
<br>
> OpenID Providers should consider hosting the following OpenID Identifiers<br>
> for which positive or negative assertions will always be immediately<br>
> generated with no interaction with the user agent in order to provide RPs<br>
> under test to programmatically check their compatibility with your Provider:<br>
> <a href="http://provider/TestIdentifierAlwaysAssert" target="_blank">http://provider/TestIdentifierAlwaysAssert</a> (or<br>
> <a href="http://TestIdentifierAlwaysAssert.provider/" target="_blank">http://TestIdentifierAlwaysAssert.provider/</a>)<br>
> <a href="http://provider/TestIdentifierAlwaysRefuse" target="_blank">http://provider/TestIdentifierAlwaysRefuse</a> (or<br>
> <a href="http://TestIdentifierAlwaysRefuse.provider/" target="_blank">http://TestIdentifierAlwaysRefuse.provider/</a>)<br>
> <a href="http://provider/TestIdentifierAssertOnSetup" target="_blank">http://provider/TestIdentifierAssertOnSetup</a> (or<br>
> <a href="http://TestIdentifierAssertOnSetup.provider/" target="_blank">http://TestIdentifierAssertOnSetup.provider/</a>)<br>
<br>
If I understand you correctly, that you expect those to be discoverable<br>
URLs, I don't think that would work very well. Those suggestions make<br>
assumptions about DNS and server configuration for the IdP/OP. None of<br>
those fit our systems -- when/if we move from being just an RP that also<br>
has "local" accounts to providing OP service for our local account holders,<br>
we'll be using directed identity with identifiers that map back to our<br>
OP application, like<br>
<br>
<a href="https://apps.example.com/OurLogin/OpenID/id.aspx?id=TestIdentifierAlwaysAssert" target="_blank">https://apps.example.com/OurLogin/OpenID/id.aspx?id=TestIdentifierAlwaysAssert</a><br>
<br>
I think a better model would be reserving certain keywords and treating<br>
any identifier that *includes* that keyword anywhere in the URL (excluding<br>
any # fragment!) would be treated as a test identifier, e.g.<br>
<br>
Some possible "__oid2test__TestIdentifierAlwaysAssert" URLs/identifiers:<br>
<br>
(http|https)://provider/__oid2test__TestIdentifierAlwaysAssert<br>
(http|https)://provider/__oid2test__TestIdentifierAlwaysAssert/<br>
(http|https)://provider/path/app.jsp?__oid2test__TestIdentifierAlwaysAssert<br>
(http|https)://provider/path/app.aspx?u=__oid2test__TestIdentifierAlwaysAssert<br>
(http|https)://__oid2test__TestIdentifierAlwaysAssert.provider/<br>
<br>
Testing RPs should be able to send a claimed identifier that has a keyword<br>
to the OP. The only expectation for the response should be that its identfier<br>
(for cases like TestIdentifierAlwaysAssert that generate positive assertions)<br>
would include the same keyword that was present in the RP request. If the<br>
RP can figure out how to make a normal, non-directed discoverable URL with<br>
a keyword that maps to an OP (<a href="https://me.yahoo.com/__oid2test__TestIdentifierAlwaysAssert" target="_blank">https://me.yahoo.com/__oid2test__TestIdentifierAlwaysAssert</a> ?), that'd be fine, too.<br>
<font color="#888888"><br>
-Peter<br>
<br>
</font></blockquote></div><br></div>