W3C home > Mailing lists > Public > public-credentials@w3.org > December 2019

Re: DIDs available by satellite. A curiosity, an exploration.

From: Tedesco, Evan <Evan.Tedesco@dish.com>
Date: Tue, 3 Dec 2019 23:20:43 +0000
To: Brent Shambaugh <brent.shambaugh@gmail.com>, Sam Mathews Chase <samantha@venn.agency>
CC: Credentials Community Group <public-credentials@w3.org>, Mike Lodder <mike@sovrin.org>, Wolf McNally <wolf@wolfmcnally.com>, David Hoffman <dhoffman32@gmail.com>
Message-ID: <1575415243420.73291@dish.com>
​I work for Dish wireless(we work closely with Echostar & Hughes net among others).  I have been noodling on resolving DIDs via satellite for a while now as a solution for getting Identity access to the less fortunate regions and here is my $.02 on it.


1) To really be able to resolve DIDs globally via Satellite you would need the associated (non-terrestrial)spectrum licenses to transmit the packets.


2) While Yubikey would be a good solution I feel it is cost prohibitive for most the populations that need this type of access(full disclosure: I didn't watch the use cases for offline credentials so I may be off the mark here).  I really like the Idea of using a javacard(chip and pin tech) at least for the underprivileged it is a lot more accessible.  I also Saw Gemalto has these: https://www.gemalto.com/financial/cards/emv-biometric-card​ which are chip and pin with fingerprint identification(biometric stored on the card).  I think this would be the most cost effective approach as you would only have to fit the POS systems with radios for backhaul.  Also because access to electricity is often scarce in these regions, it makes sense for the device to be powered by the POS terminal.





________________________________
From: Brent Shambaugh <brent.shambaugh@gmail.com>
Sent: Tuesday, December 3, 2019 1:27 PM
To: Sam Mathews Chase
Cc: Credentials Community Group; Mike Lodder; Wolf McNally; David Hoffman
Subject: Re: DIDs available by satellite. A curiosity, an exploration.


 This message originated outside of DISH and was sent by: public-credentials-request+bounce-evan.tedesco=dish.com@listhub.w3.org

Hi Sam,s

I met Jim Cantrell from Stratspace in Tuscon recently. We have known each other for awhile, and get along well. We both have engineering backgrounds.
He was involved with both generations of the Iridium Network [1],[2]. I also have been in touch with Kim Hamilton Duffy. She is up for updates and
I assume amusements, but she is quite buried.

I ordered a RTL-SDR. I might also get an Hack-RF clone. The RTL-SDR website looks like a great place to start [3],[4]. This will require
a bit of a struggle.

Blockstream is a free service worth tinkering with. They have their satellites in geosynchonous orbit which is unlike Iridium's closer
orbits.

I'm guessing that it would be better to follow an Iridum kind of thinking to minimize device size. It is not rational to expect
people to carry around bulky hardware if they are going to replace their wallet and perhaps a Yubikey(TM). I believe you
said something somewhere agreeing with this.

The video that I linked to was Daniel Hardman's talk on Peer DIDs [5]. I'm sure you will also like the did:key method talk discussed
in today's call. Perhaps it could help move Critical Use Cases for Offline Credentials forward?

I may have some overlap with the Verifiable Driving Event Data Chain in your RWoT Barcelona paper.

Tyler Ruff's Verifiable Credentials 101 talk helps a lot with understanding how Issuer, Holder, and Verifier play together [6].

I am not sure how public keys, DIDs, and DID documents play together. Is it possible to get a DID document from decoding the base58 string?
What is the relation of the DID and public key?

"Creating a did:key value consists of creating a cryptographic key pair and encoding the public key using the format provided in Section 2. The did:key Format<https://digitalbazaar.github.io/did-method-key/#format>. The creation of a DID Document is also performed by taking the public key value and expanding it into DID Document. An example is given below that expands the ed25519 did:key did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH into its associated DID Document" [6]

What about a verifiable credential that only needs to see a public ledger if it has not been seen before or is not in the "database"?


[1] ,[2] : https://www.iridium.com/, https://www.nasaspaceflight.com/2018/03/iridium-next-5-satellites-spacex-falcon-9<https://www.iridium.com/>
[3],[4] : https://www.rtl-sdr.com/talk-decoding-data-from-iridium-satellites/, https://www.rtl-sdr.com/rtl-sdr-tutorial-receiving-noaa-weather-satellite-images/
[5] : https://ssimeetup.org/peer-dids-secure-scalable-method-dids-off-ledger-daniel-hardman-webinar-42/
[6] : https://digitalbazaar.github.io/did-method-key/#create

-Brent

On Sat, Nov 30, 2019 at 12:38 AM Sam Mathews Chase <samantha@venn.agency<mailto:samantha@venn.agency>> wrote:
Hi Brent!

My company, Venn.Agency is a permanent contractor of Seaspan ULC and the Vancouver Shipyards. We are currently rolling out our verifiable safety training focused on emergency response and fire safety. The risk of fire to a vessel or ship build is the number one thing keeping Lloyd's Actuaries up at night. We're working to establish a new risk category in which everyone who enters a vessel or works in the shipyard has gone through our active simulation training and learned important safety information. We're maintaining an occupancy percentage over a set threshold which issues a "Certificate of Recognition" COR<https://www.worksafebc.com/en/health-safety/create-manage/certificate-recognition> [equivalent] Credential to BC Gov's Orgbook.<https://orgbook.gov.bc.ca/en/home> Kim Hamilton Duffy has designed our system's architecture and can offer more insight if you have specific questions.

The thing I myself most worry about is how freakin' easy it is to hack a big ship... or a tank for that matter 😳
I co-authored a paper with Wolfe McNally and Michael Lodder (on cc) at Rwot Toronto outlining Critical Use Cases for Offline Credentials.<https://nbviewer.jupyter.org/github/WebOfTrustInfo/rwot7-toronto/blob/master/final-documents/offline-use-cases.pdf>
On Satcoms, there are very narrow bandwidths for encryption and unfortunately, on top of that, a lot of passwords are password. Pentest Partners <https://www.pentestpartners.com/security-blog/sinking-container-ships-by-hacking-load-plan-software/> do a lot of good work exposing vulnerabilities and associated risk in ships and satcoms more broadly.

It is my personal belief, that focusing technical solutions and early adoption towards critical infrastructure (government, workforce data providence and privacy, heavy industry/high-risk safety and environmental compliance, etc) is the best way to make lasting change. I welcome you, (and anyone else on this thread) to comment- offer some insights, corrections, or alternate points of view on our soon to be published Rwot Barcelona paper: Driving Adoption with a Focus on Safety, Security & Compliance.<https://docs.google.com/document/d/1E-yJ5LJDCwE3yOD-U7Q5Yz2GyI2-hgk33IiZ80JalUU/edit?usp=sharing>

I'm keen to know who else is working in or near these use cases? Currently, historically, hypothetically or all of the above!

Also, the link to your video is dead. Can you recover it for me?


Sam Mathews Chase
Founder, Venn.Agency
-------------------------------------------------------
Move Slow and Fix Things.
-------------------------------------------------------
samantha@venn.agency<mailto:samantha@venn.agency>


On Fri, Nov 29, 2019 at 1:10 PM Brent Shambaugh <brent.shambaugh@gmail.com<mailto:brent.shambaugh@gmail.com>> wrote:
To whom it may concern:

I have been wondering: Would it be useful to work on a solution that makes DIDs resolvable anywhere on the surface of the earth with Satellites?

It does not seem broadband is needed, and when studying DIDs it seems like only a small part of the time does one need to verify a DID for a particular identity [1].

[1] "Peer DIDs: a secure and scalable method for DIDs that's entirely off ledger" https://www.youtube.com/watch?v=d-5MmLLd3x

Thanks for your time,

Brent Shambaugh
Received on Tuesday, 3 December 2019 23:21:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:19:06 UTC