I think <host>:<port> is normally used rather than <host>:<id-string>
> general mailing list
general mailing list
So, during discovery, the user is essentially telling a RP "the
identifier you are about to receive, whether it be URL or E-mail
address or something else entirely, is an OpenID meant to log in
Past proposals (discussed in this list's archives, if you'd like to
look) have included new protocols and new TLD's; see this post in
Note, too, that TLD's are a non-issue when everyone moves to XRI's ;)
I am relatively ambivalent about the format of the user entered identifier.
Anything that gets the user to the correct OP works in principal.
The way we are headed with the nascar users entering identifiers is becoming less likely all the time.
The question is should we have a way for people to move there claimed ID from one provider to another.
Yes XRI supports that between OPs that support XRI.
Some will argue that XRI is or has died so that couldn't have been an important feature.
Perhaps that is true. People may like the increasingly sticky relationship with there OP.
Portability and the ability to self assert without an OP should be considered.
I am slightly less optimistic than Shade about XRI eventually taking over.
However that doesn't mean that we cant save some of the important design goals.
You said this before:
>I realized this would only let the cat among the pigeons. We could
>not allow an infinite no of schemes that come up in the future
>asking for OpenID support.
Now that you're making it an argument for defining an additional
theme, rather than an argument against ("allowing") OpenID to support
more schemes, I'm going to draw your attention to something
peripheral to your interests:
Specifically, bitnet addresses. Sending messages uphill, through the
snow, BOTH WAYS (and loving it, dammit).
You've argued for allowing E-mail addresses as OpenID's, but this
misses the point: WHY are E-mail addresses even in use here? Because
we've already headed down that slippery slope of adapting technology
to what seems to work better at the time, that's why.
Allowing the Identity technology of our future to accept new schemas
would be like allowing our communications technology to accept
E-mail: then we have our bitnet addresses AND our E-mail addresses,
it all just becomes more complicated in time! If future generations
come up with some new fad schema that they'd like to see adopted,
they can waste a few years struggling to make that happen before
either the fad passes (likely; new ideas for the latest and greatest
occur at least that often) or they give up realizing the futility of
Like we SHOULD have done with E-mail.
> In any case, I feel very very strongly that whatever OpenID v.next does about identifiers,
> it MUST address the issue of consistent handling and mapping of persistent, non-recycleable identifiers and
> non-persistent, reassignable human-friendly synonyms for those identifiers.
A “persistent, non-recycleable identifier” (eg an i-number) sounds like a useful concept, but I am always struck by how much more useful “=drummond” seems to be than whatever your i-number happens to be.
“=drummond” (eg an i-name) is supposed to be a “non-persistent, reassignable synonym” for your i-number. However, only your i-name appears in e-mails (like this thread), your blog domain name, web pages, and other online resources. If =drummond gets reassigned, these resources will not change so they become “wrong”. Having an i-number doesn’t seem to help here.
Perhaps these are aspects of reputation, and perhaps reputation is a special case that needs human-friendly i-names not persistent i-numbers.
I guess accounts at online service providers that use your i-number as the account id will “fail safely” if your i-name is reassigned. Even in this situation, though, it is not clear that non-recycleable identifiers are crucial. You can notify a service when your identifier changes, which just leaves the services you didn’t care enough about to notify that benefit from non-recycleable identifiers.
Finally, if someone has let their non-persistent, reassignable synonym lapse, are they likely to be able to (securely) reclaim their persistent, non-recycleable identifier in the future? How do you prove you own an i-number (some time after you have stopped paying for an i-name that used to resolve to it)? I am not that familiar with i-number practises, but it sounds like an awkward business problem. Does the process for re-claiming a non-recycleable identifier (eg an i-number) become a little-known backdoor that can undermine the security of systems?
Identity in the web has typically 3 representations: An internal
representation (fixed, unchangeable index), a friendly representation
(for user display purposes), and a globally unique identifier that the
user can provide for login purposes.
In OpenID there is the assumption that a single URL can play both
roles. I think there is sufficient evidence now that it can't.
1. If the user provides a URL to login, it needs to be friendly which
typically prevents it from being suitable as an internal
representation (it will be subject to recycling)
2. If the user provides an OP identifier (or an email address), and
the OP asserts a machine-generated value, it will be suitable for
internal representation but it will not be friendly.
3. If we allow acct: URIs to be claimed_ids in the future, then can
serve as a global identifier but they may not be either persistent or
Food for thought.
I agree that the one URL model needs to be revisited for v.Next.
Tying the persistent identifier to a URI may warrant reconsideration as well.
We have seen self signed certificates and other creative proposals.
I think this is a key part of v.Next.
I am as guilty as anyone for having involved technical discussions on the general list.
We should keep the General list clear for items of more general interest.
Also discussing the board election and other less technical things.
I am quite certain that not everyone is deeply interested in persistent identifiers.
general mailing list
__________ Information from ESET NOD32 Antivirus, version of virus signature database 4650 (20091130) __________
The message was checked by ESET NOD32 Antivirus.