General things to consider

[Zefiro]

Hi, list

as the discussion seems to shift from single-signon / single-user'name' to full-blown digital identity, I'm retracting a bit and
let more visionary people formulate their ideas. However, I want to mention a few things which I think are important and I ask
you to a include them in your thoughts.

Martin Atkins wrote:
> As I see it, in the early days most users will be interested geeks or enthusiasts,
For consumers - yes. For identityservers - yes. For users - definitely no. Not only.
It is one of my main reasons to use OpenID instead of any other identity (namely, it was self-created users with own passwords,
like everywhere else) because I have a small site which few users, but sometimes want both to show stuff to a broader base of
users and still keep track of who accessed it or who is allowed to. I'd need this e.g. for pictures of private meetings, where
most attendees are not users of my site nor want to create user accounts. I can then easily say - look, you already have an
account! This is true now, since most users are on livejournal.com

So having a very large userbase of people who are interested in logging in, but neither in technical details nor bleeding edge
is a very good thing.


Further, adding many digital identity data is a nice thing to do. But it opens up a can of worms. One of it is data mining.
Users on the web are spied upon at every possibility - ads, popups, tracking cookies, you-name-them. Whatever we build here, it
should NOT help these data mining - nor should users distrust our system because they suspect we do. OpenID handles this very
well - the user is asked whether he wants to allow the other site to know he in fact is who he claims to be.

I just want to mention that with any added data this concept has to be broadened, not forgotten. If I log in to a site, I do
definitely want to be able to allow it to know my identity and my avatarpic and my display name and perhaps my work email
address. But I refuse to show them my CV, my private email address, my private picture gallery, etc - which I also have in my
identity and might want to show to other sites.

I think this is a very important point if we speak about putting much personal information online and behind a single identity URI.

Now, if we implement possibilites for this in the spec and the mainstream identity servers, we are forcing consumers to be aware
of this. To really make things forward-compatible, such points should be noted explicitly in the documents (and not stated as
'out of scope'). I.e. a consumers SHOULD allow for not getting all information he asks for - be it because the users doesn't has
this service or doesn't want the consumer to know it. It should allow for getting access to it at a later stage (when the user
decides that he now allows this - e.g. giving credit card details after having chosen to buy something, after he wanted to
merely look around in a webshop a bit), and it should be prepared if the identity changes. This should be possible because many
people might want to desire different identities, like they have different email addresses today. Yes, this is out of scope for
a technical spec at the moment, but I think it's important to at least put it in a chapter which consumer-programmers will read.


Lastly, I want to remind you that both consumers and servers can make use of the whole potential the internet has to offer.
Users, whishing to have a personalized identity-URL, often can not. Their identity should be 'theirs', it should be their
homepage, their domain, etc - I strongly encourage the use of openid.delegate here. But many webhosting providers don't allow
active scripting like PHP or mod_rewrite, which is needed for many of the new proposals. Even putting the <link> in the headers
throws some users off, as they use free hosting and can't even change the whole document, only the text. I agree that this is
acceptable and most persons are able to at least change the static .html or add an additional .xml metadate file. But requiring
to have more intelligence on the identity-URL server side means limiting the user base.

So in summary:
- an initial broad user base is a good thing
- we want to have many users who can use our scheme without having any clue of any technical stuff - just say 'you already have
the everything you need'
- we want to address privacy concerns (embed it in the spec and encourage/force consumers to use it)
- we don't want to limit users in their choice of identity URLs based on their technical possibilites (mod_rewrite, PHP, etc),
but only if they 'own' the URL, i.e. are allowed to make changes to it


So please address these points in your further discussion.


And it would be nice if, apart from all visionary thinking, it would still be possible to do 'just easy single-signon', without
any more fany extras :)


*purrrrrrrrr*