Re: A question on best practices for dependent claims

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