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

We’ll need to figure out a GDPR compliant solution 

But on the other matter of presenter verification I think it’s a feature not a bug.  That’s because cross border credentials like certificates of origin change hands several times from issuer to verifier 

- eg chamber (issuer)-> exporter -> forwarder -> importer -> broker -> regulator (verifier).  

Can’t assume all parties along that path have cryptographically linked dids 

Or am I missing something?

Steven Capell
Mob: 0410 437854

> On 22 Dec 2020, at 9:01 pm, Steve Capell <steve.capell@gmail.com> wrote:
> 
> 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 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>
>> Datum: maandag 21 december 2020 om 16:21
>> Aan: Bill Claxton <williamc@itr8.com>
>> CC: Arshad Noor <arshad.noor@strongkey.com>, "W3C Credentials CG (Public List)" <public-credentials@w3.org>
>> Onderwerp: Re: OpenAttestation (was Re: looking for a specific use-case)
>> Opnieuw verzenden - Van: <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> wrote:
>> 
>> Arshad,
>> 
>> OpenAttestation was an underlying component of OpenCerts.  You may find this paper 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 uses an .io top level domain.  Not sure about the choice of .com over .org for OpenAttestations.
>> 
>> Regards, Bill Claxton (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/> 
>> 
>> Used by 
>> 
>> 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/> (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> 
>> 
>> 
>> 
>> Steven Capell 
>> Mob: 0410 437854 
>> 
>> 
>> On 19 Dec 2020, at 11:51 pm, Arshad Noor <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>
>>  
>>