Thursday TokenScript weekly meeting was over-extended to 1.5 hours, and we still didn't get around to stuff the map system discussion. So I decide to write down what I would have said and take the weekly meeting to this forum.
My view initially I wished to share is that map-related features are not TokenScript features - GPS related ones are. My thinking of GPS in relationship to TokenScript is:
- GPS location or geofence can be set up as a context or trigger for TokenScript actions
- A website can obtain GPS location information (either of the current user or of the vehicle) through a token.
- GPS location can be used in authorisation.
- attested GPS location in authentication or getting authorisation
Let's talk about real-life use-cases:
location as trigger or context
Let's take a tokenised airline ticket as an example. Today, boarding is done by showing a QR code.
If you are not at the right time (3 hours before departure), at the right location (city and airport), the token wouldn't make the boarding action available. On the other hand, if you are in the right context, the boarding QR code can be shown directly in your user-agent (speaking of αWallet, the Wallet tab), automatically, as it's apparent that you want to use that action.
A more advanced usage is to use it as a trigger. Let's say you have an AirBnB token, therefore the token knows when and where are you going to show up. Even if your hands are occupied by luggage, you can open the lodging's door by simply walking into it. The action to open the door automatically triggered, which utilise Bluetooth to authenticate against a smart lock.
location for websites or integration with 3rd party
Let's take an example of someone with a car token. He logs in to a website called "Roadside Assistance" and the website asks for location.
Instead of asking for the user's location, it might ask the token to provide the location, therefore, the user could be at home - let's say, he got a phone call from the person driving his car that his car needs road-side assistance.
In the most advanced case, the token can hold a user's historical location data and use that to participate MPC in contact tracing organised by a 3rd party (Ministry of Health) who can't learn any of the user's travel history.
location used in authorising authorisation
A car workshop might get your authorisation to drive the car around, but not too far away from the car workshop. The workshop would request a car-key token with the GPS location of the shop plus a 100m radius around it.
Similarly, if you access the website "Roadside Assitance", the website might ask for your authorisation to your car's location for 24 hours. If you sign that authorisation, the website now can independently talk to your car and know it's the current location through that authorisation (which itself is a token).
location used in authentication or getting authorisation
This is used to prove to a service that the user is in a certain location. A wifi-based challenge-response can be signed by the blockchain-compatible wifi access point, which can be used to login to certain services or obtain certain attestation/tokens. This is useful in designing something like "Physical Presence Token" or encouraging fans to follow a movie star.
An advanced version can be used to satisfy transaction conditions (you can only buy this discounted XBOX if you physically present in the XBOX-conference)
What does it have to do with Google Map?
None of these location data use-cases requires TokenScript to do anything with map service providers. Not that I can think of.
- Should we provide rich location related directives in TokenScript to support these use-cases listed above? Yes.
- Should we provide directive in TokenScript to support a map to show a location obtained from a Token? My current thinking is No. For map use cases, TokenScript only needs to make sure location data is presentable to the upper layer in a recognisable format. It's up to the upper layer (application) to decide what to do with that data.
What's your thinking on this?