Universal Name Service
RID: Real ID

Goal

 在 World Wide Web 上提供一套全名服務, 以符合真實的身分需求。

Abstract

 本系統是要在 World Wide Web 上提供一套全名服務 (Universal Name Service, UNS), 以符合真實的 (real) 身分 (identification) 需求。 該名稱 (name) 所代表的身分,必須是放諸四海皆準的(universal),可以是一個真實或虛擬的自然人或法人。每一個身分有一個可變的真實名稱,及其他若干虛擬綽號。本服務提供方便與安全的相關機制與 API 以支援該身分的屬性,如名稱、住址、真實度、信用度、與可靠度等等,並保有網際網路上的匿名性和個人隱私。該身分與屬性是透過社會網路 (social network) 與 Web 2.0 來發展與確認,並具可延展性(extensibility) 以增加新屬性與其評量機制,甚至建立新的相關服務來支援該屬性。 透過這樣的身分機制,使用者可以一真實身分參與網際網路上重要的言論發表以累積本身的信用度與可靠度,或進行網路買賣交易, 也可以一匿名或佚名身分進行其他活動。 使用者或系統之間並不必要知道彼此的真實名稱,但是可以得知該名稱的真實度、信用度、與可靠度等,進而得知所提供相關資訊的可信度。 本系統支援 OpenID 以擴大使用群,並採用 Freenet 以增加安全性。 有了本系統,使用者能逐漸建立本身的身分,不僅可統合其他的帳號密碼,更可以在 World Wide Web 上更真實地模擬人的社會行為。

Group Member

1. Introduction

  本計畫 (Real ID project) 的目標,是提供一套完善的網路身份Identification服務,以確保在網路上使用這個ID辯識服務的使用者在現實世界中是一個真人、法人或其他單位。
  為達成這個目標,我們利用social network的特性設計了一套方法,讓使用Real ID service的使用者能證明自己確實是一個真人在使用,主要的方法為:透過人脈網路,搜尋出與自己生活週遭現有或曾經的人際關係。例如facebook就靠著social network的力量,將個人的人際關係網路化,舉實例來說,如在Real ID中填寫自己的教育歷程;國小同學、國高中同學及大學同學等關係,我們的ID search agent將會自己去與這些使用者做mapping,以確定這個ID的使用者本人確定是經過這樣的成長歷程。
  為了模擬這套Real ID的技術能如同真實世界般運作,我們設計了兩個重要的機制來實現;分別稱為 Credit 和 Reliability。我們希望採用 Real ID 的使用者都能為自己的所作所為負責,如果真實世界中的信用評價。因此Credit在本系統中將扮演一個無所不在的角色。無論使用者做了什麼事,這個Credit都將跟著做調整;舉例來說,若使用者在論壇中發表不實的言論,他的Credit將下降;而使用者若是在拍賣網站中賣劣等品質的商品,他的Credit也將下降。但此處的Credit只是該使用者的信用評價,不等於他的真實性,換言之,他可能是個真人,但只是行為不檢罷了,因此我們設計了另外一個稱做Reliability的機制。從一開始ID被創建時,我們會計算這個ID在Social Network Tree中距離root ID(或稱 initial ID,即系統最初被註冊的ID)有多遠,由於越遠的Reliability將越低,使用者需應該善加經營自己的ID,並多加填寫自己的相關資料來提升自己的Reliability,或是在善用系統中的任何資源來證明自己是個真實的使用者;舉例來說,一個使用者經常在某種論壇上發表文章、或是經常在某個網路商店上消費,這些都可以代表這個ID背後是確實有一位(或一位以上的)使用者在使用。
  要達到確定網路上的ID背後是確實有位使用者在操作,且又可以保有他的隱私和隱匿性並不容易,所以在隱私保護的部份我們採用了分散式Database的方法,我們僅架設一台中央的Database來儲存使用者Login時的ID與Password,其他使用者的個人資料將使用XML格式的檔案交由使用者自行保管,以及分成許多區塊隱藏在許多不同使用者的XML profile中,如果一來使用者的資料並不會只存在一個中央的伺服器上,進而產生Service Provider可以監守自盜或是中央資料庫被入侵的風險。

