[讨论] 通过DID Connect来实现跨域统一 connect的设想和思路 #60
Comments
"所有支持相同协议“ 里面的协议具体是什么协议？应用和 DID Storage 之间相互信任的协议？谁来决定 DID Storage 信任哪些应用？另外，我们的技术实现中 Blocklet 软件和 Blocklet 实例不是一回事，DID Storage 可能知道某个 Blocklet 软件的存在，但是不知道某个 Blocklet 实例的存在？这个区别如何体现在”协议中。 还是说你上面的描述只是想解决：用户来到我们的网站上，比如 Store、Launcher、Storage 等服务间跳转时 Profile 自动获取的问题？但是目前钱包的 DID 实现是每个 Blocklet 实例生成的 DID 不同，如果这个环节少了钱包，DID 的生成无从谈起。 |
|
根本目标是解决用户体验问题， 不能因为did而牺牲用户体验。 如果我们有100个单独 instance 就需要100次钱包签名，那么我们就无法有好的用户体验。 |
可能可行的方案：
|
|
采用这种方式的连接隐私特性一定下降，但这是必要的。 情型1: 例如我们arcblock的这么多个不同业务，这里其实对用户而言在这些业务之间隐私是不必要的，目前的方式反而导致用户需要一大堆passport。我们还得设一堆信任关系来减少passport 数量。 情型2: 又如一个去中心化社交网络，即使这个网络分散在不同站点上，在这个社交网络里用户是需要有统一 DID的，否则没办法形成社交关系。 也许不需要改变钱包的DID 规则。 |
|
如果我们把这个和 passport 的 trust 关系那里直接挂钩，会不会是和好主意？ 这样一群站点，只要需要跨域统一，配置即可支持。 |
|
这个问题 本周开一个讨论会一起讨论一下。 我觉得这个直接影响使用体验。 @wangshijun @linchen1987 @NateRobinson 尤其我们web3kit 带来的去中心social network 起来了，会产生无数个人站点，如果不能跨站统一登录，那么会很不好用。 过去单纯的靠浏览器端的script来跨域是很困难的，但是我们有一个统一的后端，就意味着我们可以解决的方案多很多 （例如一个通用的proxy服务来实现跨域，这个proxy验证did/vc来防止滥用和安全问题）。 我觉得能解决。 实现后带来的结果的使用体验：
|
|
补充一些我的想法： 首先对比一下现在主流的 OAuth2 第三方登录流程
下面是我设想的我们 DID Connect 实现统一 Connect 服务的思路一些问题：
这个 proxy 会有点类似第三方授权网站的存在，我们在交互上要不要做成类似的体验可以考虑一下。
|
|
还有一个疑问，user 在不同站点的角色是不一样，在A站点有可能是访客，在B站点有可能是Owner. |
是的。 你在不同用户的页面上可能是有不同权限的，比如有的是访客，有的是朋友，有的是owner。 现在的social network也是这样的，随时需要判断当前用户和当前对象之间的访问关系。 我们采用passport 方式在这个细节上可能需要考虑一些细节，因为passport 并不包含你的social graph， social graph 应该保存在哪里？ 我认为应该在did space里 （而不是链上，或者钱包里）， 每个人的social graph应该是自己的隐私信息不应该在链上。 不过如果用户采用购买了某个会员passport的方式访问另一个用户的特定权限的访问控制问题，我还在思考。 我整体思路是这些passport 也同步一份放在did space里，然后钱包授权当前浏览器内的session key （可以也是一个did）可以签名这些passport即可。 考虑到这个细节是很好的，的确是我们设计的时候需要考虑的。 |
多条。
可能不需要。 本质上这是一个master app 存在于多个域名站点上。
只有一个，就是按个master app的。 会有必要的隐私问题，但这是合理的，比如很多国家法律规定你不能蒙面进入公共场所，那么你逛了一遍商城很多人知道你的确逛了。 在意这种隐私的，只能选择不使用 （不去逛商场）。 需要思考是否会有安全隐患。 比如一个网站自己声明自己是ArcBlock系列的一个，但实际上不是。 我们公司这种可以通过授予一个certificate的方式。 但是比如decentralized socialnetwork 会是permissionless的，这样会不会带来安全问题？ |
本质上类似，如何杜绝一个钓鱼网站？ 它可以有正常的domain，SSL cert，浏览器可以访问无法判断这是否是一个安全的。 这一直是难题。 在我们这里可能也很难自动判断，因此关键是不能产生安全问题 （例如窃取我的用户数据、资产）。 一个过去访问ok的网站，也可能被黑而变成一个危险的网站。 |
|
我们第一阶段可以把目标简化和明确化：
这个阶段目标解决了，再去解决社交网站需要的能力。 |
|
根据上面的讨论和现有的实现，我理解中解决这个问题的几个关键点：
要解决问题 1：理论上这个问题解决之后，任何站点群都可以“结盟”
要解决问题2 = 解决下面几个子问题：
要解决问题3，更多是个体验问题，只要问题 2 里面的验证失效的情况下，自动弹出让用户切换 passport 即可 |
|
研究了一下，不只是我们想这个问题其他人也想解决。 stackoverflow的global network auto login （但好像现在不work了？）： OpenID connect的 Single Login Identification （SLI） IBM 的 Cross domain single sign-on (CDSSO)
Auth0的一篇科普：
我们因为每个domain 都有相同backend，因此我们不需要一个中心的auth server。 |
@mave99a 我认识里面这个相同的 backend 就是 blocklet-server（实际上不是同 1 个 server，但是因为这些 server 遵循的协议相同，所以能认出来对方签发的 token），还是说你这个 backend 另有所指？前面的讨论你提到了 did-space，我认为解决跨站 session 共享还用不到 did-space（如果拉取用户 profile 算在内的话则能用到） |
我指我们不需要一个中心的认证服务器 |
|
我思考了一下，对于这种 wellknown 的“登陆联盟” （暂且这么称呼），钱包侧可以为此专门优化profile、passport 和这些联盟的组合关系， 因为这些登陆联盟的隐私往往比严格 DID的更弱，但又是应用必要的，另外因为这些联盟往往需要profile 比较统一，否则失去了“统一用户”的效果，因此其profile 信息应该是需要用户仔细推敲的（尤其社交类的）。 安全性： 如何防止一些坏站点利用联盟特性而以此来收集用户信息甚至欺骗用户？ 对一个企业/DAO，可以是permissioned，这些联盟成员需要持有证书（联盟签发给这个应用的实际的DID）。 但对去中心社交网络类型的服务，也许这是不现实的 （难以管理）有没有可能有一种social score 的机制，或者一种masked 机制，先准匿名访问着，待信任了才切换为完整状态，并且每个站点有多少人信任有一个机制链上记录，钱包能根据用户自己的信任关系给用户提醒或警告。 e.g. |
感觉这是把 https 给去中心化了，不通过中心化的证书颁发机构，而是通过链和社交关系在给网站”颁发证书" |
|
|
|
刚讨论时我在思考这个 DID Connect Hub 应该是 ”对方的 Hub" 还是 “自己的 Hub" ? 如果是自己的 Hub, 和之前 “每个钱包都有一个专属 Server" 的思路类似。 有没有可能有一种场景，我希望我的身份不是由另一方（个人、应用或 Hub）来决定的，是由我自己决定的？
|
自己的。
这个我觉得是可行的，但其实就是某一个特殊的permissionless网络（比如叫public），也就是你给出的一个DID 就是你的DID。
现实中，你认识的马云和马一龙是一个“public”网络里的DID
|
上面我提的方案和自己的 hub 不冲突，理论上用户可以在自己的 did-space 允许某个应用来访问自己的某个 did，这个应用可以是某个，也可以是某群，构建 did-connect hub 之后，用户省去了给一群应用逐个出示 did 的麻烦。 |
|
上面的这些设计里，默认每一个人都有自己的这个特殊公开did 的 did-space，所有统一对外的profile 信息 都在这个did-space 里保存， 而所有这些外部服务需要保持的个性化信息也都保存在这个 did-space 里， 这样这个did space自然成为用户aggregate 所有服务的起点，在这里就能获得自己所有订阅、关注、参与的服务（endpoint，和DID）的列表。 一个用户自己的agent （一个blocklet）就能自动地根据这个列表，为用户聚合信息，提高用户整体访问的使用体验 （例如用户不需要用的时候才遍历自己的列表，那样就比较慢，体验不好）。 |
|
最新的实现里面需要支持 DID Connect、Auth0 登陆的会话 |
|
这个是不是已经基本都完成了？ |
痛点：
太多不同的域名和DID下的站点，每一个都需要重新连接钱包认证， 无论如何实现，这个体验都不好。
理想中，一群可信任的站点，用户只需要一次连接，就可以通行所有的站点，仅当需要执行关键的操作才需要连接钱包。
现在的服务，例如Google，可以用自己的account一票通行自己所有的服务。 过去 Facebook connect 流行的时候，所有的Facebook connect授权过的站点都能一票通行，这个使用体验是非常优秀的。
困难
过去似乎完美的解决方案只有实现自己的浏览器或者在浏览器上使用特定插件。 但这些都会影响用户体验。
另一个思路是有一个属于自己的app shell，访问其他人的服务，实际上都在自己的shell 下进行，这样实际上相当于不存在跨域访问。（这个思路在这里讨论：
上述两个方案都不理想，前者需要有新浏览器或安装插件，用户onboard成本过高。 后者可能实现困难，并且对UX 体验有限制，尤其可能会因此限制应用本身的个性化程度，以及降低别的网站的访问量，用户对这种方式提供访问的积极性不高。
解决方案
一个最新思路是我们有了 did storage 之后，我们可以设法：
这个动作仿佛用户把自己的一个专业的u盘授权插入了被访问的站点，这个站点从此盘里获得必要的信息，并且写入和这个站点相关的信息。
达到的效果
用户可以一次确认后，在各个不同的网站上畅通无阻，各个网站能立刻识别当前的用户，并把这个用户在这个网站上的个性话数据 （例如配置、comment 等）直接写入用户自己的storage。 达到非常好的用户体验。
局限
只有使用did-connect 并且使用我们的平台的应用才有可能实现互通。
安全性
用户可以自己 opt out这种跨域方式，这样支持跨域的did connect 无法获得任何信息，也不会开启这个过程
用户第一次到一个新的网站（新的DID）的时候，did connect 会提示用户授权 （这个授权可以做到需要或不需要钱包，根据用户的安全设置），只有被授权了的did，才有可能连接这个用户的 storage
用户可以在自己的管理界面立刻revoke 访问权力，清除数据等。
对方站点的bug 或恶意滥用风险，比如大量写入数据或者写入垃圾恶意数据等
隐私
这种方式有可能会让DID 的隐私一定程度上下降，但是否如此以及如何规避待具体思考。主要原因是，既然用户不需要每个站点登陆，那么这个用户用于连接的DID 以及profile 可能在多个站点之间会被获知。
The text was updated successfully, but these errors were encountered: