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
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.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