2. Definitions

  1. User: 採用Real ID 或 OpenID 登入服務的使用者。 a person or legal person with a UNS account.
    • person : a human being or a figure, might be live or dead or virtual (小說 or 卡通人物).
    • dead person : a dead person needs to be maintained by a privileged user.
      • the ownership can be removed if abused.
      • can be inherited.
      • or auctioned for a period of time,
    • virtual person : a virtual person need to be maintained by a privileged user.
      • the ownership can be removed if abused.
    • legal person : a corporation, an organization.
  2. Credit: 我們希望Real ID就如同真實世界一般,使用者可以享有原有的言論自由與一定的匿名性[1],但同時又能為自己所說的言論負起責任,而非全是完全沒有可信度,因此我們採用了信用評價機制 (Credit),這個值將代表該使用者在每個Service Provider裡其他使用者對自己曾經說過的、或曾經做過的一切行為所評價的分數,若分數值低可能表示其使用者發表的言論相對可信度低。
    • Credit在本計劃的原始概念: 用來衡量該user在整個social network的貢獻程度. (使用者提供資料的誘因?)
  3. Reliability: 為了能讓Service Provider確定他是一位真實的使用者,而非robot、agent或multiple id的使用者,在整個Real ID的architecture中最重要的一個feature就是Reliability,這個值代表了這個使用者到底有多「真實」這個值是從使用者Register到被Delete中間都將存在的值。當使用者剛註冊時,Reliability的值將與root ID的使用者 (最早註冊的使用者) 做比較,關係離root user越遠,其Reliability將越低,使用者要提高自己的Reliability就要認真的當一個「人」,譬如認真經營自己的社群網站,或是提高自己在各Service Provider的Credit值等等,Real ID將對使用者在Service Provider中進行的所有行為來不斷修改使用者的Reliability。
  4. Type of Relationships: user與user之間的關係, 處於隨時變動的狀態(time based),多種類別的Relationship 如:家人、朋友、同學、同學、團體.單向關係─關係密度低,雙向關係─關係密度高。
    1. node : 代表user 的 node.
    2. edge : the link with the user.
  5. Activity: 簡短總結user account在某時間點的事件。
  6. Client Side Service: Real ID Client Side Service是提供給User面的服務,這些服務包括了:
    1. Register: 負責註冊機制,使用者必須向Real ID註冊自己的ID,並從Real ID Web Service中取得自己的XML profile。
    2. Modify: 修改自己的profile,或是刪除自己已經不用的profile。
    3. Regenerate: 若發生帳號被盜用,或因不可抗拒的因素
  7. Server Side Service: Real ID Server Side Service是提供給Service Provider的服務,服務內容包括了:
    1. Verify: 在使用者提出登入申請時,做驗證的動作。
    2. Suspend: Service Provider可向Real ID申請將某位使用者在自己的Service (網站或其他服務) 中停權的權力。
    3. Search: 在Real ID social network中搜尋使用者的資料。
  8. Distributed User Profile:

3. Features

  1. Real ID Web Service: Real ID的系統架構是建構在標準的Web Service結構上,所有ID的request (如Register, Verify, Regenerate, Modify…etc.) 皆採SOAP protocol, 而主要的兩項Service (CSS: Client Side Service; SSS: Server Side Service) 為WSDL所撰寫,而本服務則將利用UDDI註冊讓所有Provider可以方便呼叫和採用。
  2. Service Provider: 所有採用Real ID Web Service的網站或服務提供商在Real ID架構中稱為Service Provider。Service Provider可以在Real ID system中註冊採用Real ID的服務,並自訂獨一無二的custom fields來儲存使用者額外的資訊。
  3. Privacy : data and profile are stored locally in the storage users own.
    • idea: local profile經過使用者user的private key加密, 使用者上線時, 會將public key提供給name server. key會定期更換(資料很重要, 故local端也要好好保護; 每次上線重新產生key?)
  4. Storage Server : a limited free storage for users to own, it is always on-line.
  5. Cache Server: some data not private can be cached on a cache server or distributively, so that when the user is off-line, some data could still be accessible.
    • idea: 配合privacy那點一起考慮, 只對flag為private的attribute做加密, 使用者一旦下線就將public key從name server移除, 使cache的資料無法存取?

4. Framework

Fig 1. The overall architecture of Real ID service

1 Cooperating with Real ID

There are so many services that we can’t build all of them into Real ID and the architecture of Real ID should be kept as simple as possible. But fully decoupling all services will introduce unnecessary overheads because different providers of the same service must communicate with each other without any help from Real ID.

Loosely coupling services with Real ID means that services only depend on a limited set of interfaces provided by Real ID. In our design, every Real ID contains service attribute fields which play as communication channels between services. Each type of services can alter the corresponding field only but it can read other fields if permitted. In concrete, Real ID provides two methods, one for retrieving and the other for storing.

String getServiceAttribute(String sid, String serviceType);
 
boolean setServiceAttribute(String serviceType, String attr);

Detail description of these APIs can be found at API Documentation for Real ID.

Example: User Location Service (ULS)

ULS uses the attribute field to record the provider’s address so user agents can find out the correct provider directly, thus saving the resolving time. Please refer to RID Phone for practical desgin example.

