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

If hashes become reversible I think we are all dead in the water as all 
cryptography depends on the non-reversible property.

Furthermore, reducing an infinite data pool into a finite number of 
hashes means there are bound to be collisions, so reversibility can 
never be 100% guaranteed. (in fact there are theoretically an infinite 
number of data items that will create the same hashed value).

Kind regards

David

On 22/12/2020 10:19, Joosten, H.J.M. (Rieks) wrote:
>
> 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
>     <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/>
>                 <https://www.openattestation.com/>
>
>                 Used by
>
>                 https://www.tradetrust.io/
>                 <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/>
>                 <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>
>                 <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
>                     <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
>     <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.
>

Received on Tuesday, 22 December 2020 11:17:23 UTC