Theoretical Breaking Changes Upcoming RFC (ehancements)

[james-d-elliott]

I've been considering a number of breaking changes for a while now. While disruptive to implementers I feel like the benefits outweigh the downsides (especially pre-v1). The following list outlines the various breaking changes I plan to discuss and would love some feedback on.

1. Add a Metadata Service interface.
2. Add a Configuration interface or interfaces.
3. Add a context to most request-based public methods.
4. Remove deprecated fields.

Add a Metadata Service interface

The first element that made me consider the idea of a breaking change is the Metadata service and current implementation. To my way of thinking it would be significantly more convenient for an implementer to be able to provide their own implementation of the Metadata functions so that the potential to add smart caching was possible.

For example implementers may want to save the blob to disk or shared storage (either blob or otherwise) and check if it needs to be refreshed based on the blob information itself. Adding a interface would allow this to occur with minimal fuss.

In addition I'll likely couple this with pre-parsing of the fields in the MDS blob that have a more appropriate go struct such as date fields and certificate fields. That way they only need to be parsed while decoding the blob. The parsed version will be the basis for the interface.

Likely breakages

Most of everything in the metadata package will need to break.

Add a Configuration interface or interfaces

I think the idea of hot reloading is rather desirable for the configuration as well as the ability to base the configuration values based on the context. However to do this we either need to make the fields private and introduce locks to prevent race conditions or we need to instead create and implement an interface which allows implementers to design this business logic themselves (exactly where this kind of logic belongs in my opinion).

We could either implement a monolithic interface or specific interfaces for the particular additional but optional features in the future.

Likely breakages

The Config field of the WebAuthn struct will be an interface so the values will not be directly accessible. Providing a *Config either via New() or directly declaring a WebAuthn struct should remain unchanged.

Add a context to most request-based public methods

Theoretically there are times where being able to include a context may be useful in functions similar to BeginLogin, BeginRegistration etc. I'm less certain about the benefits of this one here compared to the others. However in retrieving configuration options from the configuration interface the inclusion of this may be quite useful depending on what an implementer is aiming to accomplish.

Likely breakages

Most functions within the Begin/Finish Login/Registration flows will change their signature. It's likely several functions in the protocol package will also have a signature adjustment.

Remove deprecated fields

There are quite a few deprecated fields at present. The above changes are defiantly breaking and feeling like one painful breaking change may be better than frequent ones. The fields are fairly easy for implementers to update as well.

Likely breakages

People still using these long deprecated fields will have to update.