Scenario 1: A signs in a ULS provider S1

  1. A connects to S1.
  2. S1 authorizes A via Real ID.
  3. S1 invokes setServiceAttribute(type name of ULS, S1’s address).
  4. A keeps sending the current location to S1.

Scenario 2: B wants to find A’s location

  1. B signs into Real ID in order to use other services.
  2. B issues a query by a ULS user agent (UA).
  3. UA looks up S1’s address via getServiceAttribute(A’s sid, type name of ULS).
  4. UA connects to S1 and discovers the current location of A.

whitestone 2009/09/29 08:29

5. Implementation

在Real ID系統架構上,我們採用 Ubuntu Server 做中央伺服器,而由於 user profile 等資料使用XML格式,所以我們特別使用 Senda 資料庫系統為 XML database

6. Experiment Result

  • TBD.

7. Conclusion

  • TBD.

8. Future Work

  • TBD.

History

  • TBD.

Download

  • TBD.

Reference

Temp

  1. TODO:
    • 同 uID 者被搜尋時會一同列出.
    • 系統的價值在於整合, 提供的 WebService 提供等級評等功能(不 expose property, 可由外部傳入評等公式 or 可方便的由 3rd 處進行評等模組之製作(將評等所使用的 common properties 進行封裝)).
  2. Undefined terms:
    • Real ID or RID (ARE ID) or PowerID (Profiles Over Web for End useR) or ?
    • sID (system ID)
      • 在註冊時決定的一個GUID.
      • it is unique per user, but can be changed under some condition, e.g. reincarnation.
    • uID (user ID)
      • 使用者用以登入Real ID的一個類似OpenID表示形式之ID.
      • it is user name for any format, OpenID is one of them.
      • 目標是能讓大家能在網路上用自己原本的姓名就能方便的申請/使用各項服務, 有辦法分辨出兩個同名帳號的不同處
    • nID (nickname ID)
      • nicknames for UID
      • how many per user?
      • OpenID
    • pID
      • supporting ID for non-person ID
    • Password
      • use the same format as OpenID
  3. Undefined features:
    • User's attributes: need to be classified.

Notations

notations description notes
## primary information to create the account
# basic information to activate the user
n+[m][$] free n array + m expendable array, if m omitted, m is unlimited, $: paid or not
u unique, only one in system
S secret, encrypted
s secret, encrypted if asked
p private, only on-line can be queried, noncacheable

Attributes

attributes
name type class description notes
##sID unsigned int[4] S u
##uID char[40] S http://realid.csie.org/user/????
##pID sID S link supporting sID, 0 if it is a real user
English name char[40] S
nID[3+$] char[3+][40] S
#ID char[??] S u 身分證字號 護照號碼
Credit float = 0 how much we can trust him/her?
Reliability float = 0 how much we can relay on him/her?
#Reality float = 1 how close he/she is as a user?
permanent address char [?]? p 可再細分國城街號等
communication address char [?]? [p] 可再細分國城街號等
phone[1+$] char [??]
fax[1+$] char [??]
mobile[1+$] char [??]
email[1+$] char [??]
birth time ? ? ? ? ? 西元年月日時分
dead time ? ? ? ? ? 西元年月日時分
will char [300+$] 遺囑
father sID S link the user can be created by system with basic information
mother sID S link the user can be created by system with basic information
description char[1024+$] description of the user

Questions

  • 2009/10/01
  • 2009/9/24
  • 法人,神話人物和卡通人物如何解決?
    • Ans : 初步想法,使用者需先註冊帳號,達到一定真實性時,由使用者推薦或連署。
  • 使用者的relation 要存在那裡?relation 如何建立?

