Openid 联姻.name

.name的管理机构:GNR,刚推出一个新的服务,FreeYourID.com

用户可以注册 lastname.firstname.name 的域名,前90天免费,后面一年10.95美元。注册者同时拥有 [email protected],还有一个 lastname.firstname.name的OpenID。

.name的域名本身就是和个人的名字相联系,FreeYourID的服务,让用户的个人名字,email (这个也是ID哦)以及 OpenID 结合到一起来。

可以用email来收发信件,当然也能用它来注册了。OpenID呢,自然不用说,而且通过.name的域名,天然的指向了一个人,结合个人档案的话,web个人身份也就更完整起来。

该服务提供email、url的转向。

试着注册了 xiaoyun.zheng.name openid服务由myopenid.com提供。

看来它只提供 firstname.name的服务,而不直接注册 .name,否则其他人都没法用 zheng 姓了。这样看来,10.95好象贵了点。

继续阅读Openid 联姻.name

颇为热闹的OpenID

这一两个礼拜,在阅读的Blog中,OpenID出现的频率比平常高了许多,不知道是不是联盟又悄悄启动了宣传“攻势”?

Kveton 预言2007的OpenID ,说了这样几条:1亿的拥有者,7500个支持OpenID的服务商,将有大头也来玩等。

OpenID有很多用户没错,但如何激发起这个市场确是个问题,不知道要等支持openid的服务商达到多少个才能引爆,150个?或者这涉及到他们的影响?7500个,我觉得Kveton太过乐观,我觉得1000-2000个就很不错了。至于大头,认真地想插一脚,或者在07年下半年会有。呵呵,开个玩笑,百度有可能么?

另外,在MyopenID那里,又罗列了几个新的支持OpenID的网站,有些很有意思 :

- doxory.com ,一个问答社区,让用户可以和朋友之间问答,他们定位在为生活提供方向。

- stikis , 一个Web Notes(便签服务)

- Ticket Everything! ,管理Bug,不止于此,也可以用来管理日常工作中的许多事情。

- Teamtastic ,一个服务于小团队和俱乐部(Club) 的社会性网络服务(SNS)。

我是用我的inames:=zheng 登录Stikis的,看来openID与i-names之间的互通比我想象的来得要快。

国内方面,前几天,lokichin发布了mysecond.name 这个openid服务,上面列有不少的服务。

继续阅读颇为热闹的OpenID

有趣的Pavatar,个人集中控制的网络化身图片

作为互联网基础服务的email,因为每个人都拥有至少一个,且每个人都能唯一的证明那是他/她自己的email,所以称为web应用验证个人身份的一个重要途径。

在Blog带动的web2.0兴起后,有越来越多的人拥有他们自己的Url,而且这些Url所对应的网页/网站都能被拥有者证明其所属,水到渠成的,人们会想到把URL作为验证个人身份的另一个有效途径。OpenID就是在这个背景下被广为关注。

除了OpenID之外,从Url作为个人身份识别角度的一些有趣想法还有以前提到的MicroID,它是给其他Web应用证明自己归属的一种简单方式。

Pavatar(Personal Avatar) 类似于MicroID,使用它,人们就能在其他服务上,留下Url的同时,也显示出自己设定的个人画像,听上去很像许多网站用的在浏览器地址栏显示的icon(favicon.ico)。

不过后者是独立于页面,单独存放。而Pavatar,则是在页面的代码中,加入
。需要个人头像的Web应用,按照协议的方式读取即可。

目前,这个协议中所建议的图片大小是80 x 80 px,呵呵,好像有些大。

类似的想法,BRUCE 从openID的角度也提到过,那时候是在讨论如何通过api调用用户在wealink上的头像使用问题,bruce就想到把icon结合到openID的使用中。

有意思的是,也有许多人自然想到了Pavatar与openID的共同基础,建议它们结合起来。

继续阅读有趣的Pavatar,个人集中控制的网络化身图片

URL 不用了,ID属于谁

OpenID 这东西很好,不过,要大规模的被接受并被应用,必须解决这样一个问题:作为openid的url的每次所属者的全球唯一性。

具体来说,是这样:我用www.klogs.org作为openid的url,现在它属于我;但是,有一天,我放弃了这个域名,它被另外一个人注册了。按照openid的使用方式,这个人能够证明www.klogs.org属于它,自然就能够用它来登录我以前登录使用的各种服务。

怎么能够解决这样的问题呢?

1、如果是openid服务商来说,它可以控制每个被使用的url,一旦被申请,就不再被第二个人使用。不过要每个服务商都这么做,似乎比较困难。特别是这种方法对独立的顶级域名的Url无效。

2、在这方面,i-names的方式倒是值得参考。每个inames,除了人可读的名字之外,比如=zheng, 它的背后对应的还有一个全球唯一的数字ID,这个ID只被使用一次。对于inames的验证,实质上是通过数字ID完成。这样,即便明年我不对=zheng续费,有另外的人注册了这个名字,因为它对应的数字ID和我所拥有的已经不同,所以无法通过它登录我曾经使用的服务。

