能不能应用密码学，实现授权下的匿名——付费得到授权，但使用过程是匿名的

[sillydaddy]

有没有这样一种授权+匿名的组合方法？

1. 用户付费后得到服务方提供的一个授权码。（这时服务方有能力将该用户付款过程中的信息与该授权码关联起来）
2. 用户使用授权码，随意生成一个登录码，使用登录码使用服务。（这时服务方能验证登陆码来自于有效授权，但无法将该登陆码与特定的授权码关联起来）
3. 用户使用某个授权码生成多个登录码，使用服务。（这时服务方能区分这几个登录码来自同一个授权码，但还是无法与具体的授权码关联起来）
4. 用户可以针对服务方发放的授权码进行独立验证，以确定后续使用此授权码生成登录码时，不会暴露自己的信息。

这 4 条应该是递进的关系，有些应用可能只要求满足 1，2 即可。如果 1，2，3，4 都满足，就比较理想了。其中 3 的话，可以防止用户生成大量的小号。4 的话，主要还是防止服务方搞小动作。

对于应用场景，最简单的解释就是：用户付钱才能使用服务，但在使用服务的过程中，不想被提供服务的一方彻底追踪，扒个底儿掉。

有这个想法，主要是现在的隐私环境太差了。如果可能实现这样的系统，我会毫不犹豫将其纳入到自己的产品中使用。

感谢楼下各位。
回复里提到的盲签名，确实可以很好的实现主题里的 4 点要求。

具体就不写出来了，留给大家思考吧。不愿思考的可以查一下“电子现金”相关的资料。对于主题里的第 3 点，在盲签名基础上使用一点小技巧就可以做到了。

[dzdh]

中间 CA 证书再生成证书？

[Jirajine]

有的，你可以看一下 Geph 迷雾 tong，它的付费系统就是这样设计的。

[sillydaddy]

@Jirajine 谢谢，我去看一下。

[hahastudio]

不知道对不对，在我看来，现在的用户名密码模式，也不能将某个用户名和某个用户特定起来
但对于服务方来说，这个用户的使用时间、设备、IP 、地理位置和喜好能关联起来就够了

[q9OxQg]

也立即想到 @Jirajine 提到的 geph，看上去很良心的一个梯子。可以一试。国内的 app 和服务还有 big techs 提供的产品和服务不可能这么做。

[sillydaddy]

@hahastudio 你这么说好像也没错。。用户名本来也是匿名的，不过关联到付费信息就不是匿名的了。

[sillydaddy]

@q9OxQg
@Jirajine
在 v 站见过迷雾 tong，但没想到它采用了“盲签名”这样的技术，感觉这点确实挺好的。

[q9OxQg]

@sillydaddy 它提供免费档的，虽然限了速，已经很良心了。得了，不歪楼谈论这了。匿名授权可行的，只是服务提供者没有动力广泛这么做。

[oxogenesis]

这还用想？
用户在自己的设备上生产密钥对及账户，用户天然就是匿名的。
服务提供方对于付费的用户，将其账号加入白名单，对白名单用户提供与其支付金额对于的服务。

有时候脑子是个好东西。
看看我 GitHub 的聊天客户端和服务段，自然就懂了。

[Stain5]

？？？？？？？
直接在付费阶段匿名不就好了，XMR 了解一下

[muzuiget]

本来就可以，无非就是 API 的 Access Token 。

最大问题是，为什么服务方要这么做，跟踪用户不香吗？哪怕用 GMail 现在都强制要求你提供手机号，就是想精确跟踪你。

[jwenjian]

human-id.org

[gps949]

https://wedpr-lab.readthedocs.io/zh_CN/latest/docs/selective_certificate_disclosure.html

[gps949]

不过还是没明白楼主意思，这标准付费过程哪里有隐私了？
服务方服务端调用结算方（如三方支付）接口，传入应付费金额及回调接口，获得订单号及付款链接之类，
客户端让用户跳转到结算方页面，
用户在结算方页面完成支付，结算方客户端提示成功并服务端返给服务方成功（也有需要服务方主动 pull 的），
结算方跳转回服务方完成页面，服务方发放授权码。

整个过程中信息留存情况：
服务方： 用户名（ id ）、订单号、付费金额、付款成功状态（ true ）、购买服务名、授权码、订单备注
结算方：商户名、付款账号名（背后会涉及姓名等个人信息）、订单号、付费金额、付款成功状态、订单备注
用户方：用户名、订单号、商户名、付款账号名、付费金额、付款成功状态、购买服务名、授权码、订单备注

所以这里面关键隐私有两处，一个对于服务方来说不该知道个人信息、对于结算方来说不该知道购买服务（按国内审查来说这个其实也是该知道的）。按上述过程并不会透露啊？

[sillydaddy]

@gps949 #14 > “一个对于服务方来说不该知道个人信息、对于结算方来说不该知道购买服务（按国内审查来说这个其实也是该知道的）。按上述过程并不会透露啊？”

可以再看一下主题里面的前 2 条，把授权码和登录码分开，主要是让服务方没办法将用户注册(付款)得到授权时暴露的信息，与用户使用服务时的信息一一关联起来。

举个例子，xiaoming 用 [email protected] 注册了一个服务，付款后，服务方得到了 [email protected] 这个用户名与付款信息。同时，xiaoming 使用服务时，比如看 iqiyi 视频，xiaoming 所有的浏览记录都与这个 [email protected] 关联起来了。按照正常的逻辑，[email protected] 和他付款时暴露的少量信息，并不会暴露他的实名信息。但考虑到
1. 国内都是实名制的
2. 服务商作出一些“额外的努力”，有没有可能将 [email protected] 以及付款信息，与 xiaoming 关联起来呢？
这些都会危及用户的隐私。多平台的话，效果更甚。

[no1xsyzy]

加密准确地说是一种可以仿射到认知论的范畴，但是我看了主题和 #15 仍然没能明白到底想 “使能 / 使不能” 否认 “什么” 到 “什么” 的映射……
如果与我猜的一致，是 “使能” 否认 “使用记录” 到 “付款信息” 的映射

盲签名是否与同态加密是类似的技术？

[sillydaddy]

@no1xsyzy
对，就是切断“使用记录”与“注册记录”的联系。

比如 10000 个用户注册并使用服务，服务提供方知道这 10000 个注册用户的注册信息(包括付款信息)，也知道这 10000 个用户各自的使用过程信息(比如浏览记录)。但没办法建立注册信息与使用过程信息的一对一关系。

如果主题中的第 3 条成立，那么服务提供方可以把用户准确地区分为 10000 个，各自画像，但画像信息与注册信息是解除关联的。如果主题中的第 3 条不成立，也就是说服务方无法确定用户由同一个授权码生成的不同登录码实际上是同一个授权码生成的，那么服务方甚至都不能确定这 10000 个用户画像。

[neptuno]

确实,应该是所有厂商都不愿意做的事,所有厂商都在将用户整个链路的行为都关联起来