Old Questions

  • TBD:
    • 一個人要查是否是真的人 該怎麼查?
      • how close are 2 uIDs, a uID and a nID, 2 nIDs, to the same person respectively?
    • 有新的 user 加入 網路該怎麼長?
    • How to protect a user's private information?
      • Once it is stolen, how to recover or reincarnate?
    • reincarnation
      • The user 重新做人, most attributes reset, some are kept。
    • 國小通訊錄, 國中通訊錄 … 校友通訊錄, 如何做? 怎麼做能達到某個人更新了自己的聯絡資料, 網路上的人都能知道?
    • 用「年」來紀錄每個人的成長過程
    • API 要有 Input 與 Output 的定義
    • Real ID 的 search engine 要怎麼做
    • 人性本善, default credit = 1
  • Probable Applications:
    • Social Network 的具體應用,例如:畢業同學通訊錄;User 更新自己的資料後,他(她)過去的同學不會找不到他(她)。
    • MoovieLive 影評功能?
    • Where are you? 出差, 旅遊 怎麼找到人?
  • 11/06 1 on 1 Meeting 要討論的項目:
    • User's profile is stored in user side / server side ? Distributed or single file? If it is distributed, does the file store in freenet structure?
      • Ans: Priority: 先存在 user local side, 我們也提供一個 storage server 給不想存在 local 裡的 user 存, 還有 cache server 可以改善 performance.
      • idea: 我們提供的storage server能讓user自己掌控profile的online/offline, 就像是使用者有自己的local storage一樣.
    • 承上, 那 Attributes file 要存在哪裡? Sedna 的作用又是什麼?
      • Ans: Attributes file 同 user profile, 為同一份 XML file, Sedna 用在 storage server 和 cache server 上, user local 是否採用未定.
    • 承上 Attributes file 要存在哪裡? 這將影響到 SP 如何 read / write (can they wirte it?) 這個 XML file?
      • Ans: SP 是利用我們提供的 API 做存取, 因此開放哪些 API 給 SP 是我們決定的.
    • The definition of “Credit”, 是一個 user 一個, 或是一個 user 在每個 Service Provier 裡都有一個?
      • Ans: 一個 user 一個, SP 端的是 SP 端自己的事情.
    • All behaviors (e.g. Register, Login, Delete, Edit, Search … and so on) are handled by Open ID?
      • If the answer is “yes”, user's profile 是在哪個 process 時被存到我們的 db 裡? And how to do search function? (real-time update?)
      • If the answer is “no”, user's ID/PW 要在哪個 process 時與 Open ID sync?
      • Ans: 我們只提供 API 給 SP, 是 SP 要能與 Open ID 相容.
    • 如何讓 user 避免重覆填寫自己已填過的資料? (microformat is the solution?)
      • Ans: microformats maybe the good solution.
      • idea: 使用microformats是為了相容性, 故我們的implementation採不採用皆可, 但要有辦法mapping, 當要export成microformats可以用到.
    • 若有 user 要 Delete/Remove 自己的資料, 或要 reincarnation, 這個動作是否需要 SP 審核? 或是 user 直接向 Real ID 提出申請?
      • Ans: 這是 SP 自己的事情, 我們提供的是 ID 服務.
    • 承上 Service Provier 和 Real ID 到底該怎麼互動?
      • Ans: 同上, Real ID 提供的是 Name Service. 與 SP 可透過 API 溝通.

Todo

  • How to integrate Social Network into this Project? – Deadline 11/30.

Minutes

  • 2009/10/01
  • 邀請函
    • 600 封( As MSN)
    • 加好友(5000, As Facebook)
  • 2009/09/25
  • account 登入方式
    1. 使用者自己註冊
    2. 使用Open ID
    3. 使用yahoo,google,facebook等ID
  • account 相同處理之方法
    1. 用 email 來辨別使用者
    2. 提供問題辦別使用者
    3. 送一個cookie(or key),到使用者電腦,由server side來辨別
  • Real ID 的真實性
    1. 實數 0 到 1

Old Minutes

  • 12/9
    • OpenID compatible. #due date: 12/19
    • Attributes. (see Attributes section of this page) #due date: 12/19
    • Implementation of basic function. (e.g. getReality(id))
    • Privacy of attributes. (address vs phone)
    • Pre-creation of IDs. (e.g. parents)
    • PID.
  • 12/12 lab meeting
    • 10 % effect
      • 我們是不是也可以使用類似的觀念在 reality, credit 上?
    • Currency 的概念
      • Behavior ← Trading → Credit / Reality
        • 買賣的概念 / 市場機制?
        • Credit 越高的”人”代表越多人想要 buy “其” behavior.
      • 1 by 1, multiple instance?
  • 12/16
    • ID service.
    • 好用(應用).
    • 可信度? real? reliable?
      • Real是什麼?
        • 大家的共識 → matrix.
    • Privacy?
      • System id changes from time to time.
        • Idea: sid = time-based-hash(sid)
  • 12/18
    • Implement as Java RemoteObject.
      • Freenet is also written in Java.
    • Freedom of funny plus privacy.
      • Killer Apps.
  • How to initialize such a network?
    • Total credits will grow from time to time. (inflation)
    • Starting from 10 nodes.
  • Anything(person, node, service…) in the network has its own credit.
    • 管制?
    • the Unix philosophy: “Make each program do one thing well.”
    • Emotional entity.
      • Each node has a eager to survive in this network.
      • Even service got its own credit!
  • The value of information?
    • Automatic opinion extraction.
    • deposit.
projects/realid/realid.txt · 上一次變更: 2011/11/26 10:41 由 cwhsueh
CC Attribution-Noncommercial-Share Alike 3.0 Unported
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0