openid的url是否也可能采用这种机制呢?在每次生成一个有效的openid的时候,提供一个全球唯一的id来作为背后的验证,比如表面上是www.klogs.org,实际上背后用的是一个数字ID来辅助?

不知道在openid2.0的规范中,是否有解决此问题?回头仔细去查查…

继续阅读URL 不用了,ID属于谁

OpenID 工作方式,以Klogs.org为例

OpenID 是一个用户中心的,以URL为身份标识的身份验证解决方案。在这个方案中,每个人可以用他/她所拥有的支持OpenID的URL,作为出入各种互联网应用/服务的钥匙。(所谓你的身份你控制)

下面,就以我自己网站的url为例,来讲讲这个OpenID的工作原理

OpenID有三种实现方式,

一种呢,使用OpenID服务商提供的URL,比如zheng.pip.verisignlabs.com;

第二种,如果自己的虚拟主机能够支持OpenID的server程序的话,不妨自己搭建;

第三种,注册的是OpenID服务商的服务,但是又想用自己Blog或者网站的url,比如我想用WWW.KLOGS.ORG,而不是verisignlabs.com的url。这种方式能够通过"委托"的方式实现。

我选择的是第三种。

首先,我已经注册了http://pip.verisignlabs.com/ 提供的OpenID服务,在那里申请的URL为:zheng.pip.verisignlabs.com

接下来,把下面两行代码插入到我的www.klogs.org首页的...中。

<link rel="openid.server" href="http://pip.verisignlabs.com/server" />

<link rel="openid.delegate" href="http://zheng.pip.verisignlabs.com" />

第一行是用来指明所采用的OpenID服务方所在的位置;第二行是说www.klogs.org实际上只是zheng.pip.verisignlabs.com的代理,真正的OpenID Url是后面这个。

这样做的好处, 有点类似于Feedsky的Feed托管,不过我的Blog,我的RSS的地址如何变幻,在Feedsky上的RSS输出并没有变化。

好了,现在我要用www.klogs.org来申请并使用其他服务了,这里选择的是OpenID的营地:OpenidEnabled.com

我在Openidenabled.com输入www.klogs.org。

提交后,作为验证需求方的Openidenabled开始工作。先是抓取我提供的URL对应页面的代码,找寻其中的OpenID申明。

在我的www.klogs.org中,Openidenabled将会发现我的OpenID的验证服务方实际上是来自pip.verisignlabs.com/server,真实地OpenID URL是 zheng.pip.verisighlabs.com,www.klogs.org只是一个被委托者。自然的,Openidenabled就要去处理zheng.pip.verisighlabs.com这个地址。

接下来,Openidenabled.com会用我的URL所声称的验证服务url生成一个公有密钥(SHARED SECRET),同时构建一个用来验证我的id的url(如下),并让浏览器转向到那里。

http://pip.verisignlabs.com/server?openid.mode=checkid_setup&openid.identity=
http%3A%2F%2Fzheng.pip.verisignlabs.com%2F&openid.trust_root=http%3A%
2F%2Fwww.openidenabled.com%2F&openid.assoc_handle=%7BHMAC-SHA1%7D
%7B44be6b1d%7D%7B3sqAgQ%3D%3D%7D&openid.return_to=http%3A%2F
%2Fwww.openidenabled.com%2Fopenid_login%3Ftoken%3DTbQQC7S86fefBIy
PEJigbtzJaYMxMTUzNDA5MzU0AHVmQk9OSGRIAGh0dHA6Ly93d3cua2xvZ3Mub
3JnLwBodHRwOi8vemhlbmcucGlwLnZlcmlzaWdubGFicy5jb20vAGh0dHA6Ly9waX
AudmVyaXNpZ25sYWJzLmNvbS9zZXJ2ZXI%253D%26came_from%3D

因为我还未登录,所以pip.verisignlabs.com提示我登录,在我成功登录之后,也就验证了我拥有我所声称的Openid url:zheng.pip.verisignlabs.com

验证的服务方此时构建一个返回到验证需求方的URL,将浏览器跳转到该页面,我就被授权能使用openidenabled.com的服务了。

表面上看,服务方跳转回来后的过程很简单,其实在后面还有更多的动作:它将检查是否有为这个验证服务方生成的公有密钥缓存。

存在缓存的话,验证服务方转过来的URL所带的Signed参数被该缓存的公有密钥验证。

不存在的话,验证需求方与验证服务方的对话还要再进行一次,服务方会返回需求方过来的签名有效。

(这里有一张Openid work flow图,表达得更清晰:)

----------

对用户来说,整个过程就是输入url,到服务端确认 ,就两个动作,一点不复杂。

继续阅读OpenID 工作方式,以Klogs.org为例

MicroID 可以怎么用?

microID 只能验证一个网站、页面,也就是某个URL是用户所申称的,并不能验证该页面上的内容是用户申称的。

尽管受限于此,不过基于URL的拥有上,microID还是可以有不少有趣用途的。

