[OpenID] Delegation leading to new accounts on websites

[Andrew Arnott]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090710/99298dbf/attachment.htm>