storacha-network / specs

🏅 Technical specifications for the w3up protocol stack
17 stars 0 forks source link

invocations that require user interactions #22

Open Gozala opened 1 year ago

Gozala commented 1 year ago

As I was updating account & space protocol specs I realized that there are at least few cases where it would make a lot of sense if handler could request user interaction.

For example in access/authorize flow we have an email based user interaction, where client is presumable waiting that user clicks an email.

sequenceDiagram
  participant Agent as 👩‍💻<br/><br/>did:key:zAgent
  participant W3 as 🌐<br/><br/>did:web:web3.storage #32;
  participant Email as 📬<br/><br/>alice@web.mail

  Agent ->> W3: access/authorize
  Note right of Agent:🎟<br/>with: did:key:zAgent<br/>as: did:mailto:alice@web.mail
  W3 ->> Email: ✉️ Verification email
  Email ->> W3: 🔗 Approve
  W3 -->> Agent: ./update
    Note right of Agent:🎫<br/>with: did:web:web3.storage<br/>key: did:key:zAgent

In this specific case application can anticipate user interaction and can communicate with a user ahead of time. However in some other cases e.g. in provider/add service MAY want to require user to accept terms of service or enter credit card info if card is only not on file.

It appears to me that instead of trying to go around user interaction flow, we might be better of embracing it in our design, which in turn could simplify some of our protocols. For example instead of denying request from did:mailto:alice@web.mail (without ./update proof) we could respond with user interaction which could take