[OpenID] Case for a unified scheme for OpenID "oid:"

[Santosh Rajan]

I have been thinking of OpenID's representing a universal set of identities for months now. Given that we all agree that identities must be URI's, there is one solution to the problem we can consider for OpenID v.next.

One of the problems with OpenID's is that it only supports a subset of all URI's, the "http" scheme. One of the solutions is to allow OpenID to support more URI schemes. But then 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.

Instead I have come to the conclusion that the best solution for OpenID is to register its own scheme. I will explain the suggested scheme with the following example.

1) oid:example.com/joe

2) oid:joe @ example.com

3) oid:example.com:1234567890

And here is the URI syntax for the 3 examples above

1) oid:<host>[/[[path]][#fragment]

2) oid: <username>@<host>

3) oid: <host>:<id-string>

(1) and (2) are self evident. (1) is the http URI. (2) supports the email like identifier. (3) requires more explanation. People are used to "id's", which may be an id issued by a govt or bank or any organization that has members. A lot of people already have access to this id which they are already using online. It may be a national identity no, or a company username or whatever. By supporting option (3) we allow those organizations who want to support OpenID to continue to allow their users to use the same id's they are used to. (Of course i have stretched (3) a bit to include govt and banks which is far fetched now considering the security implication, but lets assume we will be able to solve those problems).

Please feel free to comment on this idea which ever way you like.

--
http://hi.im/santosh

[Melvin Carvalho]

I think <host>:<port> is normally used rather than <host>:<id-string>

>
> --
> http://hi.im/santosh
>
>
>
> _______________________________________________
> general mailing list
> gen...@lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general
>
>
_______________________________________________
general mailing list
gen...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general

[Santosh Rajan]

Please remember "oid:" is a urn and this is consistent with usages like "tag:something:something".

--
http://hi.im/santosh

[John Bradley]

Hi Santosh,

The W3C has set the bar very high on registering new URI schemes.

http://www.w3.org/2001/tag/doc/URNsAndRegistries-50.xml

http://www.w3.org/2001/tag/issues#httpRange-14

Any new scheme that is approved will need to show significant benefit that cannot be accomplished with existing schemes and specifically http:

The XRI TC ran up against this with XRI and the proposed xri: scheme.

I suspect that it would be argued that the discovery process for openID should deal with multiple identifiers or that all identifiers can be named with http: URI.

The Web-Finger people are taking a run at the issue with a proposed acct: scheme.

I suspect that it will not become an official scheme though.

The XRI TC in consultation with the W3C agreed to rework the XRI identifier as a relative URI rather than creating a new scheme.

I think I understand what you are trying to do.  I won't comment on the details of your proposal because I think there are larger issues that need to be overcome for something like this to be accepted.

I recommend reading the above references,  and perhaps some of my dialog with the TAG on there mailing list, for background.   

Regards

John B.

[SitG Admin]

>Please remember "oid:" is a urn and this is consistent with usages
>like "tag:something:something".

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
with"?

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
particular:
http://lists.openid.net/pipermail/openid-general/2006-December/000826.html
Note, too, that TLD's are a non-issue when everyone moves to XRI's ;)

-Shade

[Santosh Rajan]

Hi John,

Thanks for the links. I am beginning to see how difficult it is going to be to get this passed W3C.

I was actually looking at the list of official IANA registered schemes here. (I hope this list is accurate).

http://en.wikipedia.org/wiki/URI_scheme

And i was thinking we had a better case than many of the registered scheme's here. Here is the case we could make.

1) OpenID would like to support more schemes than the http scheme alone. However this would be impractical because it would only increase in complexity with each scheme supported in future.

2) Instead OpenID would register its own scheme, with a syntax that would allow for a limited scheme specific possibilities, that represents a large majority of identities used around the world today.

3) There is no IANA registered scheme representing "identities". OpenID being the premier identity service protocol would like to be the first to register a scheme specific to identities.

It might be well worth to send a preliminary email to the concerned people on this regard and let us see what they have to say.

