Re: A question on best practices for dependent claims

Hi all

After a long delay this is just to say thank you all for your insightful
comments.

For the cross-border document use case (notably certificates of origin) our
short term solution is the "oracle as issuer" model where the exporting
regulator issues the VC on request by the identified and authorised
issuer.  It's not exactly the fully decentralised model that would be the
ideal end-state but in the short term it provides a simple way for the
verifier to assess trust and for the issuer to avoid technical complexity
(ie just get the oracle to do it).

I think the next step will be to separate this into two VCs - one which is
the actual trade document and the other is the role assertion of the issuer
by the oracle.  That is a better separation of responsibilities but imposes
a bit more work on the verifier and on the issuer.  Like any significant
transition from current state to future state, it's often better to take
little steps than giant leaps.

Rebuttals welcome ;)

kind regards,
steve

On Sat, 1 Aug 2020 at 11:01, steve capell <steve.capell@gmail.com> wrote:

> yes of course - you are right.  it would be quite reasonable to call it a
> high volume edge case ;)
>
> On Sat, 1 Aug 2020 at 10:54, <steve.e.magennis@gmail.com> wrote:
>
>> Btw ‘specific use case’ <> ‘edge case’, but point taken.
>>
>>
>>
>> *From:* steve capell <steve.capell@gmail.com>
>> *Sent:* Friday, July 31, 2020 5:48 PM
>> *To:* steve.e.magennis@gmail.com
>> *Cc:* daniel.hardman@evernym.com; Luca Boldrin <luca.boldrin@infocert.it>;
>> Adrian Gropper <agropper@healthurl.com>; W3C Credentials CG <
>> public-credentials@w3.org>; Chris Gough <chris.gough@gosource.com.au>;
>> Roman Evstifeev <someuniquename@gmail.com>; Richard Spellman <
>> richard.spellman@gosource.com.au>
>> *Subject:* Re: A question on best practices for dependent claims
>>
>>
>>
>> just to give you a feel for the scale of this "edge case" issue.
>>
>>
>>
>> The world bank together with partner UN agencies maintain statistics on a
>> thing called the "cost of trade"-  its complex stuff but can be simplified
>> to roughly the ratio of price of the thing at the warehouse door of the
>> distributor in an importing nation - over the price of the same thing at
>> factory door of the producer in the exporting nation. So, for example, the
>> cost of trade would be 100% if you can buy a sack of potatoes at the farm
>> gate in USA for $10 but the same sack of potatoes costs $20 from the
>> distributor warehouse in china (for the example of potatoes exported from
>> Us to china).
>>
>>
>>
>> Globally the average cost of trade between all nations hovers at around
>> 90% for manufactured goods and 150% for agricultural goods.  Obviously it's
>> a super-critical number when reduced to specific bilateral pathways because
>> it has a huge impact on the relative competitiveness of national produce in
>> export markets.  For example is USA-CN cost of trade is 120% but EU-china
>> cost of trade is 80% then EU producers are significantly advangated.
>>
>>
>>
>> the (very) interesting question is - how does this 100% average cost of
>> trade break down?  where are these costs?  Of course the answer is specific
>> to particular trade lanes but on average it's something like:
>>
>>    - 40% is distributor markup (ie profit int he supply chain)
>>    - 30% is the actual cost of transport
>>    - 30% is border costs.
>>
>> what is even more interesting is that, of that 30% border costs, on
>> average, only around 10% is duty.  So the other 20% are "non-tariff
>> barriers" like the paper certificates I described.  Now when you realise
>> that international trade accounts for around 20% of world GDP then this 20%
>> is a LOT.  world GDP currently stands at $80Tn USD.  So international trade
>> is maybe a bit under $20Tn (including the cost of trade).  So these
>> non-tariff border costs add up to at least $1Trillion.
>>
>>
>>
>> not an edge case I think....
>>
>>
>>
>> On Sat, 1 Aug 2020 at 10:17, steve capell <steve.capell@gmail.com> wrote:
>>
>> Hi Steve,
>>
>>
>>
>> "except maybe with very specific use cases, at which point you probably
>> already have sufficient a-priori knowledge that a verifier wouldn’t need to
>> go (much) beyond the issuer to determine if they trust the issuer or not"
>>
>>
>>
>> My main use cases are in international trade and specifically where the
>> issuer is in the exporting country and the verifier is in the importing
>> country.  And pretty much ALL of my use cases are therefore of the "very
>> specific" kind that you indicate may be an unusual edge-case.  My view is
>> that they are certainly not unusual - they are an every day occurrence at
>> volumes that make your eyes water.
>>
>>
>>
>> For example - lets get specific with two very common kinds of
>> certificates.
>>
>>    - A "preferential certificate or origin" is a document issued by an
>>    authorised body in the exporting country (in USA, one of 7000 chambers of
>>    commerce) that attests that the goods in a specific shipment (identified
>>    with a consignment number and/or invoice number) conform to the terms of
>>    free trade agreement.  Crucially, the verifier is  the customs authority in
>>    the importing country who will decide whether they believe the (currently
>>    mostly paper / wet seal) certificate is valid. If so then the importer is
>>    granted preferential duty rates.  Note that a certificate of origin must
>>    accompany EVERY shipment.  It's not a multiple use license, it is a single
>>    use certificate.  Obviously there are literally millions of them issued
>>    every day around the world.  They are a burden (is a non-tariff barrier) on
>>    trade.
>>    - A "phytosanitary certificate" is a document issued by an accredited
>>    person (a qualified food health inspector) in the exporting country that
>>    attests that the plant material (there are different certificates for
>>    animal products) meet the quality criteria of the importing jurisdiction.
>>    There are complex rules maintained by most exporting nations about exactly
>>    what kind of phyto certificate is needed by which country for which
>>    category of plant based material.  Just search through this for a bit to
>>    see what I mean -
>>    https://micor.agriculture.gov.au/Plants/Pages/default.aspx.  that's
>>    just for plants - there are five other categories.  The actual certificates
>>    are issued by accredited persons - in Australia they are called "Australian
>>    Authorised Officers" - to become one, you go through this process
>>    https://www.agriculture.gov.au/export/controlled-goods/plants-plant-products/ao.
>>    there are around 700 officers in australia. The department maintains a list
>>    of accredited officers at
>>    https://www.agriculture.gov.au/export/controlled-goods/plants-plant-products/ao/register as
>>    a set of state level pdf documents.  Like certificates of origin,
>>    phytosanitary certificates are single use and so there are also millions
>>    issued all the time and they also present a non-tariff barrier to trade and
>>    also a high entry barrier to export markets for domestic SME food producers.
>>
>> Now, back to your "specific" case.  The verifier in the importing country
>> (who often doest speak english) cannot be expected to know that a
>> particular chamber (of hundreds) or authorised officer (of hundreds) is
>> accredited or not. very often they are legislatively obliged not to trust
>> these random claims. However, under the terms of Free Trade Agreements etc,
>> most importing customs authorities will trust the exporting regulator to
>> assert the veracity of a digital version.  It's not often actually done
>> which is why the majority of these millions of daily certificates are still
>> paper and why they are often faked.  Also it's not uncommon when there is
>> either some corruption at the border or some greater political tension
>> between nations, that an importing authority customs officer will reject a
>> valid certificate - to make a point or to get paid some rort. These use
>> cases are crying out for a high integrity digital equivalent where fakes
>> are hard to make and valid ones cannot be refuted.
>>
>>
>>
>> So these very specific use case do require a chain of trust between the
>> issuer (who is definitely unknown and untrusted by the verifier) and the
>> accreditation authority (who is almost always some agency of the exporting
>> government and so is known and trusted by the verifier - often legislated
>> in the FTA).
>>
>>
>>
>> Our solution to this problem if digitising certificates has two phases
>>
>>    1. a single central government site (portal) has the job of
>>    registering, identifying, and authorising domestic issuers of certificates
>>    (eg chambers and authorised officers). It'll include manual or
>>    semi-automated checks against public lists like those PDF docs from the
>>    department of agriculture. Idetity would be confirmed via national ID
>>    frameworks such as myGovID in Australia.  Then this authorised issuer loads
>>    their certificate and the site wraps it in a VC and notarises it to a
>>    public ledger - puts a QR code on the cert.  The importing authority
>>    customs officer can scan the QR code and will see a ".gov.au" domain as the
>>    issuer and so trusts it.  The scan returns also the original ceritificate
>>    as issued so it can be compared against the one provided by the importer -
>>    thereby preventing just sticking the genuine QR on a fake cert.  This is a
>>    "semi distributed, semi digital" model that basically still has the human
>>    readable certificates - just that they can be send as a PDF in an email
>>    attachment (avoiding the whole original document, wet seal, fedex bag
>>    stuff) and also cannot be unreasonably refuted at the border.
>>    2. the above scenario still has a lot of centralisation in it and not
>>    much machine automation - but still adds a lot of value. The next phase is
>>    what has been driving my questions to this WG.  In that phase, the
>>    certificate data is JSON and there are two VCs - one issued to the
>>    certifier (ie chamber or AAO) by the government - it's a certificate of
>>    accreditation.  the other is the actual certificate of origin or
>>    phyosanitary certificate issued by the authorised entity.  They will need
>>    to be identity linked - possibly via a DID representing the authorised
>>    entity.  Both certificates are provided in native digital form, maybe via a
>>    G2G channel called a "secure trade lane" or otherwise via any B2B2G
>>    channel.  The VCs are verified by the importing regulator system so that
>>    the corresponding consignment can be auto-cleared (at least from an
>>    origin criteria and food health perspective).
>>
>> Phase 2 above is what we'd like to do following best practices in the DID
>> / VC / DIF world - hence my original question.
>>
>>
>>
>> kind regards,
>>
>> steve
>>
>>
>>
>>
>>
>> On Fri, 31 Jul 2020 at 23:59, <steve.e.magennis@gmail.com> wrote:
>>
>> … upon further refection.
>>
>> Having a verification process that checks the issuer of a VC so the
>> verifier can determine if they trust them,
>>
>> and if they do not then checks the whoever accredits / authorized /
>> certified the issuer so the verifier can determine if they trust them
>>
>>                 and if not, checks the whoever accredits / authorized /
>> certified them, etc.
>>
>>
>>
>> Is interesting and has a nice recursive symmetry, but would also require
>> that Accreditation / authorization / certification VC’s be issued at all
>> levels starting at the top and somehow chained down to the issuer. At this
>> point of market maturity that seems like a pretty unlikely think to happen
>> except maybe with very specific use cases, at which point you probably
>> already have sufficient a-priori knowledge that a verifier wouldn’t need to
>> go (much) beyond the issuer to determine if they trust the issuer or not.
>>
>>
>>
>> Would welcome use cases that show I’m thinking about this incorrectly.
>>
>>
>>
>> -S
>>
>>
>>
>> *From:* steve.e.magennis@gmail.com <steve.e.magennis@gmail.com>
>> *Sent:* Thursday, July 30, 2020 6:54 PM
>> *To:* daniel.hardman@evernym.com
>> *Cc:* 'Steve Capell' <steve.capell@gmail.com>; 'Luca Boldrin' <
>> luca.boldrin@infocert.it>; 'Adrian Gropper' <agropper@healthurl.com>;
>> 'W3C Credentials CG' <public-credentials@w3.org>
>> *Subject:* RE: A question on best practices for dependent claims
>>
>>
>>
>> Agree, but I think Steve C. presents an interesting nuance that intrigues
>> me. Defining acceptable authority or creating white lists implies an
>> a-priori perspective of what a verifier would consider acceptable. Here, I
>> think, the situation is that even if an assurance is unacceptable at one
>> level, if the chain of assurance can be followed to the entity at the next
>> level up … and that entity is acceptable then the verifier could be OK with
>> it. Of course a verifier could always set the minimal level of acceptance
>> to be the top most level (e.g. government or other well know body) and be
>> assured that they wouldn’t reject anything unnecessarily, but that would be
>> heavy handed. Maybe there can be a dynamic nature to setting the threshold.
>>
>>
>>
>> *From:* Daniel Hardman <daniel.hardman@evernym.com>
>> *Sent:* Thursday, July 30, 2020 4:33 PM
>> *To:* Steve Magennis <steve.e.magennis@gmail.com>
>> *Cc:* Steve Capell <steve.capell@gmail.com>; Luca Boldrin <
>> luca.boldrin@infocert.it>; Adrian Gropper <agropper@healthurl.com>; W3C
>> Credentials CG <public-credentials@w3.org>
>> *Subject:* Re: A question on best practices for dependent claims
>>
>>
>>
>> Aries RFC 0430 ("Machine Readable Governance Frameworks")
>> <https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0430-machine-readable-governance-frameworks/README.md>
>> contemplates this question and answers it by saying that any governance
>> framework can answer the question by a DIF-style presentation definition,
>> an Indy proof request, or some other demand for proof. That is, the gov fw
>> can say, "Trust any university that can present a credential issued by DID
>> X, showing that they're accredited." Or the gov fw can say, "Trust any DID
>> in the following list." Or lots of other variations.
>>
>> The thinking is that software "installs" or "activates" a gov framework.
>> A user might get prompted: "Do you want to use trust rules about how
>> universities are accredited, as codified by Org X?" Saying yes activates
>> the gov framework for all proving contexts that identify that gov
>> framework, going forward. Once the user says yes, the software reads the
>> rules that tell how an org becomes trusted to be an issuer or a verifier,
>> and automatically challenges other parties to prove their bona fides on
>> behalf of the user.
>>
>>
>>
>> On Thu, Jul 30, 2020 at 5:05 PM <steve.e.magennis@gmail.com> wrote:
>>
>> Actually, these are exactly the type of use cases I think are important
>> to get on the radar of the WG to challenge our thinking. In your Sarah Doe
>> example, as I understand it the department of public health in Australia
>> accredits inspectors directly, so the chain is pretty short: the validator
>> is either comfortable with the assurance of the government or is not. In
>> other scenarios a verifier might have to continue farther up the chain to
>> reach an institution they know or are comfortable with.
>>
>>
>>
>> -S
>>
>>
>>
>> *From:* Steve Capell <steve.capell@gmail.com>
>> *Sent:* Thursday, July 30, 2020 3:10 PM
>> *To:* steve.e.magennis@gmail.com
>> *Cc:* Luca Boldrin <luca.boldrin@infocert.it>; Adrian Gropper <
>> agropper@healthurl.com>; W3C Credentials CG <public-credentials@w3.org>
>> *Subject:* Re: A question on best practices for dependent claims
>>
>>
>>
>> Thanks steve, I will have a look at toip
>>
>>
>>
>> “ 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.”
>>
>>
>>
>> It’s certainly true that, as a verifier, I really don’t need the trust
>> chain to price accreditation if the issuer itself is already well known (eg
>> Oxford / Harvard).  But most o our use cases are not like that.  It’s not
>> general public knowledge (although often publically accessible ) that
>> Australian business 78 145 321 320 is the trademark owner of lindemans
>> wine.  Or that John Smith is an accredited vet.  Or that Sarah doe is an
>> authorised officer that is accredited for food safety inspections - and so
>> on.  These are our main use cases
>>
>> Steven Capell
>>
>> Mob: 0410 437854
>>
>>
>>
>> On 30 Jul 2020, at 11:50 pm, 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.
>>
>>
>>
>> <image001.png>
>>
>>
>>
>>
>>
>> *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
>>
>>
>>
>>
>>
>>
>> --
>>
>> Steve Capell
>>
>>
>>
>>
>>
>>
>> --
>>
>> Steve Capell
>>
>>
>>
>
>
> --
> Steve Capell
>
>

-- 
Steve Capell