standard

standard copied to clipboard

This pull request makes the following changes:

• Add an additional client protocol option of:accepts:anonymous that signals to client applications that authenticated requests are not required
• Add new optional tag of:context:$client_protocol that is true or false and specifies whether additional context (untrustedData fields that extend OpenFrames) are required for a particular $client_protocol. There is also an option to pass of:context:none that signals to client applications that there is no additional context required.

The motivation for this spec change is to allow frames to support "unauthenticated" and "optionally authenticated" sessions. This allows open frames to be displayed across a wider variety of client applications, and gives more flexibility to frames and applications to decide their requirements for displaying frames and policies for user privacy.

What are the advantages of allowing frames to specify their expected level of authentication?

There are a lot of frames where there isn't a strict requirement to verify the identity of the user such as photo galleries, single session games, or informational frames. These frames could have no use for authentication, they could implement an optional logged in experience (data tracking, saving sessions, etc.), or they could implement a requirement for an authenticated session.

1.) This spec allows Frames that do not require or optionally require authentication to be displayed across any client application that supports Open Frames, regardless of whether the application has a user logged into a session of a client protocol 2.) A frame that is designed to work with one client protocol can more easily be adapted to support other protocols by designating itself as optional 3.) Apps could introduce settings letting users specify to only interact with unauthenticated/optional frames to preserve privacy 4.) Removing unecessary signing and verifying of frame requests reduces latency

Isn't it always beneficial to use authenticated frame requests when possible?

Not really. Frame requests are not explicitly signed by the user. They are signed and sent in the background by the client application. The only clear advantage to using an authenticated request is that the frame server can verify the identity of a user performing the action is logged into a valid session for $client_protocol. The exact details of the request (button pressed, input text, etc.) are placing a similar level of trust in the client application as untrustedData.

Thanks for putting this together!

Agree that this is currently a big problem and that we should find a solution.

~I'm not the biggest fan of the suggested of:authenticated property as a solution because it allows inconsistent specs by decoupling the of:authenticated and of:accepts:$client_protocol tags.~

~For example, let's say that a developer sets up of:authenticated as false and of:accepts:lens is set. This seems to be inconsistent, and it's unclear which property should take precedence, and we'd need to document this.~

I think an alternative we could consider is an additional clientProtocol, of:accepts:anonymous, wherein it doesn't require any signature, and sends an empty trustedData. This wouldn't require making the other fields optional, nor adding the additional of:authenticated property, and keeps the spec simpler, while still achieving the same amount of expressiveness, in my opinion.

Let me know what you think!

edit: I misunderstood your suggestion, hence the strikethrough.

The downside of what I suggested is that the clientProtocol currently communicates both the signature scheme and the context in which the content is in, which is passed into the frame action. With a clientProtocol of anonymous, it's unclear which context is to be expected by the frame server.

The clientProtocol communicates two things currently; the required context of the content, and the required signature scheme. Your suggestion may make the signature optional, but it doesn't resolve the question of how a frame can communicate whether the clientProtocol context is optional, which is a separate problem but closely related and relevant for making frames that work everywhere without issues. Perhaps these two things could be decoupled, of:accepts:anonymous added for signatures and of:context:lens, of:context:xmtp, of:context:anonymous ... or something similar

Currently the of:accepts tag provides the following information to a client about the data that a server accepts:

1. encoding of the message bytes
2. frame context
3. authentication scheme

I don't necessarily see a use case for overriding the encoding, but perhaps we should introduce tags for overriding frame context and authentication scheme to be 'none' and 'anonymous' respectively. In cases where context=none and authentication=anonymous, the client can ignore the of:accepts tag.

Because these new tags would override defaults it would be backwards compatible with existing frames and clients. It also leaves room for frames/client protocols to support multiple different frames contexts (and potentially multiple authentication schemes)

@davidfurlong @stephancill Thanks for the feedback, I really like these suggestions. I updated the PR to make these changes:

• Remove of:authenticated and replace with of:accepts:anonymous option to designate a Frame as not requiring authentication.
• Add optional of:context:$protocol_identifier tag to specify whether context is "none" or true/false for specific client protocols.

I think these changes will give Frame and app developers a lot more flexibility on how to expose and integrate across multiple protocols. Let me know if you have any feedback on this approach. I'm going to run this by the XMTP team tomorrow to see if they have any thoughts and also think through some more scenarios this week to make sure this covers them all.

Gm! We want to move forward with adding of:accepts:anonymous and move the of:context bit to a separate discussion for the future. of:accepts:anonymous enables an ethereum equivalent to Blinks, via anonymous open frames that initiate transactions.

Perhaps we should also specify what exactly an anonymous and frame request looks like. For example what goes in the tag content attribute and what the frame server can expect to find in the post request body. To be more general we can maybe format it as 'a minimum viable frame' and 'minimum viable frames request'?

Perhaps we should also specify what exactly an anonymous and frame request looks like. For example what goes in the tag content attribute and what the frame server can expect to find in the post request body. To be more general we can maybe format it as 'a minimum viable frame' and 'minimum viable frames request'?

makes sense - I also think there's an opportunity to clarify the compatibility - for example xmtp clients can support of:accepts:anonymous frames even if those frames don't specify the of:accepts:xmtp tag