Thanks

Santosh

--
http://hi.im/santosh

[John Bradley]

I think if we are going to consider identifiers as we should in V Next, one of the core issues should be support of portable identifiers for claimed ID'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.

Regards
John B.

[John Bradley]

Hi Santosh,

Most of those schemes were registered before the W3C started actively opposing them.

Some like afp: and others remain unofficial despite significant merit.

This may be a silly question but if someone is entering this why do you want them to enter a scheme?

Wouldn't ve7...@vetjtb.com be sufficient.

If they don't need to enter it and it isn't used for resolution that leaves using it as a link as a possible use.

If it is a new scheme then you need to show the value in modifying browsers to recognize it.

The argument will be (I have had it used on me) that http: URI are the only scheme recognized universally by browsers.   Map whatever you want into that scheme so that browsers don't need to be modified.

My caution is not a refection on the merit of the idea.  It is simply that this is a large issue and you need to be well prepared.

I am off to the Beach for the rest of the day.

Regards

John B.

[Santosh Rajan]

Hi John,

I don't expect the user to actually enter the scheme. The user will only enter whatever was given to him by his provider. So if the provider gave him any of the following, to be used as his OpenID he would only enter that. Giving my own example.

1) santoshrajan.myopenid.com

2) santrajan @ gmail.com

3) myexamplebank.in:1234567890

The protocol would clearly specify how to differentiate between these three scheme specific entries and how to resolve them. We already know how to resolve these three URI's and hence I am not discussing them further.

I don't see any need for modifying the browser at the moment to recognize this. The protocol will take care of that. There also is value for browsers to modify to recognize this, because this allows the users and relying parties to use the most commonly used identities, which will only benefit all the stakeholders involved.

Regards

Santosh

--
http://hi.im/santosh

[SitG Admin]

>1) OpenID would like to support more schemes than the http scheme
>alone. However this would be impractical because it would only
>increase in complexity with each scheme supported in future.

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:

Communication schemas.

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
it all.

Like we SHOULD have done with E-mail.

-Shade

[Drummond Reed]

John,

