Too bad. Good nit to fix in a potential future rev when libraries need upgrading anyway.<br><br><div class="gmail_quote">On Fri, Jul 10, 2009 at 3:02 PM, John Bradley <span dir="ltr"><<a href="mailto:john.bradley@wingaa.com">john.bradley@wingaa.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">The spec is quite specific http: , https: URI or XRI.<br>
<br>
I suspect that RPs that support XRI will be more forgiving. Other libs may be using underlying libraries that are validating them as URL.<br>
<br>
If that assumption had not been built into the spec any string would have been appropriate.<br>
<br>
Some of those same assumptions break IRI as openID.<br>
<br>
John B.<div><div></div><div class="h5"><br>
On 10-Jul-09, at 5:49 PM, John Panzer wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
(What practical constraint does this impose on OPs -- which comes down to asking, what strings would cause an exception when processed by the set of existing RP libraries? Is urn:isbn:0-486-27557-4 okay, for example?)<br>
<br>
On Fri, Jul 10, 2009 at 1:57 PM, Andrew Arnott <<a href="mailto:andrewarnott@gmail.com" target="_blank">andrewarnott@gmail.com</a>> wrote:<br>
Johnny,<br>
<br>
I agree that RPs should treat them as opaque strings, but due to the constraints in the spec, I can name at least a couple of .NET openid libraries that would choke on openid.local_id values if they were not XRIs or URIs. I'm for loosening this up, but in the meantime, OPs should please conform to this constraint to avoid breaking RPs.<br>
<br>
--<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." - S. G. Tallentyre<br>
<br>
<br>
2009/7/10 Johnny Bufu <<a href="mailto:johnny.bufu@gmail.com" target="_blank">johnny.bufu@gmail.com</a>><br>
<br>
> On Tue, Jul 7, 2009 at 4:03 PM, Johnny Bufu <<a href="mailto:johnny.bufu@gmail.com" target="_blank">johnny.bufu@gmail.com</a>> wrote:<br>
> > Doesn't even have to be a URI even; what matters is that the OP issues<br>
> > it, so they (can) have full control/authority over it if that's a<br>
> > concern for them.<br>
<br>
On Thu, Jul 09, 2009 at 01:20:07PM -0700, Breno de Medeiros wrote:<br>
> It does need to be an URI (at least for OpenID). See the spec definition of<br>
> identifiers.<br>
<br>
That part was overspecified, mostly for keeping the spec simpler by<br>
having all identifiers be a subclass of URI and at the expense of some<br>
flexibility for the OPs (if they choose to be strict about this).<br>
<br>
But from a practical / protocol point of view, the OPs are the only ones<br>
that produce (issue) and consume (recognize/authenticate) delegate<br>
identifiers, while the rest of the parties involved pass around and<br>
compare them as opaque strings.<br>
<br>
<br>
Johnny<br>
<br>
<br>
_______________________________________________<br>
general mailing list<br>
<a href="mailto:general@openid.net" target="_blank">general@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
<br>
<br>
_______________________________________________<br>
general mailing list<br>
<a href="mailto:general@openid.net" target="_blank">general@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
<br>
<br>
</blockquote>
<br>
</div></div></blockquote></div><br>