I like the advantages of using ContentHandler (in particular, the change tracking and transparency). Private content could be a logged-action against the "page", possibly? "Jdforrester updated the application secret key for Fish" and so on?

That would probably work. Alternatively, ContentHandler::unserializeContent() could look up the secret key in the database and add it to the content object, and it could be written back in the database on PageContentSave.

my first impression is that ContentHandler would not be an improvement here

Based on your description, I think the main improvements would be a) not duplicating core features like revdel b) and providing "change tracking and notification".

content needs to be available cross-wiki as the authorization dialog could be displayed on any site

You could create a custom API module like EventLogging's action=jsonschema.

there would have to be some kind of pre-publication review workflow (something similar to how FlaggedRevs works)

This would still be an issue in the database table version right?

In T109156#1560868, @Legoktm wrote:

Based on your description, I think the main improvements would be a) not duplicating core features like revdel b) and providing "change tracking and notification".

Agreed, I think those are big advantages. I am just not sure that the disadvantages are not bigger.

content needs to be available cross-wiki as the authorization dialog could be displayed on any site

You could create a custom API module like EventLogging's action=jsonschema.

You mean that Special:OAuth would make a server-side call to the API on meta? How would that work exactly, given that this data is private, security-sensitive and needs to be writable cross-wiki (to store grants)? I would rather not have an API endpoint that's exposed to anyone - it could make it possible, for example, to escalate a local XSS vulnerability to an all-cluster, almost invisible, permanent backdoor to that user.

there would have to be some kind of pre-publication review workflow (something similar to how FlaggedRevs works)

This would still be an issue in the database table version right?

Yes, but I imagine it would be a lot easier to do that with custom tables. I am a bit afraid of ending up with something unmaintainable like FlagRev. Maybe only dealing with a content type we own and/or not having to deal with template/image inclusion would make that kind of versioning a lot simpler - I am not familiar with it enough to be able to tell.

I think the gains from using ContentHandler (and by "using", it seems like this task assumes we're replacing the entire oarc table with a json-like ContentHandler page) are outweighed by the requirements that don't fit the ContentHandler model. Mostly the approval workflow, but also the cross wiki use.

You'd also pretty much be rewriting the entire extension. It's small enough that I think that's feasible, but I'd rather see us tackle OAuth2 if we're going to rewrite the whole thing.

I think using a json wiki page for supplemental information (description, link to privacy policy) and storing in the oarc table the approved revision id could work. You get into weird issues like what happens when the approved version get's suppressed, but I think you could make it workable.

In T109156#1637138, @csteipp wrote:

I think the gains from using ContentHandler (and by "using", it seems like this task assumes we're replacing the entire oarc table with a json-like ContentHandler page) are outweighed by the requirements that don't fit the ContentHandler model. Mostly the approval workflow, but also the cross wiki use.

At a minimum the secret key would stay in the table - putting that in revision entries seems very problematic.

Or maybe we could leave everything in the table, and use that data to generate some kind of "wikitext" for diffing, so that a JSON representation of each version would be stored in the text table but it wouldn't be actually used for anything other than displaying old versions and diffs. That would still mean reimplementing all the actions but it would retain a workflow that's familiar for most users. I haven't looked at ContentHandler close enough to tell if that's a realistic idea or not.

You'd also pretty much be rewriting the entire extension. It's small enough that I think that's feasible, but I'd rather see us tackle OAuth2 if we're going to rewrite the whole thing.

Well, I might be able to tackle this but probably not OAuth2 so those aren't really alternatives :) Anyway, could you file a task about that?

Probably this can be done step by step in reasonably-sized chunks.
Step 1: preserve a namespace (Application?), create a page for every application name (not every consumer, since we don't want separate pages for each app version), use the talk page to aid communication between the developer and the admins, on the page show the application name and links to the Special:OAuthListConsumers entries of the various app versions or something similarly stupid. Applications cannot be renamed currently so no headache about that (but need to make sure that suppression of the app deletes the page).
Step 2: fix T57705: Hyperlinks seemingly unsupported in app metadata fields in OAuth MediaWiki extension and T60193: OAuth consumer metadata is too limited, incorporate that data into the page.
Setp 3: Find some way to make parts of the page user-editable (that probably requires a new table, or maybe magic subpages)

All this still depends on

Or maybe we could leave everything in the table, and use that data to generate some kind of "wikitext" for diffing, so that a JSON representation of each version would be stored in the text table but it wouldn't be actually used for anything other than displaying old versions and diffs. That would still mean reimplementing all the actions but it would retain a workflow that's familiar for most users. I haven't looked at ContentHandler close enough to tell if that's a realistic idea or not.