Can you summarize the following document?
        
  OpenID最初由LiveJournal的Brad Fitzpatrick開發,後來加入了Light-Weight Identity,Yadis,Sxip DIX protocol和XRI/i-names。未來的OpenID規範正在由OpenID.net開發,都參與其中。  為了推動OpenID的應用,2006年8月,贊助設立了OpenID獎勵計劃,對前10位滿足要求的軟體專案各獎勵5000美元。  2007年12月5日,OpenID驗證規範9.0和屬性交換規範9.0釋出。

  OpenID相關基本術語:  終端使用者(End User) 標識(Identifier) 身份提供者(Identity Provider, IdP) 依賴方(Relying Party, RP)

  一個想要為其訪問者提供OpenID登入網站,比如example.com,需要在頁面的某個地方放置一個登入表單。與提示使用者輸入使用者名稱和密碼的傳統登入表單不同的是,這種表單只有一個輸入框:OpenID標識。網站可以選擇在這個輸入框旁顯示一個小的OpenID圖示。這個表單與OpenID客戶端庫的實現相連線。  假設使用者Alice在身份提供者openid-provider.org處註冊了一個OpenID標識:alice.openid-provider.org。如果Alice想使用這個標識來登入example.com,她只需要到example.com去將alice.openid-provider.org填入OpenID登入表單。  如果標識是一個URL,依賴方example.com做的第一件事情是將這個URL轉換為典型格式:<nowiki>http://alice.openid-provider.org/</nowiki>。在OpenID 1.0中,依賴方接著請求該URL對應的網頁,然後通過一個HTML連結tag發現提供者伺服器,比如<nowiki>http://openid-provider.org/openid-auth.php</nowiki>。同時也確定是否應該使用授權身份(delegated identity)。從OpenID 2.0開始,依賴方請求的是XRDS文件(也稱為Yadis文件),使用內容型別application/xrds+xml。這種型別在URL中可能存在,而在XRI中總是存在。  依賴方可以通過兩種模式來與身份提供者通訊: 第二種模式更加常用。而且,如果操作不能夠自動進行的話,checkid_immediate模式會轉換為checkid_setup模式。  首先,依賴方與身份提供者建立一個“共享祕密”——一個聯絡控制代碼,然後依賴方儲存它。如果使用checkid_setup模式,依賴方將使用者的網頁瀏覽器重定向到提供者。在這個例子裡,Alice的瀏覽器被重定向到openid-provider.org,這樣Alice能夠向提供者驗證自己。  驗證的方法可能不同,但典型地,OpenID提供者要求提供密碼(然後可能使用cookies儲存使用者會話,就像很多基於密碼驗證的網站的做法一樣)。如果Alice當前沒有登入到openid-provider.org,她可能被提示輸入密碼,然後被問到是否信任依賴方頁面——如<nowiki>http://example.com/openid-return.php</nowiki>,這個頁面被example.com指定為使用者驗證完成後返回的頁面——獲取她的身份資訊。如果她給出肯定回答,OpenID驗證被認為是成功的,瀏覽器被重定向到被信任的返回頁面。如果Alice給出否定回答,瀏覽器仍然會被重定向,然而,依賴方被告知它的請求被拒絕,所以example.com也依此拒絕Alice的登入。  但是,登入的過程還沒有結束,因為在這個階段,example.com不能夠確定收到的資訊是否來自於openid-provider.org。如果他們之前建立了“共享祕密”,依賴方就可以用它來驗證收到的資訊。這樣一個依賴方被稱為是stateful的,因為它儲存了會話間的“共享祕密”。作為對比,stateless的驗證方必須再作一次背景請求(check_authentication)來確保資料的確來自openid-provider.org。  Alice的標識被驗證之後,她被看作以alice.openid-provider.org登入到example.com。接著,這個站點可以儲存這次會話,或者,如果這是她的第一次登入,提示她輸入一些專門針對example.com的資訊,以完成註冊。  OpenID不提供它自己的驗證方式,但是如果身份提供者使用強驗證,OpenID可被用於安全事務,比如銀行和電子商務。

  OpenID正在被越來越多的大網站採用。Yahoo!已經支援OpenID。所有有Yahoo賬戶的使用者可以通過OpenID directed identity方式登入支援OpenID信賴方網站。  Google 曾經支援OpenID 2.0,不過自 2015 年 4 月 20 日起,Google 賬戶將不再使用 OpenID,轉而使用OpenID Connect。  Orange、AOL與Yahoo!都已經支援OpenID。AOL提供每個AOL或AIM的使用者一組OpenID Identity,目前還在測試階段,為codice_1。  目前使用OpenID代替一般賬號密碼的網站包括了 著名的開源社群SourceForge、LiveJournal、Zooomr、Wikitravel、ma.gnolia.com、claimid.com以及Jyte。  在openid.net上有一份公開的伺服器列表,可以讓一般人申請OpenID Identity。

  

  2014年5月,新加坡南洋理工大學一位名叫王晶(Wang Jing)的物理和數學科學學院博士生,發現了OAuth和OpenID開源登入工具的"隱蔽重定向漏洞"。  其實漏洞不是出現在OpenID這個協議本身,這個協議本身是沒有問題的,之所以存在問題是因為各個廠商沒有嚴格參照官方文件,只是實現了簡版。問題的原因在於OpenID的提供方提供OpenID授權過程中沒有對回撥的URL進行校驗,從而導致可以被賦值為非原定的回撥URL。
OpenID是一個去中心化的網上身份認證系統。對於支援OpenID的網站,使用者不需要記住像使用者名稱和密碼這樣的傳統驗證標記。取而代之的是,他們只需要預先在一個作為OpenID身份提供者(identity provider, IdP)的網站上註冊。OpenID是去中心化的,任何網站都可以使用OpenID來作為使用者登入的一種方式,任何網站也都可以作為OpenID身份提供者。OpenID既解決了問題而又不需要依賴於中心性的網站來確認數字身份。