Re: A question on best practices for dependent claims

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