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