[OpenID] Community Opinion on OID 2.1 Discovery and Identifiers...
John Bradley
john.bradley at wingaa.com
Sun Jun 7 11:54:13 PDT 2009
--Apple-Mail-329--194318239
Content-Type: text/plain;
charset=US-ASCII;
format=flowed;
delsp=yes
Content-Transfer-Encoding: 7bit
David,
I think it comes down to deciding what our abstract identity model for
openID is and proceeding from there.
The conflict between URLs and XRI has more to do with having multiple
names that resolve to a single claimed_id where with URLs there is a
one to one relationship. I believe it was that impedance mismatch
more than library complexity that prevented people from seeing any
advantage to XRI.
The two identifier types also have different approaches to identifier
recycling, and portability.
We need a single model and then fit the identifiers to it rather than
trying to adapt the core to the identifiers in a piecemeal fashion.
The first questions we need to answer:
1. Are we going to support many to one relationships, or enforce a
one to one relationship?
2. Are we going to support identifier portability?
3. Are we going to decouple the display ID from the primary key?
John B.
On 7-Jun-09, at 11:13 AM, David Fuelling wrote:
> Replies inline...
>
> On Fri, Jun 5, 2009 at 10:03 PM, John Bradley
> <john.bradley at wingaa.com> wrote:
> I am referring to identifier abstraction to make certain that we
> clearly understand the need for a primary key vs a display identifier.
>
> +1. This is a very valid issue.
>
>
> We ran into this with XRI and the presumption that the claimed_id is
> what is displayed for the user.
>
> With XMPP identifiers you may have multiple identifiers that resolve
> to the same XRD and hence have the same claimed_id but may want your
> input identifier represented in some way.
>
> Perhaps we need more that one identifier at the API layer.
>
> +1.
>
>
> What I am saying is that if the core spec assumes URI then there
> will be a built in bias as there is now.
>
> Wondering _how_ you would describe an OpenID Identifier if it's not
> a URI...would you specify string-text (with x,y, z, etc as allowed
> characters)? Or anything goes?
>
> The only reason I ask is that is seems most Identifiers (in the
> generic sense) are URI's with a scheme: (http://; xri://; ldap://;
> mailto:; uri://; etc).
>
> Are JID's not URI's?
>
> We need to consider how provider portability could be achieved or at-
> least not be precluded by core design choices.
>
> +1
>
>
>
--Apple-Mail-329--194318239
Content-Type: text/html;
charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">David,<div><br></div><div>I =
think it comes down to deciding what our abstract identity model for =
openID is and proceeding from =
there.</div><div><br></div><div>The conflict between URLs and XRI has =
more to do with having multiple names that resolve to a =
single claimed_id where with URLs there is a one to one =
relationship. I believe it was =
that impedance mismatch more than library complexity that =
prevented people from seeing any advantage to =
XRI.</div><div><br></div><div>The two identifier types also =
have different approaches to identifier recycling, and =
portability.</div><div><br></div><div>We need a single model and then =
fit the identifiers to it rather than trying to adapt the core =
to the identifiers in =
a piecemeal fashion.</div><div><br></div><div>The first =
questions we need to answer:</div><div>1. Are we going to support =
many to one relationships, or enforce a one to one =
relationship?</div><div>2. Are we going to support identifier =
portability?</div><div>3. Are we going to decouple the display ID =
from the primary key?</div><div><br></div><div>John =
B.</div><div><br><div><div>On 7-Jun-09, at 11:13 AM, David Fuelling =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite">Replies inline...<br><br><div class=3D"gmail_quote">On =
Fri, Jun 5, 2009 at 10:03 PM, John Bradley <span dir=3D"ltr"><<a =
href=3D"mailto:john.bradley at wingaa.com">john.bradley at wingaa.com</a>></s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"border-left: =
1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: =
1ex;"> <div style=3D""><div>I am referring to identifier =
abstraction to make certain that we clearly understand the need for a =
primary key vs a display =
identifier.</div><div></div></div></blockquote><div><br>+1. This =
is a very valid issue. <br> <br></div><blockquote class=3D"gmail_quote" =
style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt =
0.8ex; padding-left: 1ex;"><div style=3D""><div><br></div><div>We ran =
into this with XRI and the presumption that the claimed_id is what =
is displayed for the user.</div> <div><br></div><div>With XMPP =
identifiers you may have multiple identifiers that resolve to the same =
XRD and hence have the same claimed_id but may want your input =
identifier represented in some way.</div><div><br></div><div> Perhaps we =
need more that one identifier at the API =
layer.</div><div></div></div></blockquote><div><br>+1. =
<br> </div><blockquote class=3D"gmail_quote" style=3D"border-left: =
1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: =
1ex;"> <div style=3D""><div><br></div><div>What I am saying is that if =
the core spec assumes URI then there will be a built in bias as there is =
now.</div><div></div></div></blockquote><div><br>Wondering _how_ you =
would describe an OpenID Identifier if it's not a URI...would you =
specify string-text (with x,y, z, etc as allowed characters)? Or =
anything goes?<br> <br>The only reason I ask is that is seems most =
Identifiers (in the generic sense) are URI's with a scheme: (http://; =
xri://; ldap://; mailto:; uri://; etc).<br><br>Are JID's not =
URI's?<br> </div><blockquote class=3D"gmail_quote" =
style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt =
0.8ex; padding-left: 1ex;"> <div style=3D""><div></div><div>We need to =
consider how provider portability could =
be achieved or at-least not be precluded by core =
design =
choices.</div><div></div></div></blockquote><div><br>+1<br><br> </div=
></div><br></blockquote></div><br></div></body></html>=
--Apple-Mail-329--194318239--
More information about the general
mailing list