Re: A question on best practices for dependent claims

I worry that we’re setting up a false dichotomy between Issuers that
service Holders and those that service Verifiers directly (as oracles). See
https://github.com/w3c/did-core/issues/370#issuecomment-683075977 for a
proposal.

- Adrian

On Fri, Aug 28, 2020 at 7:45 PM steve capell <steve.capell@gmail.com> wrote:

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