You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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/>[email protected]
Agent ->> W3: access/authorize
Note right of Agent:🎟<br/>with: did:key:zAgent<br/>as: did:mailto:[email protected]
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
Loading
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:[email protected] (without ./update proof) we could respond with user interaction which could take
The text was updated successfully, but these errors were encountered:
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:[email protected]
(without./update
proof) we could respond with user interaction which could takeThe text was updated successfully, but these errors were encountered: