[OpenID] Delegation leading to new accounts on websites
John Panzer
jpanzer at acm.org
Fri Jul 10 23:59:46 UTC 2009
Too bad. Good nit to fix in a potential future rev when libraries need
upgrading anyway.
On Fri, Jul 10, 2009 at 3:02 PM, John Bradley <john.bradley at wingaa.com>wrote:
> The spec is quite specific http: , https: URI or XRI.
>
> I suspect that RPs that support XRI will be more forgiving. Other libs may
> be using underlying libraries that are validating them as URL.
>
> If that assumption had not been built into the spec any string would have
> been appropriate.
>
> Some of those same assumptions break IRI as openID.
>
> John B.
>
> On 10-Jul-09, at 5:49 PM, John Panzer wrote:
>
> (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?)
>>
>> On Fri, Jul 10, 2009 at 1:57 PM, Andrew Arnott <andrewarnott at gmail.com>
>> wrote:
>> Johnny,
>>
>> 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.
>>
>> --
>> Andrew Arnott
>> "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
>>
>>
>> 2009/7/10 Johnny Bufu <johnny.bufu at gmail.com>
>>
>> > On Tue, Jul 7, 2009 at 4:03 PM, Johnny Bufu <johnny.bufu at gmail.com>
>> wrote:
>> > > Doesn't even have to be a URI even; what matters is that the OP issues
>> > > it, so they (can) have full control/authority over it if that's a
>> > > concern for them.
>>
>> On Thu, Jul 09, 2009 at 01:20:07PM -0700, Breno de Medeiros wrote:
>> > It does need to be an URI (at least for OpenID). See the spec definition
>> of
>> > identifiers.
>>
>> That part was overspecified, mostly for keeping the spec simpler by
>> having all identifiers be a subclass of URI and at the expense of some
>> flexibility for the OPs (if they choose to be strict about this).
>>
>> But from a practical / protocol point of view, the OPs are the only ones
>> that produce (issue) and consume (recognize/authenticate) delegate
>> identifiers, while the rest of the parties involved pass around and
>> compare them as opaque strings.
>>
>>
>> Johnny
>>
>>
>> _______________________________________________
>> general mailing list
>> general at openid.net
>> http://openid.net/mailman/listinfo/general
>>
>>
>> _______________________________________________
>> general mailing list
>> general at openid.net
>> http://openid.net/mailman/listinfo/general
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090710/17cec120/attachment.htm>
More information about the general
mailing list