A digital business card for the people in an organisation

Tap & Play gives everyone at an organisation a card at a web address they can put on a badge, in a signature or behind a QR code. An organisation that connects its Google Workspace directory can add people from it and have a card taken offline within a day of that person leaving; one that does not connect a directory keeps its people by hand, and nothing here goes offline on its own.

What a card is

A card is one page at an address like https://acme.tapnplay.me/k9x4p. It can carry a person’s name, work email address, job title, department, office telephone number and extension, office location, photograph, mobile number, LinkedIn address, pronouns and a short description of what they do — whichever of those their organisation’s card settings include and they have filled in themselves.

Every card also offers the same details as a .vcf contact file, which a phone saves straight into its address book, and as a QR code that encodes the card’s own address. Both are generated from the card, so they cannot say something the card does not.

How somebody gets one

• There is no sign-up form here. We create the organisation, give it an address under tapnplay.me and name its first administrator.
• We add the people too — one at a time, or from a connected Google Workspace directory using an explicit list of named addresses, which reads only the addresses on that list. An organisation’s own administrators cannot add somebody themselves yet: there is no screen and no command for it on their side, so they ask us.
• The person signs in with their work Google account at their own organisation’s address and fills the card in themselves.

A card is private until somebody publishes it

A new card is not public. Until the cardholder or one of their administrators publishes it, its address answers exactly as an address nobody has — the same response, to the byte. That is deliberate: a card that has not been published yet, a card belonging to somebody who has left, and a name that was never used cannot be told apart from outside, so nobody can probe an organisation’s address to learn who used to work there.

What connecting a Google Workspace directory does

An organisation can connect its Google Workspace so that people can be added from the directory and their cards go offline when they leave, instead of both being done by hand. There are two ways a directory comes to be connected, and they differ in who grants the access, which credential holds it, and what disconnecting can take back.

Connect, on Google’s own screen

One of the organisation’s own administrators clicks Connect and approves a read-only directory permission on Google’s consent screen. On this route nobody opens the Google Admin console and nothing is copied and pasted. It is built and deployed but cannot be used yet: its setup on Google’s side is unfinished, and because Google classes the directory permission as sensitive it also needs Google’s review before any organisation but a pilot that trusts us by hand can use it.

Domain-wide delegation, arranged with us

The other route, and the only kind of directory connection running today. The organisation’s Google Workspace super administrator enters our service account’s client ID and that same single read-only scope in the domain-wide delegation screen of their own Google Admin console, and creates a dedicated account in their domain for us to read the directory as. We then configure it at our end with an operator command. There is no consent screen, nothing on the organisation’s own administration page sets it up, and the access rests on a private key of ours rather than on a credential belonging to that one organisation. The privacy policy says which credential that is, that it is shared by every organisation connected this way, and what disconnecting does and does not do to it.

What it does

• Reads under one directory permission and no other: admin.directory.user.readonly, read-only access to the user records in the directory. Connect asks for it on Google’s consent screen alongside Google’s two basic sign-in scopes, openid and email, which tell us which administrator is consenting; the delegation route asks Google for nothing on a screen at all and reads with the grant the organisation’s own super administrator made, for that same one scope.
• On the Connect route, requires a Google Workspace super administrator of one of the organisation’s own domains, and checks that again before every sync that could change anybody. An administrator who can only see part of the directory would make everybody outside their view look like a leaver. On the delegation route nothing here can check that, so it falls to us and to the organisation’s super administrator to give the account we read as a role covering the whole domain.
• Fills in two fields on a card when a person is added — full name and work email address — and neither is the cardholder’s to edit afterwards. Everything else on a card belongs to the cardholder.
• Runs a nightly check of the people it has already added, and takes a card offline when that account is suspended or gone from the directory. Nothing is deleted; reinstating the account brings the same card back at the same address, so printed codes keep working.
• Can be disconnected at any time from the organisation’s own administration page. That stops the sync on either route. On the Connect route it also withdraws the permission at Google; on the delegation route there is nothing for us to withdraw, and the grant stays until the organisation removes it in its own Admin console. The page says which of those has just happened.

What it does not do

• It never changes anything in the directory. The permission is read-only and every directory request is a read. The only request that changes anything at Google is the one that withdraws a Connect permission, when a directory connected that way is disconnected.
• No mail, no calendar, no files. The directory permission covers user records and nothing else, and beyond it and the two sign-in scopes above no Google permission is ever asked for.
• Adding people does not sweep the directory. People are added from an explicit list of addresses, looked up one at a time, and the nightly check reads only those same people. The permission does allow the directory to be listed, and the privacy policy names the two places where it is.
• It does not keep a name up to date on its own. A name and address are read when a person is added. If either changes in the directory afterwards, the card keeps what it has until somebody here runs that step again by hand; an automatic name sync is not built yet. Suspension and removal are what the nightly check looks for.
• It does not fill in the rest of the card. Job titles, telephone numbers, photographs and reporting lines are not taken from the directory.
• It does not sign anybody in. Connecting a directory grants no access to anything and admits nobody to the organisation.

What an organisation controls

• Which of a card’s fields are hidden from visitors, which are optional for the person whose card it is and which are required — ten of the fourteen fields, set by the organisation’s own administrators on their setup page. Full name and work email address are ours to fill in and appear on every card; hiding a field takes it off the card and out of the .vcf and deletes nothing anybody has already typed. A required field is marked as such in that person’s own card editor and asked for the next time they save it; no card already published is taken offline or emptied by the change.
• Who its administrators are.
• Publishing and unpublishing any card in the organisation.
• Whether a directory is connected at all, and disconnecting it — and where the connection is a domain-wide delegation, the grant in its own Google Admin console, which only the organisation can withdraw.

Where it runs

In Google Cloud in europe-west1 — St. Ghislain, Belgium: the application on Cloud Run, the database on Cloud SQL for PostgreSQL, and a load balancer in front for TLS. Configuration secrets are held in Secret Manager and replicated only to europe-west1 and europe-west4, never worldwide. The privacy policy says what is stored and for how long.

Where we have got to

Tap & Play is at pilot stage and this page describes only what is built and running today. One organisation is live, and its directory is connected by the domain-wide delegation route above, which an operator configures. Connect — the route where an administrator approves the permission on Google’s own screen — is built and deployed, but its setup on Google’s side is not finished, so nobody has used it yet; and because Google classes the directory permission as sensitive, we need Google’s review before any organisation other than a pilot that trusts us by hand can use it. This page and the privacy policy are part of applying for that review.

There is no pricing here, no self-service sign-up, and no mobile application. If you are considering Tap & Play for your organisation, write to us and you will be talking to the person who built it.

Talk to us

Who runs Tap & Play

PLACEHOLDER — the legal entity has not been decided yet

Address

PLACEHOLDER — no registered address yet

Privacy questions and support

tapnplay@falvey.net