Devcon Flow that shows how attestation token + identifier attestation works for Hotel Bogotá (3rd party website)

Usecases
1

Result of last TokenScript meeting.

U = Ticket Recipient

DT = Devcon Ticket Site

AID = identifier attestation issuer (attestation.id)

TPS = Third-party website (bogota.hotel)

BLS = Browser Local Storage

EP/CA = explicit permission or capability attestation

Flow to create attestation (need negotiator+authenticator on DT)

  1. Devcon website (after user paid for the ticket) generate a ticket attestation -> magiclink
  2. U receives magicLink with email, clicks it
  3. DT opened, ticket saved in the BLS
  4. DT opens AID in iframe and ask for matching identifier attestation;
  5. AID asks for EP/CA
  6. AID returns result by checking AID's BLS.
  7. if none found, the AID asks for identifier (if not provided already - in devcon case provided in magic link);
  8. sends (by email or SMS) an OTP to the identifier ( for example "Please check your email to get the OTP" )
  9. U types the OTP and signs it with Metamask and send signature to AID.
  10. AID creates identifier attestation+secret, save it in AID's BLS, send "SUCCESS" to DT.

For DEVCON_6, step 3, 5, 6 are simplified;

3 -> simplified with hardcoded domain name 5,6 -> implement proper logic later when devcon ends. The entire magic link is sent to AID instead;

TPS = Third-party website (Hotel Bogota) TPS need to install negotiator npm module

  1. with the negotiator, TPS opens iframe to DT and requests DT for tickets list with EP/CA
  2. DT iframe answers with list
  3. negotiator returns promise with the list of tokens the user allowed to use on TPS
  4. later, TPS requires the token to be authenticated (i.e. user is in booking confirmation). when that happens:
  5. DT request AttestaionId for attestation+secret
  6. DT creates useTicket object and signs it
  7. DT sends signedUseTicket to TPS
  8. TPS sends signedUseTicket to the TPSBackendServer
  9. TPSBackendServer sends signedUseTicket to some AUTH_SERVER API for validation
  10. if AUTH_SERVER API answer valid then TPSBackendServer creates user session or add current user prmission to have Ticket benefits and send updated products list to the TPS

Total, what we need to install

  1. TPS - negotiator
  2. DT - [unspecified - up to the implementor @nicktaras
  3. TPSBackendServer need to know how to work with AUTH_SERVER API
  4. AUTH_SERVER API (nodejs or Java for now)
  5. update Attestation.Id to work with magic link through postMessages only without UI

Devcon_modules-relationship
Devcon_modules-relationship1334×945 120 KB

2

Sorry I don't remember if we finalised how to handle the secret in the ticket, committing the ticket to its specific user's identifier. As far as I remember the identifier commitment is simply ignored and the ticket becomes a "bearer" ticket, always accepted by the AID flow. However, I remember we have discussed several approaches for this initial system. Here they are mentioned in decreasing order of security:

  1. The ticket is stored in BLS as part of the online purchasing.
  2. The secret becomes a seperate part of the magic link and is extracted in the webbrowser and stored in BLS.
  3. DT looks up the specific ticket and returns in to be stored in BLS once the magic link is clicked.

Item 1 has the usability issue that the ticket is locked to the browser where the purchase is made. Item 2 and 3 works well in this flow since the email is verified as a later part of the flow. So the secret can also be used to learn the identifier the ticket is assigned to.

Can someone please confirm that we go with the "bearer ticket" approach?

3

After talking with @olehhrib it got clarified that we go with item 2. I.e. the secret is contained in the magic link as a separate entity, which is extracted by DT one the user clicks the magic link. I.e. magic link = url + params: ticket, secret, email