![[OpenID enabled]](http://lid.netmesh.org/images/openid-relying-party-anonymous.gif)
![[XRI enabled]](http://lid.netmesh.org/images/inames.gif)
![[LID enabled]](http://lid.netmesh.org/images/lid-relying-party-anonymous.gif)
LID-FAQ-Architecture
From LID Wiki
Questions about LID architecture and technology.
Is LID a centralized system?
No. Unlike most other systems with related functionality, LID allows individuals and companies to be in complete control over their digital identities without having to trust an external service provider, simply by self-hosting their identities.
LID gives you a choice that many others do not: host your own digital identity, or use a service provider whom you trust.
What standards does LID support?
LID is built on:
- vCards (actually the XML version of vCards) for information about individuals;
- FOAF (friend-of-a-friend) for information about your social network;
- XPath to select which information to query, and which information is published to whom.
- Gnu Privacy Guard (GPG) for digital signatures.
- HTTP and HTTPS for (secure) transport
- XML for information exchange
- OpenID for shared cryptographic secrets
LID does not require browser extensions; industry-standard browsers are full-fledged clients.
How does it work?
For a description of how LID works, refer to the LID homepage at http://lid.netmesh.org.
What happens if a user wants to change their LID URL?
(asked by David Weinberger, updated answer)
We recommend that you create your LID URL at your very own domain name (such as from the .name top-level domain). If you do so, you can carry your LID URL with you, even if you change ISPs or hosting providers.
In the future, we additionally may put a "secured .forward" protocol into LID that enables a transition period for forwarded identity requests, just like the postal service forwards mail.
Does a LID user have to have exclusive control over a web server, or a DNS domain?
No. For security reasons, it is advantageous to make sure other users of a server cannot access one's LID installation, which may be accomplished easiest on those servers over which one has exclusive control.
However, there is no reason whatsoever why a service provider, for example, couldn't host thousands of LID URLs on the same server, using the same or different domain names. For example, the same server could host identities such as http://example.com/~tim, http://example.com/some/pseudonym and http://tim.name/
Why don't all LID URLs hosted by the same service provider have the same format? (i.e., http://yourdomain.com/users/jim/cgibin/lid.cgi)
(suggested by Dave Kearns, updated answer)
Our goal with LID is to have only one URL for the person (or the persona). This means that using an existing URL of the user (e.g. their blog URL) as their LID URL is a fundamentally simpler setup than coming up with an additional URL construction scheme.
Further, reusing the same URL provides the abstraction that we want to provide: there is one URL for a person, and depending on which arguments you provide (some, none, e.g. xpath=...) it returns different information.
Why don't you use e-mail addresses instead of LID HTTP URLs
There would be certain advantages if we could use e-mail addresses (say, liddemouser@lid.netmesh.org instead of http://lid.netmesh.org/liddemouser/, such as the familiarity of users with e-mail addresses as a way of identifying a person. However, there would also be substantial difficulties:
- with spam e-mail being more than half of all e-mail and often aggressive filtering by individuals or their organizations, e-mail messages have become unreliable, and are thus not a good foundation on top of which to build a new kind of system
- e-mail addresses may apply to people, but there are no e-mail identifiers for groups, organizations, or non-human entities which also should have digital identities
- key distribution is a substantial, and essentially unsolved problem if only SMTP is available as a transport (e.g. see PGP's key distribution problems)
- most importantly: it would be infeasible to define command and information vocabularies like we do in LID (e.g. to support queries, SSO, secure messaging etc.) on top of SMTP.
We may define some sort of mapping (e.g. from liddemouser@lid.netmesh.org to http://liddemouser.lid.netmesh.org/ or http://lid.netmesh.org/liddemouser/ at some point if it turns out that user acceptance is indeed inhibited by disallowing e-mail addresses as identifiers.
With phishing attacks on the rise, are you comfortable using URLs as digital identities?
(asked by Eric Sigler)
Yes we are. No other naming scheme is going to be any safer than URLs, nor better governed than the domain name system. And billions of dollars in e-commerce depend on consumer's ability to trust that if they type an URL into their browser, they will indeed interact with that vendor and not somebody else. Because of that, they will likely be safer than virtually anything else we or anybody else can come up with.
It appears that your FOAF integration depends on a particular RDF serialization and namespace syntax. Is that correct?
Yes, it is. There is no particular advantage we can think of in supporting multiple serialization methods. And because it is difficult to use XML namespaces properly in XPath expressions that may come in over the network, we decided to adopt a fairly tight convention to enable tight XPath expressions.
Also note the more recent addition to LID of RSS-FOAF.
Can I keep my existing home page at the the same URL that I want to use as my LID URL?
This depends on the particular LID implementation that you are using, and its features.
Generally, we would consider this to be A Good Idea for LID implementations.
Can I move my LID URL from one service provider to another?
Yes, as long as you can move your domain name with you.
Can purl.org be used with LID?
(asked by Shelley Powers.)
No. The HTTP redirect inserted by a scheme such as purl.org's likely interfers with the redirects needed by the LID protocol itself.
Instead, we recommend that you use your own DNS name, such as in the .name TLD (top-level domain).
