- From: Stephen Curran <swcurran@cloudcompass.ca>
- Date: Thu, 30 Jul 2020 10:27:21 -0700
- To: Ken Huang <13068783860@163.com>
- Cc: "agropper@healthurl.com" <agropper@healthurl.com>, "steve.e.magennis@gmail.com" <steve.e.magennis@gmail.com>, "luca.boldrin@infocert.it" <luca.boldrin@infocert.it>, "steve.capell@gmail.com" <steve.capell@gmail.com>, "public-credentials@w3.org" <public-credentials@w3.org>
- Message-ID: <CAFLTOV7gRbJLOTdJCchAPwtD1Sn6c0gzDzcMQeVHidz8W=JcPw@mail.gmail.com>
Thanks, Ken. Agreed, with the caveat that such VCs cannot be verified by just anyone -- only by those with access to the peer:did. We've thought about such things a little. The use cases that you are mentioning are very interesting. It sounds like a way to truly externalize (to the subject) what's normally considered to be necessary account information -- eliminating the need to hold the data at all, accessing it only in session with the other party. On Thu, Jul 30, 2020 at 10:09 AM Ken Huang <13068783860@163.com> wrote: > Stephen: > > I agree with most of answers to Adrian's question and for the following > answer, I have a slight different view: > > > > - Isn't everything about a DID and DID document entirely public? > - A public DID is -- e.g. on one a public ledger. However, a peer DID > shared only amongst communicating entities is not. And such a peer DID is > not useful for VCs -- the are just to enable a secure communication channel. > - *My comments: Peer DID together with VCs can be useful for pairwise > business relationships, such as an individual with his current employer, or > a patient with a doctor, or a citizen with one of the government agency for > business purposes. In addition to secure communication channel, the Peer > DID can leverage VCs for on-going trusted pairwise relationship.* > > > Thanks > > Ken Huang > Chair of Blockchain Security of Cloud Security Alliance Great China Region > > > Ken Huang > m13068783860@163.com > > <https://maas.mail.163.com/dashi-web-extend/html/proSignature.html?ftlId=1&name=Ken+Huang&uid=m13068783860%40163.com&iconUrl=https%3A%2F%2Fmail-online.nosdn.127.net%2Fqiyelogo%2FdefaultAvatar.png&items=%5B%22m13068783860%40163.com%22%5D> > 签名由 网易邮箱大师 <https://mail.163.com/dashi/dlpro.html?from=mail81> 定制 > On 7/30/2020 12:04,Stephen Curran<swcurran@cloudcompass.ca> > <swcurran@cloudcompass.ca> wrote: > > I'm happy to respond to your questions with my thoughts: > > - Do DIDs even have to consider VC at all? > - No. VCs are made much easier (viable?) with DIDs to bind the claims > to the issuer, but not the reverse (DIDs relying on VCs). For VCs with no > "call home" component, I think DIDs are extremely useful, bordering on > necessary. > - Isn't everything about a DID and DID document entirely public? > - A public DID is -- e.g. on one a public ledger. However, a peer DID > shared only amongst communicating entities is not. And such a peer DID is > not useful for VCs -- the are just to enable a secure communication channel. > - Do DIDs natively have anything to do with holders, claims, ZKP's? > - DIDs have something to do with claims -- they are used to determine > who issued the claims. As well, in BBS+, the signatures on the claims are > derived from the public key in the DIDDoc of the issuer to enable > tamper-evidence. > - Can't a DID-capable wallet be useful and interoperable if it enables > non-repudiable digital signatures, authentication and authorization without > any notion of VCs, credentials and claims? > - I don't think they are useful -- at least I've not seen good > examples. I think DIDs are necessary foundational elements, but I see far > more value in VC wallets as the "useful and interoperable" layer. The > biggest issue for me is correlatability - a DID being "the identifier" for > a person. > - Do DID methods have anything much to do with VCs? > - They do insofar as DIDs bind the VC with the issuer and so to > resolve the issuer, you need to be able to use it's DID method. By > extension, issuer DIDs enable tamper-evidence and support for revocation > (proof that the issuer revoked an issued credential). > - In some VC models, DIDs also bind the holder to the credential > during presentation of a proof. > > > On Thu, Jul 30, 2020 at 8:35 AM Adrian Gropper <agropper@healthurl.com> > wrote: > >> There were already too many moving parts for me to follow and the >> introduction of ToIP is confusing me even more. >> >> W3C were wise to limit dependency between DID and VCs: >> >> - Do DIDs even have to consider VC at all? >> - Isn't everything about a DID and DID document entirely public? >> - Do DIDs natively have anything to do with holders, claims, ZKP's? >> - Can't a DID-capable wallet be useful and interoperable if it >> enables non-repudiable digital signatures, authentication and authorization >> without any notion of VCs, credentials and claims? >> - Do DID methods have anything much to do with VCs? >> >> Now, I do understand the value of claims related to DIDs, the promise of >> SIOP, the benefits of ZKP and the link between wallets and agents when it >> comes to authorizations for Bob (as opposed to authorizations for Alice or >> other DID controllers). But I sense a lot of complication, in terms of >> standards, interop, and adoption, arising from an unnecessary blending of >> VC and DID. >> >> For example, it's obvious that trust and governance are going to be >> essential to both DID methods and VCs but wouldn't it help to try and >> partition the conversations as much as possible? >> >> - Adrian >> >> On Thu, Jul 30, 2020 at 9:50 AM <steve.e.magennis@gmail.com> wrote: >> >>> I would highly recommend looking into the Trust over IP Governance Stack >>> WG (disclosure I am vice-chair for the group). We are dealing with just >>> such questions and welcome a variety of perspectives, especially grounded >>> in real use cases. >>> >>> >>> >>> Currently some of the thinking is focused on the notion of >>> ‘self-certification’ and ‘self-attestation’ vs. certification or >>> attestation from a ‘known and trusted’ source whose trust is at least >>> partially anchored by operating within a trust framework (that participants >>> can trust). For example a university may self-certify their ability to >>> issue a diploma VC. The perceived value of that VC though is connected to >>> the university being accredited by an educational accreditation body, who >>> in turn is certified by CHEA or the US department of education (in the US), >>> who at the top of the authority chain is self-certified. In the future >>> there may even be a separate accreditation body, independent of the chain >>> just described that is solely focused on the issuance of diploma >>> credentials from accredited and non-accredited universities. >>> >>> >>> >>> The main question is what does a verifier need to trust. In the above >>> example, is the question simply do I have the right university, or is it >>> that the university accredited, by a certified accreditor, etc. In the real >>> world, much of this is known to and trusted a-priori by the participants, >>> or at least is assumed based on seeing a familiar name, a letterhead, >>> having had previous contact, etc. so a verifier probably doesn’t need the >>> entire chain of authority to properly evaluate a VC. When participants seek >>> trust assurance because they don’t already have it or there is presumed >>> risk of fraudulent activity is where the problem comes in. >>> >>> >>> >>> >>> >>> >>> >>> *From:* Luca Boldrin <luca.boldrin@infocert.it> >>> *Sent:* Thursday, July 30, 2020 12:12 AM >>> *To:* steve capell <steve.capell@gmail.com>; Adrian Gropper < >>> agropper@healthurl.com> >>> *Cc:* W3C Credentials CG <public-credentials@w3.org>; Luca Boldrin < >>> luca.boldrin@infocert.it> >>> *Subject:* R: A question on best practices for dependent claims >>> >>> >>> >>> Dear Steve, all, >>> >>> >>> >>> this is a familiar issue in EU, due to the large diffusion on legally >>> binding digital signature (eIDAS regulation), and especially of its >>> strongest form which is the “qualified” digital signature. IMHO, it does >>> not have a satisfying solution yet. >>> >>> >>> >>> The most common way of dealing with the “right of issuing credentials” >>> in EU is simply through “liability”: when vet John Smith issues a >>> credential, he is in fact signign a document with a key whose public key is >>> certified by a CA who identified him. In signing the document, John Smith >>> is himself claiming to be an authorized vet, and he takes legal >>> responsibility for that (identification is essential to enforce liability). >>> >>> >>> >>> This is however not satisfying in many situations, like those you >>> mention. A different approach involves “role certificates”, public key >>> certificates issued by the CA which additionally contains a specific “role” >>> attribute (e.g., “accredited vet”). The process for issuing/revoking such >>> certificates involves the authority (e.g. https://www.anzcvs.org.au/ ), >>> which must interact with the CA. The interaction with the CA is a critical >>> point, especially when the vet loses his qualification: the authority >>> should inform the CA, and the CA should revoke the certificate. This >>> process is CA-centric and inefficient. >>> >>> >>> >>> The use of external existing oracles, as recommended by Adrian, is >>> certainly a valid option. The issue here is obviously that the verifyer has >>> to be oracle-aware, and implement as many oracle integrations as there are >>> oracles. >>> >>> >>> >>> There is now a lot of interest on “trust frameworks”, as a set of tools >>> to support the verifier. I’ve seen different approaches, from those based >>> on linked credentials to those based on external infrastructures (e.g., DNS >>> like in lightest.eu or centrally managed like in >>> https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0430-machine-readable-governance-frameworks). >>> Applicability to IOT (where automatizaion is paramount) appears to be >>> relevant. >>> >>> >>> >>> I believe this will be a field of growing interest. I am very interested >>> in hearing of other views. >>> >>> >>> >>> Best, >>> >>> >>> >>> --luca >>> >>> >>> >>> >>> >>> *Da:* steve capell <steve.capell@gmail.com> >>> *Inviato:* giovedì 30 luglio 2020 02:21 >>> *A:* Adrian Gropper <agropper@healthurl.com> >>> *Cc:* W3C Credentials CG <public-credentials@w3.org> >>> *Oggetto:* Re: A question on best practices for dependent claims >>> >>> >>> >>> Hi Adrian, >>> >>> >>> >>> Thanks for that - a lot of common sense in there. And, yes, I think you >>> are right about not overwhelming existing trust chains with too much >>> digital change. >>> >>> >>> >>> I think it'll work fine for most use cases. We do have a few cases >>> where the register is not public (for example "Australian Trusted Traders" >>> - a kind of international supply chain accreditation granted after audit of >>> facilities and processes). But perhaps the simple solution for that is >>> just that the "convener" needs also to be trusted by the accreditation >>> authority and API access is authenticated. >>> >>> >>> >>> I really appreciate this response Adrian. And if anyone else has any >>> ideas to contribute, we are listening attentively and gratefully ;) >>> >>> >>> >>> kind regards, >>> >>> steve >>> >>> >>> >>> On Thu, 30 Jul 2020 at 09:32, Adrian Gropper <agropper@healthurl.com> >>> wrote: >>> >>> At least for medical, and maybe veterinary, practice the solution is not >>> as complicated as it would seem if we make best use of existing regulations >>> and practices. The problem arises when we try to overwhelm the existing >>> chains of trust with excess digital innovation. >>> >>> >>> >>> For example: >>> >>> - Licensed physicians have public credentials that can be used to >>> hold them accountable if their actions are logged in non-repudiable way. >>> - Because these credentials are public, it makes no difference how >>> they are held or even if they are published by an oracle like a state board. >>> - Many state and federal boards already offer APIs that can serve as >>> oracles. >>> - A simple DID credential that links an official oracle with the DID >>> can be self-signed or co-signed by a notary who also reviews a driver's >>> license. >>> - DID wallets can also support a non-repudiable digital signature at >>> least as good as the ink on paper ones. >>> - Paper signatures in medicine are often accepted by verifiers based >>> on "Trust On First Use" with out-of-band verification. >>> - Timestamping signatures on public blockchains is easy and may >>> almost be a commodity. >>> - Licensed physicians and verifiers are typically subject to records >>> retention regulations that combine with digital timestamps to close the >>> loop on non-repudiation and enforcement. >>> >>> In this example and many like it, the technology and standards related >>> to SSI are almost entirely in the control of the physician herself. Yes she >>> has to install a relatively simple DID wallet. Yes, she has to go through >>> the one-time credential issuance process. The economic benefit to the >>> physician of a self-sovereign professional identity pays off handsomely in >>> terms of not sharing power or revenue with hospitals that provide them with >>> an administrative identity. >>> >>> >>> >>> The oracles already exist and don't need to know about SSI or VCs. >>> >>> >>> >>> The last thing left is hosting the digital transaction that brings >>> patient and doctor together and gets the document timestamped. This >>> convener does have to be SSI-aware and trusted as an intermediary by the >>> patient, the doctor, and the verifier. Nice thing is, these conveners can >>> be almost anywhere and don't themselves need to keep any patient data >>> related to the transaction, limiting both security and privacy risks. >>> >>> >>> >>> Wouldn't this be the fastest way to gain mass adoption of SSI? >>> >>> >>> >>> - Adrian >>> >>> >>> >>> >>> >>> >>> >>> On Wed, Jul 29, 2020 at 6:37 PM steve capell <steve.capell@gmail.com> >>> wrote: >>> >>> Hi all, >>> >>> >>> >>> I'm hoping some of you will have some sage advice for me on how best to >>> handle a common pattern that we need to solve here in Australia. The >>> generalised case is that a certificate (ie credential) issued by X has >>> little value to verifier Y unless backed up by an accreditation (ie >>> credential) issued by recognised authority Z that says X is authorised to >>> issue this type of claim. Some real world examples >>> >>> - Business identity ABN123 issues a claim that a consignment of wine >>> is genuine penfolds. But without another claim from IP Australia that >>> ABN123 is the holder of trademark "Penfolds" then it's of little value. >>> - Veterinary surgeon John Smith issues an animal health certificate >>> about snoopy the dog. But without a supporting claim from >>> https://www.anzcvs.org.au/ that john smith is an accredited vetinary >>> surgeon, the certificate is useless. >>> - And there are hundreds of others.... >>> >>> Some initial thinking >>> >>> - If these are totally separate credentials then there is a problem >>> with identity linking. The subject of one claim (john smith is a vet) must >>> be identical to the issuer of the other claim (snoopy is healthy). even if >>> the identifiers are the same, there are lots of john smiths in the world so >>> how to be sure that the one issuing the cert about snoopy is the one that >>> was accredited? Does John smith first create a self-sovereign identity and >>> get https://www.anzcvs.org.au/ to issue the claim to that identity? >>> - Another approach is that the accreditation authority runs a >>> service that counter-signs each certificate. so john issues the health >>> cert and then authenticates to https://www.anzcvs.org.au/ and gets >>> it counter-signed. the verifier can trace the authority through a single >>> health certifiate. This implies some real-time infrastructure capability >>> on the part of all accreditation authorities that might be a bit >>> impractical. >>> - Another is that the accreditation authorities maintain public >>> lists of accredited identities via some public ledger protocol. verifiers >>> can check the issuer id in the health claim and then check the public list. >>> Maybe the lists need to be anonymised via some kind of zero knowledge >>> proof. >>> - and so on... >>> >>> Looking for best practice advice that is both cryptographically secure >>> and practical to implement for large number of accreditors and certifiers. >>> >>> >>> >>> Thanks in advance! >>> >>> >>> >>> -- >>> >>> Steve Capell >>> >>> +61 410 437854 >>> >>> >>> >>> >>> >>> >>> -- >>> >>> Steve Capell >>> >>> >>> >> > > -- > > Stephen Curran > Principal, Cloud Compass Computing, Inc. (C3I) > Trustee, Vice Chair - Sovrin Foundation (sovrin.org) > > *Schedule a Meeting: **https://calendly.com/swcurran > <https://calendly.com/swcurran>* > > -- Stephen Curran Principal, Cloud Compass Computing, Inc. (C3I) Trustee, Vice Chair - Sovrin Foundation (sovrin.org) *Schedule a Meeting: **https://calendly.com/swcurran <https://calendly.com/swcurran>*
Attachments
- image/png attachment: image001.png
Received on Thursday, 30 July 2020 17:27:50 UTC