- From: Mike Macgirvin <mike@macgirvin.com>
- Date: Sat, 08 Mar 2014 09:19:00 +1100
- To: public-fedsocweb@w3.org
I do know what a URI is and what a URL is. It's just that whenever we're talking about identity on the web - the first thing people do is mush them together - like they did for the various flavours of the "federated social web". Your identity could be one of [acct:]foo@example.com or https://example.com/something/foo. Meaning that the identity foo is only foo when you're talking about example.com. In the zot world in which I now spend my time an identity is a combination of a complex string and its signature. In order to verify the assertion it does need to be addressable somehow, so it is *also* paired with a _current_ dns location (e.g. URL - which is also signed by the same key as the identity signature). These four components together make up a portable and unique addressable identity - across the internet. The complex identity string *and* its signature combined together comprise a unique identity which is separated from its address. Now you can contact the location provided in the location URL and query a well-known URL there (e.g. webfinger) to find the key you need to verify both signatures and find a profile vcard, etc. - and you've got some proof of the assertion. So you do and yes, this is George - who is currently at example.com. He can move to a different DNS location and still be George. The identity doesn't change. The new location just needs to be signed by his personal key. So certainly the identity assertion here (the complex string and its signature) could be a URI. I'd need a new URI scheme for a zot guid/uuid+signature, but that's not a big deal. But note that it is not a DNS based URL. You do need the URL (+ signature) location pair to verify the assertion, so this might have to be yet another new URI scheme for this information structure if this were also to be represented by a URI. But I don't really care whether it's a URI or not. That's just for folks that somehow need things to be URIs. In the current project, these identities can be somewhat ad hoc. Whether or not this could be used in systems that require government-ids is something I haven't looked at much because in my world we don't necessarily trust governments. Since it's your personal identity and you have the signing key, you would have to sign the government's URL so that they could verify your assertion. Governments typically don't work this way - they like to be in control. But there's no technical reason why this couldn't be possible. They could for instance hand you the signing key they generated, after they used it to sign your identity and their own location. Or they could require that they sign all your identity assertions and keep the key to themselves. I'm *not* trying to standardise this process and make it available as a w3c draft standard. I'm just making something that works for my needs. Same as I always have, so don't look at this as competition that has to be squashed. Back in the federated social web discussions, I was told that OStatus was the way the game was going to be played and if I wanted something private and spam-free I was a troublemaker and asked to leave. Sorry, but I'm still a troublemaker. If the standards process means implementing something that's fundamentally flawed in my eyes, and contrary to the needs of my customers, I won't do it. From what I've seen of webIdentity, it doesn't work for my customers' needs and I therefore can't and won't use it. This isn't to say it may not find value in a centralised top-down fully controlled world. I'm just saying that isn't my world. You may now resume your discussions and forget that this post exists. I don't see that my input is going to change anything. The identity steam-roller is going to roll on regardless. But I still wanted to put my $0.02 on the plate. Dissenting input is hopefully still allowed to play a part in the standards process if for no other reason than to define the boundaries where the proposed standard solutions work and the realms where they start to break down.
Received on Friday, 7 March 2014 22:19:30 UTC