我们先对microID做点小的改动,前面提到,microID的生成是利用验证过了的email和所在的URL,其实还可以更多,可以是手机号码,也可以是某一句只有你自己知道的话或者口令,我这称它为“私房话”。

好,现在假设klogs.org要和beeki.com合作,由后者为klogs.org的用户提供服务,问题是,beeki.com怎么证明过来的是Klogs.org的用户呢?

帐号Api?Klogs.org暂时还没有能力做到(openID是另一个解决方式),把Klogs.org上的用户信息倒过去?更不可能。

利用microID,只要验证我输入的email是我的,就能够通过microID验证我是klogs.org用户。至于验证email的私有性,发一封确认信过去就行了。

当然,这里涉及email的输入,如果担心有什么问题的话,那么,可以改用“私房话”而不是email的方式来获得microID。

我输入我的“私房话”和声称的URL, 如果得到的microID和Klogs.org上我的页面的microID一致,那就可以证明我是Klogs.org的用户了。

………

继续理解中:)

继续阅读MicroID 可以怎么用?

学习PeopleAggregator(一)

号称“Open Social Networking”的PeopleAggregator昨儿正式开放。它是由”broadbandmechanics“开发。关于Boradbandmechanics ,可以看看这里

他们开发PeopleAggregator的目的是希望实现SocialNetworking的开放(Open),具体来说,就是“任何人可以自由的将他们的联系人、群组以及社会资本进行迁移,能够在任何网络中和任何人建立关系,发送消息,创建或者加入群组,发布内容等”。这将是一个“社会性的网络/Social Web”,用户掌控着自己的关系、数据等,这里的掌控不仅仅是拥有,还包括可以移动。

作为这个Open Social Networking的基础,也就是ID部分,PeopleAggregator承诺支持任何开放的ID系统,他们把他叫做“Identity Hub”。就现在来说,人们可以用Flickr帐号、OpenID、SxIP等登录。

不过这里面还有很多事情需要做,包括他们提到的“normalizing the namespace, and creating a federated identity space” 以及最终要建立起来的用户自主的“authentication layer”。

具体要解决的,就是实现不同Identity系统之间的导入导出。这个导入导出的机制也是完全在用户自主控制下进行的,任何人“can decide who gets to see what, where it is and under what circumstances that data and content exists. ”

完成了这步后,就是他们称之为“common actions”的事情需要处理,不同社会性网络/系统之间的相互操作,比如前面提到的“建立关系,发送消息,创建或者加入群组,发布内容等”。

以上这些都被他们装到了PeopleAggregator的API中。

更让人钦佩的设想还在后面,他们希望建立一个接口,借助这个接口,PeopleAggregator能把下面这些服务相互连接起来。具体实现上类似Mashup,甚至可以更简单,只需要定制或者设置就可以。

  • Calendaring and events: Google, Yahoo (and UpComing), Microsoft, 30Boxes, Zvents, Eventful, Whizspark
  • File storage: Xdrive, S3, Gdrive, Live Drive, Box.net, Omnidrive
  • New kinds of aggregators and tagging systems: dabble, Plum, del.icio.us
  • Media repositories: YouTube, Revver, ourmedia, Google video
  • Citizen journalism and media (ratings, opinions): NowPublic, Memoerandum, Digg, OhMyNews, NewsVine, Tailrank
  • IM and presence: AIM, MSN Messenger, Yahoo Messenger, Jabber
  • Social Networks: Bebo, Tribe, OpenBC, Multiply, MySpace, Facebook

以上基础都打好了之后,他们要做“persona editor”:

“help humans keep track of, edit, manage and otherwise manipulate their digital identities, web services and content – which is spread far and wide across the Internet.”

—————

这是之前我提到的“第三代SocialNetworking”的一个尝试,核心是用户中心的、分布式的、可移动的、定制化的Live Web/Social Web。

继续阅读学习PeopleAggregator(一)

连接各个社会性网络的Greasemonkey脚本

前些天还在考虑如何整合分散在各个社会性网络中的个人信息集

今天就发现一个不错的变通方式:使用GreaseMonkey脚本。

paolo编写了一个javascript脚本,叫做Identity Burro,他说这能让社会性网站更富社会性。

一般情况下,人们在各个社会性网络服务中,总是注册相同的名字。IdentitBurro就是利用这点,抓取所浏览的社会性网络服务的URL中的用户名,然后依此用户名生成一个个指向其他社会性网络服务的链接。

右上角的截图显示了浏览del.icio.us/zheng的时候,该脚本给出的我在technorati、flickr、last.fm、43things、rojo等服务中的个人网址(那个livejournal和rojo应该不是我?!)。

很有意思,无论在哪一个社会性网络中,它都会出现。这有点像什么呢?我在浏览器本地,为不同的服务创建了一个HUB(这个比喻可能不准确)。

这种方式有个不足的地方,那就是相同的用户名在不同的社会性网络服务中未必是同一个人。要脚本来判断当然不可能。这就提出一个问题,如何统一不同社会性网络服务中的个人ID

Paolo那里提到OpenID.net。

统一的个人ID服务,可能么?

继续阅读连接各个社会性网络的Greasemonkey脚本