concerns about each user having a unique "URL"

[Peter Watkins]

For some time I've been pondering federated identity systems for 
my employer. I work for a large organzation of, let's say, plumbers.
While much of OpenID seems to meet our needs well (real-time assertions,
signed assertions, "zero footprint" on the client, does not require
or assume certain authentication methods), I am concerned about the 
notion of an individual claiming a unique URI. The main concerns are:
 1) data entry: what if the user mis-remembers, mis-types, or just 
    doesn't like the idea that his identifier is "rsmith38.id.plumbers.co"?
 2) privacy: if plumber Rob Smith tells every OpenID relying party
    that he's "rsmith38.id.plumbers.co", all the relying parties know
    they're talking about the same exact user. It's the whole Passport
    GUID mess all over again. Some sites only need to know that Rob
    is a licensed plumber (attr http://plumbers.co/openid/schema/licensed),
    while others might only care about his name & email address
 3) name changes: many people like handles based on their names...
    right up til a life-changing event changes "hmills" to "hmccartney",
    or back to "hmills" again.
 4) password-less authentication: we allow individuals to authenticate to
    our systems by answering the normal "enrollment" questions and skipping
    the username setup phase. In the past, we've also used SAML-based
    federated identity products to authenticate users such that there was
    no friendly "username" for us to grab hold of, only something like
    a globally unique Plumber Identification Number.

Additionally, I don't think we're ready to offer each plumber his own 
web site. While the OpenID presentations I've read talk about users
"understanding" URLs, I think those presentations understimate the likelihood
that OpenID users will expect that "having a unique URL" means having
a human-usable web site.

Also, while the obvious user identifier would be something like 
  username + "id." + domain name ("plumbers.co")
For years we have allowed characters in the username field that are
not compatible with RFC 952, e.g. "Patrick O'Rourke". With tens of 
thousands of accounts, I don't want to think about dealing with 
username -> uri translations -- *especially* since the users would 
need to know their new OpenID-compatible URLs.

To me it would seem an improvement for OpenID to
 - not require an individual's unique URL/iName, but also accept a
   URL that only uniquely identifies the Identity Provider (id.plumbers.co)
 - specify that the response should include a identifier that is
   unique to the user/subject for the request's openid.realm 
   This would allow a more Liberty Alliance-like behavior wherein the
   IdP could choose to use the same identifier 
   (like http://openid.net/schema/person/guid) for all RP's, or could 
   choose to create a different identifier for each realm for each unique user
 - define a core property for the user's URL (?)

I fear that I don't understand the OpenID 2.0 specs terribly well. I can see 
hints that my desired behavior might be permissible/feasible -- for instance,
the response contains openid.identity, and the specs do not dictate that
openid.identity match the claimed identifier (URL the user entered), and
the fact that there is a "guid" property defined suggests that the 
openid.identity that an IdP responds with may be different from the 
guid and the claimed identifier. So perhaps our users could enter 
"id.plumbers.com" in the OpenID field to use our IdP endpoint, which 
would then return a unique (at least for that user in that RP realm)
identifier after authenticating the user. But that really sounds like 
cheating, given all the high-level discussion of users' proving "ownership"
of a URL. I expect that many programmers building OpenID RP software 
would assume that the "claimed identity" (URL used by the RP to authenticate
the user) was unique for each user.

I would very much appreciate your thoughts on all this.

Thanks,

Peter