Re: A question on best practices for dependent claims

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>*