Some will *always* argue that XRI "is or has died". But as you know, XRI is alive and well, and with XRD 1.0 finally out, the XRI TC is making steady progress on having XRI 3.0 out by the end of the year (I personallly have been the biggest bottleneck due to other obligations, but I"m committing to getting it out in that timeframe). For those following John's thread, XRI 3.0 is the adjustment to XRI architecture that places XRI completely within URI architecture to deal with W3C TAG's objection to XRI 2.0.

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. Until it solves that issue, OpenID will carry a huge security hole which will rule it out for many of the uses for which it otherwise would appear to be a good solution.

(For reference, Information Card/IMI architecture filled that security hole with the PPID mechanism built into Information Cards. However Information Cards rely on a different discovery mechanism. The best of both worlds would be to have the discoverability of OpenID with the automatic persistent identifier protection of Information Cards.)

=Drummond

[Manger, James H]

=Drummond,

 

> 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?

 

 

 

James Manger

[Andrew Arnott]

James,

You make a good point about using "=drummond" everyone eventually leading to out-of-date identifiers.  But I think the biggest value to non-recycleable persistent identifiers is the security that losing control of that identifier cannot lead to someone else eventually spoofing your identity at an RP.  That's huge.  

The second most important value (IMO) of this is that after "=drummond" is recycled, Drummond can still either log into the RP with his i-number, or acquire a new recyclable identifier and attach it to his i-number and log in with that.  I don't know how re-attaching a new i-name to an existing i-number works, or even if it does today.  But it seems like a logical thing to be able to do.

The convenient, but least important IMO, is what you bring up, James, which is that others who recognize the i-name are still able to find the original owner, even if that owner doesn't own that alias any more.  I don't know how to make this work, but given the two earlier points, I think achieving the first two without the third would still be hugely worthwhile.

--
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

[Drummond Reed]

+1 to all the points Andrew makes for all the security reasons about why every human-friendly recycleable OpenID identifier should be paired with a persistent non-recycleable identifier, and why RPs should use ONLY the latter as the persistent identifier for the user's account at the RP.

As Andrew says, it's not about users being able to switch recyclable identifiers - they can do that today. It's about the huge security hole that opens up when they LOSE CONTROL of a recyclable identifier - their domain name lapses and is reassigned, or their URL is reassigned. By the definition of OpenID, this means the new owner/controlled of that identifier can now fully and completely impersonate the previous owner/controller everywhere they had an OpenID account -- without detection or recourse.

Don't misunderstand - I'm not saying OpenID has to adopt XRI i-names/i-numbers as the only solution to this problem (though XRI synonym architecture was developed for this very purpose). Regular URLs and hash-URLs are another option (weaker but still valid). And still other solutions could be developed. What I am saying is that unless OpenID v.next builds the capacity for automatic synonym mapping - from one or more human-friendly recyclable identifiers to a persistent non-recyclable identifier, and RPs adopt the practice of storing the former as the friendly name and the latter as the persistent external account identifier -- will the problem truly be solved.

(Note: this solution is othogonal to directed identity - the persistent non-recyclable identifer can be pairwise-unique or not depending on the user's privacy preferences - but in the former case it is of course important not to turn around and share a non-pairwise unique human-friendly recylable identifier as a synonym.)

Net net: it's not an easy solution. But it must be tackled if OpenID is going to grow to the next level.

=Drummond

[Nat Sakimura]

+1 to both Drummond's and Andrew's point. 

I have done a blog post a while ago: 

http://www.sakimura.org/en/modules/wordpress/identity-loss-with-openid-20/

If nothing else, what OpenID v.next should do is to deal with this problem. 

Simply put, the persistent identifier must be returned by the Discovery Service, not Authentication Service. 

Note: This as an impact to the UX of identifer_select, and a way to cope with it is desired. 

--
Nat Sakimura (=nat)
http://www.sakimura.org/en/

[Drummond Reed]

Nat actually makes a very important point here with regard to the persistent non-recyclable identifier issue: in order for it to fully protect the OpenID user, this identifier must be returned to the RP via the discovery process, not the authentication process. I encourage folks to read Nat's blog post. Yet another reason why I personally believe Discovery should be its own independent modular specification for OpenID v.next.

=Drummond

[Breno de Medeiros]

One of the reasons this issue keeps cropping again is that OpenID is
not faithful to the 'Tripartite Identity' concept:
http://habitatchronicles.com/2008/10/the-tripartite-identity-pattern/

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
friendly.

Food for thought.

--
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)

[John Bradley]

Good points.

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.

John B.

[John Bradley]

I would like to recommend moving the technical discussions to the Specs List.

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.

Regards
John B.

[Chris Messina]

I would support that move. 

To that end, let's make sure to remind one another to follow that convention and discuss all technical matters on the specs@ list from this point forward. Without diligence, I think we'll end up just reverting back to misusing general@.

Chris

_______________________________________________
general mailing list
gen...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general

--
Chris Messina
Open Web Advocate

Personal: http://factoryjoe.com
Follow me on Twitter: http://twitter.com/chrismessina

Citizen Agency: http://citizenagency.com
Diso Project: http://diso-project.org
OpenID Foundation: http://openid.net

This email is:   [ ] shareable    [X] ask first   [ ] private

[Brian Kissel]

+1

Cheers,

Brian
___________

Brian Kissel
CEO, JanRain - WebID and Social Publishing for User Engagement
Email: bki...@janrain.com     Cell: 503.866.4424     Fax: 503.296.5502

Regards
John B.

__________ Information from ESET NOD32 Antivirus, version of virus signature database 4650 (20091130) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

[Drummond Reed]

Agreed, to the extent I'm guilty I apologize, I was just responding to a thread someone else started on the general list.

=Drummond

[John Bradley]

We just made the decision to move as a result of the recent issues.

The general list is getting to cluttered.

You can feel guilty if you like:)

John B.