RE: OpenAttestation (was Re: looking for a specific use-case)

I am not sure, but I think the argument is that what is not reversible/brute forceable today, may not have that property tomorrow.
And if that were to happen, you have no clue how far reaching the consequences are going to be.
The uncertainty of such consequences (i.e. the risk) is therefore very high.
Rieks

From: Steve Capell <steve.capell@gmail.com>
Sent: dinsdag 22 december 2020 11:02
To: Marnix.van.den.Bent@rabobank.nl
Cc: williamc@itr8.com; arshad.noor@strongkey.com; public-credentials@w3.org
Subject: Re: OpenAttestation (was Re: looking for a specific use-case)

A salted hash is considered private data ? Really? It’s not reversible and, thanks to salt, not brute force guesssble

Is there a cryptographic miracle that permits actual private data to be reversed out of a salted hash? Or is this a case of otherwise very sensible legislation gone a bit off the rails ?
Steven Capell
Mob: 0410 437854


On 22 Dec 2020, at 8:39 pm, Marnix.van.den.Bent@rabobank.nl<mailto:Marnix.van.den.Bent@rabobank.nl> wrote:

We used to collab with GovTech and Accredify for a short time to explore OpenCerts about a year ago. It’s a cool solution dedicated to easily verify certificates and also render them using the template of the issuing party. At that time they did have a centralized registry (https://docs.opencerts.io/docs/registry) but also the possibility to verify using DNS. We did see that there was no mechanism in place to verify the presenter (like we have signature proofs bound to CredentialSubject id), since they assume you’d identify yourself on the actual job interview for example. Also we found some GDPR complications; The OpenCerts can be issued in batches, results into one student having an OpenCert file containing hashes of other OpenCerts. Whilst it is very unlikely to reverse engineer the hash due to the salts, our government still treats it as personal data, even if it’s hashed. And we don’t have legal grounds to process those..

Kind regards,
Marnix van den Bent

+31 88 72 19312



Van: Steve Capell <steve.capell@gmail.com<mailto:steve.capell@gmail.com>>
Datum: maandag 21 december 2020 om 16:21
Aan: Bill Claxton <williamc@itr8.com<mailto:williamc@itr8.com>>
CC: Arshad Noor <arshad.noor@strongkey.com<mailto:arshad.noor@strongkey.com>>, "W3C Credentials CG (Public List)" <public-credentials@w3.org<mailto:public-credentials@w3.org>>
Onderwerp: Re: OpenAttestation (was Re: looking for a specific use-case)
Opnieuw verzenden - Van: <public-credentials@w3.org<mailto:public-credentials@w3.org>>
Opnieuw verzenden - Datum: maandag 21 december 2020 om 16:19

Interesting article bill

May well be correct for the use case you describe of Singapore’s education system.  But I think it needs to be updated to reflect current state for our cross border use:
- you talk about a central register of approved issuers, but there is no managed register of issuer identities.  The issuer ID is linked to their DNS.  abf.gov.au for example, which obviously needed no approval from Singapore
- you say that the certificate is stored in free text, but actually it is symmetrically encrypted using a one time password

One interesting question is how the subject (not the issuer) is identified.  Not a DID. Actually just a public domain identifier like a business registration number. I guess this is one of the core differences between open attestation and VCs.  I think this goes to the use case for tyres things in international trade. Unlike a VC style bearer token where the presenter is almost always the subject, these are rather more transactional credentials (eg a certificate of origin about a consignment of goods from an exporter) where the presenter is often (usually) not the subject.  Eg a certificate of origin pathway is issuer (chamber) -> subject (exporter) -> freight forwarder -> importer -> customs broker -> verifier (importing customs agent).  I don’t know (but willing to learn) how you’d practically make this work if each party in the chain needed to verify DIDs

Cheers

Steven Capell
Mob: 0410 437854



On 21 Dec 2020, at 11:26 pm, Bill Claxton <williamc@itr8.com<mailto:williamc@itr8.com>> wrote:
Arshad,

OpenAttestation was an underlying component of OpenCerts.  You may find this paper<https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/topics-and-advance-readings/Decentralising%20OpenCerts%20v2.md> that I co-wrote provides some history and establishes the rationale for creating it, and why we felt that many governments would do the same thing.  A lot of the recommendations in that paper have since been implemented and, as Steve said, there are plans to better align with the VC data model and use of DIDs.

The main page for OpenCerts<http://opencerts.io/> uses an .io top level domain.  Not sure about the choice of .com over .org for OpenAttestations.
Regards, Bill Claxton (williamc@itr8.com<mailto:williamc@itr8.com>)
Facebook, Skype, MSN, Yahoo, Twitter, Flickr or Gmail: wmclaxton
Voice, Text or Whatsapp: +65-9012-4327
On 12/21/2020 9:45 AM, Arshad Noor wrote:
I'm not sure I understand Steve.

The home page says "OpenAttestation is an open-sourced framework to notarise documents using the blockchain." But, I don't see any white-paper anywhere on:

- The business problem it solves; or
- Why existing schemes/technology do not solve the problem that necessitates the use of a new framework.

Does such a white-paper exist?

Thanks.

Arshad

P.S. Curious that an "open" framework would choose to publish its content on a commercial .com domain rather than the traditional top level domain for open-source projects: .org.


On 12/19/20 1:59 PM, Steve Capell wrote:


https://www.openattestation.com/ <https://www.openattestation.com/><https://www.openattestation.com/>

Used by

https://www.tradetrust.io/ <https://www.tradetrust.io/><https://www.tradetrust.io/> (A Singapore government site)

And by

https://igl.trade.np.cp1.abf.gov.au/ <https://igl.trade.np.cp1.abf.gov.au/><https://igl.trade.np.cp1.abf.gov.au/> (Au government - beta trial only)

Part of a UN collaboration described here https://uncefact.unece.org/pages/viewpage.action?mobileBypass=true&spaceKey=uncefactpublic&title=Cross+border+Inter-ledger+exchange+for+Preferential+CoO+using+Blockchain <https://uncefact.unece.org/pages/viewpage.action?mobileBypass=true&spaceKey=uncefactpublic&title=Cross+border+Inter-ledger+exchange+for+Preferential+CoO+using+Blockchain><https://uncefact.unece.org/pages/viewpage.action?mobileBypass=true&spaceKey=uncefactpublic&title=Cross+border+Inter-ledger+exchange+for+Preferential+CoO+using+Blockchain>



Steven Capell
Mob: 0410 437854



On 19 Dec 2020, at 11:51 pm, Arshad Noor <arshad.noor@strongkey.com><mailto:arshad.noor@strongkey.com> wrote:

What is this protocol, Steve? A search does not identify the protocol uniquely: https://duckduckgo.com/?t=ffab&q=singapore+open+attestation+protocol&ia=web


Thanks.

Arshad Noor
StrongKey

On 12/19/20 4:25 AM, Steve Capell wrote:


In our international trade domain I can’t think of a use case where we don’t need notarised and revocable credentials - things that don’t get much of a mention in the w3c specs.  It’s why we use the Singapore open attestation protocol
Steven Capell



======================================================
Rabobank disclaimer: http://www.rabobank.nl/disclaimer


<#rbnl#1898i>

________________________________
This email (including any attachments to it) is confidential, legally privileged, subject to copyright and is sent for the personal attention of the intended recipient only. If you have received this email in error, please advise us immediately and delete it. You are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. Although we have taken reasonable precautions to ensure no viruses are present in this email, we cannot accept responsibility for any loss or damage arising from the viruses in this email or attachments. We exclude any liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided in this email or its attachments, unless that information is subsequently confirmed in writing. <#rbnl#1898i>
________________________________


This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.