[OpenID] Calling OpenID 2.0 editors
There is a discussion on the openID general list that a number of people have asked me to comment on.
I am not going to reply to the list because I don't want to encourage them. I will however share some thoughts around openID identifiers.
openID 1.0/1.1
Way back over a year ago(forever in internet time) Brad Fitzpatrick had a simple notion, he wanted to enable people to claim there personal blog URL's when making a post on another blog.
So the openID was born as a concrete identifier of a resource you control ie you BLOG. In my case thread-safe.net is a concrete identifier for my BLOG, and through putting some rel tags in my HTML I can express an authentication endpoint that will verify my claim of being the person who put those tags in the HTML of the page.
Yes there is a authentication service that I can run or I can use one run by a third party.
This works because my page has one or more rel tags (Meta Data) in it that tell a Reliant Party (Web site) how to verify the identity of a person claiming ownership/control of that URL identifier.
In openID 1.0 there are two elements openid.server and optionally openid.delegate.
A website can use openID to prove to itself that I have control over my input identifier by redirecting me to the URL containd in openid.server with ether my input URL as my identifier (openid.identity) or with the contents openid.delegate as my identifier.
openid.identity is and always has been an opaque identifier passed to the OP. There is no grand significance to it. In my case it isn't a url its an iName =jbradley. The convention of using the input identifier as a local identifier for the OP is just that. The openID protocol assumes that you want to use a normalized version of your input identifier as your "OP-Local Identifier"
My input identifier "thread-safe.net" is normalized to "http://thread-safe.net/" and used by the RP as the RP sees fit.
Life was good with openID 1.0/1.1.
An openID was a URL that returned some HTML with metadata that allowed you to prove to another site that you controlled that URL in some way.
OpenID 2.0 The rise of complexity.
People saw that openID was good, but could be better if it did just one more thing. Some people wanted iNames (XRI) others wanted different authentication systems LID etc.
So people looked at the example set by XRI and its XRDS meta data and thought by golly if we discover meta data for an identifier we can use openID, LID, or SAML to allow someone to prove ownership of that identifier.
True but that doesn't change the fundamental nature of the URL. An iName =jbradley for example always resolves to a XRDS document, there will be forwarding and contact services as well as an authentication service contained in the XRDS.
An iName as an identifier is all about discovering meta data. A URL as an identifier is still about the resource identified by resolving the URL with a browser.
In XRI resolution there is something called a "Canonical ID" the resolution process enforces this. Think of it this way the CID is the address of the XRD document.(XRDS documents returned during are comprised of XRD documents the traversed, if you care)
While any given address must be unique there may be many routes to the address. An iName like =jbradley is just a route to a CID in fact =VE7JTB is a route to the same CID.
This allows for a user to have multiple identifiers that all use the same authentication service with the same "OP-Local Identifier". The CID from the XRDS in the XRI case.
In XRI it is "VERY STRONGLY RECOMMENDED" that an iNumber be used as the CID. iNumbers are not reassignable, so work to detect identifier recycling. If my iName =jbradley gets purchased by some one else after I give it up it MUST have a new and different iNumber for the XRD it resolves to.
If I decide to get a new iName =thread-safe and point it at my existing iNumber, I can use the new name to log into any site that is using my iNumber as a primary key.
I can also move my iNames and iNumbers between providers if an OP offers me a more compelling service. Something that is hard to impossible to do with URL's.
I happen to like iNames(XRI) because they are abstract identifiers with a resolution protocol that allows for service discovery. (There are other advanced features of XRI that I have not listed)
Not everyone (Brad Fitzpatrick and others) agree with me. The argument is that we can retrofit the features of abstract identifiers onto the concrete URL identifiers.
The first step to add functionality to the URL identifiers was Yadis this added a way to retrieve a XRDS document via a URL.
There is however a subtle difference, an XRDS retrieved via XRI is constructed by the resolution process and the CID is validated. A XRDS retrieved via a URL is just a special form of XML document and has no validated CID.
So to deal with the identifier reuse problem at places like Yahoo and AOL there needed to be something like the XRI CID.
The decision was taken to add something new to the 2.0 protocol "Claimed Identifier", this is intended to be the primary key for the Reliant Party to use. In the XRI case the thing to do was obvious, use the CID returned in the XRDS from the service discovery process.
In the URL case there is no CID in the XRDS and if there was one we couldn't verify it due to the resolution process. There was a proposal to use "Canonical EquivID" in the XRDS and verify it according to the XRI rules. It would have worked but some people didn't want to enforce the use of an XRDS to support identifier recycling.
The adopted solution has the RP relying on the OP to provide it with a URL to use as its primary key during the authentication process. This is the infamous and unfortunately named "Claimed Identifier". It is a mistake to think of it as anything other than an identifier that the OP is authoritative for to be used as the primary key by the RP.
The relationship between the "Input Identifier" and the "Claimed ID" is a one way one at best, they are not intended as synonyms.
When I do discovery on my URL "thread-safe.net" I may be redirected to "https://xrds.thread-safe.net/jbradley". The URL as a result of all redirects is my "Claimed ID" for sending to the OP. The OP may append a fragment ie "https://xrds.thread-safe.net/jbradley#12345" and return that as the "Claimed ID". This returned "Claimed ID" is what must be used as the primary key by the RP.
If we think back to openID 1.0/1.1 I have now proven that I control thread-safe.net but my OP wants the RP to use "https://xrds.thread-safe.net/jbradley#12345" as its primary key. The RP could and should use my original input identifier for display purposes.
The same goes for an XRI in that if my input identifier is =thread-safe I want the RP to display that and not my iNumber =!BF81.FD97.C81B.B4E5. I have only indicated that I or my OP wants =!BF81.FD97.C81B.B4E5 used as the primary key.
A reasonable question to ask is why use the product of the redirects as the root of the primary key at the RP and not the "Input Identifier"?
The answer has to do with people being cheep, wanting to keep the bar for adoption low, and how that conflicts with security.
A iName uses secure XRI resolution to retrieve the meta data, so things like the CID and OP URL can be trusted.
A URL may or may not point to a web site that has a SSL cert covering the URL being used. If the meta-data is retrieved over a non SSL connection without certificate verification you are asking to have your account hijacked via DNS poisoning.
So this leads to a two step normalization process for the "Input Identifier":
1. Prepend http:// if necessary, this defaults the identifier to non-SSL for maximum compatibility.
2. URL Identifiers MUST then be further normalized by both following redirects when retrieving their content, this allows an OP to force the retrieval of the meta-data to be over https.
If my OP is doing its job, my primary key is always a https:// URL so that if someone poisons the DNS cache they can spoof the http:// version of my identifier but not the https:// version. The RP must not consider the two URLs synonyms for the purposes of authentication. They may be synonyms for display, and I may have proved control over both, however only the URL that results from following all redirects is valid for securely logging me into an account.
I really don't care about the type of redirects HTTP follows. The primary key must be based on the URL that the meta-data is returned from for security reasons.
Changing this part of the openID 2.0 spec would break the security model for URLs.
I do however recommend that the original intent of the 1.0/1.1 spec be maintained in that the user has proven control of the concrete URL identifier, and that can be used to indicate the persons blog or info page for display or linking.
=jbradley
I am not going to reply to the list because I don't want to encourage them. I will however share some thoughts around openID identifiers.
openID 1.0/1.1
Way back over a year ago(forever in internet time) Brad Fitzpatrick had a simple notion, he wanted to enable people to claim there personal blog URL's when making a post on another blog.
So the openID was born as a concrete identifier of a resource you control ie you BLOG. In my case thread-safe.net is a concrete identifier for my BLOG, and through putting some rel tags in my HTML I can express an authentication endpoint that will verify my claim of being the person who put those tags in the HTML of the page.
Yes there is a authentication service that I can run or I can use one run by a third party.
This works because my page has one or more rel tags (Meta Data) in it that tell a Reliant Party (Web site) how to verify the identity of a person claiming ownership/control of that URL identifier.
In openID 1.0 there are two elements openid.server and optionally openid.delegate.
A website can use openID to prove to itself that I have control over my input identifier by redirecting me to the URL containd in openid.server with ether my input URL as my identifier (openid.identity) or with the contents openid.delegate as my identifier.
openid.identity is and always has been an opaque identifier passed to the OP. There is no grand significance to it. In my case it isn't a url its an iName =jbradley. The convention of using the input identifier as a local identifier for the OP is just that. The openID protocol assumes that you want to use a normalized version of your input identifier as your "OP-Local Identifier"
My input identifier "thread-safe.net" is normalized to "http://thread-safe.net/" and used by the RP as the RP sees fit.
Life was good with openID 1.0/1.1.
An openID was a URL that returned some HTML with metadata that allowed you to prove to another site that you controlled that URL in some way.
OpenID 2.0 The rise of complexity.
People saw that openID was good, but could be better if it did just one more thing. Some people wanted iNames (XRI) others wanted different authentication systems LID etc.
So people looked at the example set by XRI and its XRDS meta data and thought by golly if we discover meta data for an identifier we can use openID, LID, or SAML to allow someone to prove ownership of that identifier.
True but that doesn't change the fundamental nature of the URL. An iName =jbradley for example always resolves to a XRDS document, there will be forwarding and contact services as well as an authentication service contained in the XRDS.
An iName as an identifier is all about discovering meta data. A URL as an identifier is still about the resource identified by resolving the URL with a browser.
In XRI resolution there is something called a "Canonical ID" the resolution process enforces this. Think of it this way the CID is the address of the XRD document.(XRDS documents returned during are comprised of XRD documents the traversed, if you care)
While any given address must be unique there may be many routes to the address. An iName like =jbradley is just a route to a CID in fact =VE7JTB is a route to the same CID.
This allows for a user to have multiple identifiers that all use the same authentication service with the same "OP-Local Identifier". The CID from the XRDS in the XRI case.
In XRI it is "VERY STRONGLY RECOMMENDED" that an iNumber be used as the CID. iNumbers are not reassignable, so work to detect identifier recycling. If my iName =jbradley gets purchased by some one else after I give it up it MUST have a new and different iNumber for the XRD it resolves to.
If I decide to get a new iName =thread-safe and point it at my existing iNumber, I can use the new name to log into any site that is using my iNumber as a primary key.
I can also move my iNames and iNumbers between providers if an OP offers me a more compelling service. Something that is hard to impossible to do with URL's.
I happen to like iNames(XRI) because they are abstract identifiers with a resolution protocol that allows for service discovery. (There are other advanced features of XRI that I have not listed)
Not everyone (Brad Fitzpatrick and others) agree with me. The argument is that we can retrofit the features of abstract identifiers onto the concrete URL identifiers.
The first step to add functionality to the URL identifiers was Yadis this added a way to retrieve a XRDS document via a URL.
There is however a subtle difference, an XRDS retrieved via XRI is constructed by the resolution process and the CID is validated. A XRDS retrieved via a URL is just a special form of XML document and has no validated CID.
So to deal with the identifier reuse problem at places like Yahoo and AOL there needed to be something like the XRI CID.
The decision was taken to add something new to the 2.0 protocol "Claimed Identifier", this is intended to be the primary key for the Reliant Party to use. In the XRI case the thing to do was obvious, use the CID returned in the XRDS from the service discovery process.
In the URL case there is no CID in the XRDS and if there was one we couldn't verify it due to the resolution process. There was a proposal to use "Canonical EquivID" in the XRDS and verify it according to the XRI rules. It would have worked but some people didn't want to enforce the use of an XRDS to support identifier recycling.
The adopted solution has the RP relying on the OP to provide it with a URL to use as its primary key during the authentication process. This is the infamous and unfortunately named "Claimed Identifier". It is a mistake to think of it as anything other than an identifier that the OP is authoritative for to be used as the primary key by the RP.
The relationship between the "Input Identifier" and the "Claimed ID" is a one way one at best, they are not intended as synonyms.
When I do discovery on my URL "thread-safe.net" I may be redirected to "https://xrds.thread-safe.net/jbradley". The URL as a result of all redirects is my "Claimed ID" for sending to the OP. The OP may append a fragment ie "https://xrds.thread-safe.net/jbradley#12345" and return that as the "Claimed ID". This returned "Claimed ID" is what must be used as the primary key by the RP.
If we think back to openID 1.0/1.1 I have now proven that I control thread-safe.net but my OP wants the RP to use "https://xrds.thread-safe.net/jbradley#12345" as its primary key. The RP could and should use my original input identifier for display purposes.
The same goes for an XRI in that if my input identifier is =thread-safe I want the RP to display that and not my iNumber =!BF81.FD97.C81B.B4E5. I have only indicated that I or my OP wants =!BF81.FD97.C81B.B4E5 used as the primary key.
A reasonable question to ask is why use the product of the redirects as the root of the primary key at the RP and not the "Input Identifier"?
The answer has to do with people being cheep, wanting to keep the bar for adoption low, and how that conflicts with security.
A iName uses secure XRI resolution to retrieve the meta data, so things like the CID and OP URL can be trusted.
A URL may or may not point to a web site that has a SSL cert covering the URL being used. If the meta-data is retrieved over a non SSL connection without certificate verification you are asking to have your account hijacked via DNS poisoning.
So this leads to a two step normalization process for the "Input Identifier":
1. Prepend http:// if necessary, this defaults the identifier to non-SSL for maximum compatibility.
2. URL Identifiers MUST then be further normalized by both following redirects when retrieving their content, this allows an OP to force the retrieval of the meta-data to be over https.
If my OP is doing its job, my primary key is always a https:// URL so that if someone poisons the DNS cache they can spoof the http:// version of my identifier but not the https:// version. The RP must not consider the two URLs synonyms for the purposes of authentication. They may be synonyms for display, and I may have proved control over both, however only the URL that results from following all redirects is valid for securely logging me into an account.
I really don't care about the type of redirects HTTP follows. The primary key must be based on the URL that the meta-data is returned from for security reasons.
Changing this part of the openID 2.0 spec would break the security model for URLs.
I do however recommend that the original intent of the 1.0/1.1 spec be maintained in that the user has proven control of the concrete URL identifier, and that can be used to indicate the persons blog or info page for display or linking.
=jbradley