3rd party Pack authentication: how should developers identify their packs to the integrated services and to users?

Making Packs
1

When a 3rd party pack attempts to authenticate itself with an integrated service, such as a Google product, how should the pack be identified to the service the user is connecting to? The name of the application, privacy policy, terms of service, support emails, home page, are all examples of information that is requested from the service provider when registering the pack as an app to enable authentication. It would be nice to have some guidelines put out by the Coda team that explain what developers should use when registering their pack as an app. For example, I would imagine that using the same values as the 1st party Coda packs is not a great idea, for legal and branding reasons.

How the pack is identified and registered on the integrated service’s end may influence the verification and auditing of the app with the service provider, and the user’s experience when authorizing access to potentially sensitive data (e.g. consent form for OAuth2).

I would envision that once the Pack publishing experience matures, publishing a pack that crosses the Coda system boundary would require some sort of auditing or stamp of approval from Coda before being made available to download via 1st party channels. If that is the case, then it would be nice to grant such verified packs some common guidelines that can be used (so long as they adhere and are verified to adhere to some TOS), for example a common application name (e.g. “Coda Verified Packs”), another set of privacy policy and terms of service, and maybe enforcing that the application home page be set as the Coda-hosted pack listing.

As it stands, it is somewhat unclear what values the app should take on, and it may create a confusing or worrisome experience to end users when leaving the Coda platform and having to authorize access to their data to unvetted developers with no relation to Coda. Not only that but it leaves developers wondering how to present a safe experience to users without infringing on Coda’s branding or legal. Having Coda verify the packs before being published would mitigate most of those concerns, and putting forth guidelines that developers would have to follow to make the consent forms displayed to users and the app registration with service providers consistent would improve the user experience.

Thoughts on this? Is this idea one that the Coda team is already considering?

1 Like
2

Hi @louca.developer - Thanks so much for raising this concern, and in the past I’ve found myself in a similar situation, struggling to figure out how to provide a TOS and what should be in it. To set expectations, we may be limited in how much guidance we provide developers, since these are legal documents. I’ll bring this topic up with the Packs team and see what kind of guidance we can provide.

2 Likes
3

I’m installing a pack and it wants a token. The ‘Generate new token’ wizard allows for a Pack type restriction, and wants a ‘Pack ID to grant access to’. Can this be used to limit the token’s access to just what the pack needs? How do I find this for the pack?

4

@Johg_Ananda - That’s a good question, but a bit unrelated to this particular topic. Perhaps ask again in a new topic?

1 Like