使用场景

在QHID体系下, 用户可以快速构建的将实体身份转化为DID、VC的服务,以达到快速、准确的信息流转,同时还具有隐私保护、溯源防伪、可移植、操作性强的特征。

溯源

很多的欺骗行为之所以能成功,大多是因为”手续、流程“问题,比如假身份、萝卜章。假身份可以通过chanellege-response 的proof模式发现;如果有地方可以查”章“的合法性就可以避免问题的发生。

案例分析:某店铺并不具有某品牌的授权资质,但是欺骗顾客冒充加盟店铺,“挂羊头卖狗肉”,这里有个前提需要说明,以下的方案是解决店铺”识别不具备品牌授权“的资质,不是解决”识别假冒商品“。

1. 由权威部门或者工商组织成立认证中心(sp, service-provider),负责对入驻的品牌商身份审核。

2. 品牌商(did-holder)通过APP将密钥等物料并向认证中心申请品牌-DID。

3. 店铺通过APP提交密钥及实体信息(店铺地址,有效期、法人...)等信息提交给品牌商,品牌商使用品牌-DID私钥签名VC(之所以是VC不是创建DID的主要原因是保护品牌商和店铺的隐私), 店铺选择性纰漏VC中的申明(仅出示必要信息如地址等即可,保护店铺隐私),并使用持有人私钥签名用途创建VP(处于防止VP被盗用的目的)。
 
4. 顾客(verifier)依次验证VC中的实体店铺的地址、VP的签名、VC的颁发者(issuer, did-holder)及其签名,最后通过challenge-response 模式验证持有人(vc-holder)  

../_images/brand-sequence.png

品牌打假

iot资源共享

无法共享智能设备很大原因是受制于“认证”和“授权”类的问题。比如对于所有者来说最大的问题是“谁可以访问我的设备”, 访问者的问题在于“访问谁的设备”。我们通过引入俩个诉求治理方“设备认证中心”和“查询监管中心”来解决这两个问题。

1. 对设备所有者:
    - 向设备认证中心申请数字身份
    - 将设备和数字身份绑定,并定期向中心更新业务信息

2. 对于访问者:
    - 向查询监管中心的子办事单元申请查询凭证(VC)
    - 使用VC向调用设备认证中心注册的设备(直接访问设备或者通过设备认证中心桥接)

3. 对于设备认证中心:
    - 向cert service 申请业务数字身份 cert-id
    - 使用cert-id 向auth-service 注册所有者数字身份  
    - 认证中心是并存的模式

4. 对于查询监管中心:
    - 因为查询的内容可能会涉及用户隐私,所以最由监管方承担
    - 同设备认证中心一样,申请嗯cert-id 后向子办事单元签发数字身份

案例分析:车辆丢失后,失主很难调动民间摄像头查找车辆去向。困难可能在于“利益不相关”和“缺乏合规性”。摄像头所有者部署车牌识别服务,并向认证中心申请数字身份后开展查询业务。失主向公安部门申请数字身份调用车牌识别服务。

../_images/iot-share.png

车牌检测