Releasing 6.0.0

[PeterOrneholm]

With the release 6.0.0 of ActiveLogin.Authentication we bring new features, bug fixes, and improved documentation.
Most important we now fully support the sign functionality in BankID with UI, flow etc.

We are happy to celebrate that we know have passed 450 000 downloads on NuGet!

Since 5.0.0 we have:

• Made loads of changes
• Closed 9 Issues and Pull Requests

3 people contributed to this release. Thank you @tobylo, @ChrisKlug and @PeterOrneholm.

News

Major features and changes in this release

• Support BankID Sign with both API, flow, and UI
• New architecture under the hood to support both BankID Sign and Auth. Allows for more use cases as the core parts is separated from the web parts.
• Some certificates are now embedded (with permission from BankID) for easier handling of them

Features & Improvements

• Implement UI for BankID Signing Implement UI for BankID Signing #110
• Remove dependency on Bootstrap Remove dependency on Bootstrap #367
• Migrate frontend code to Typescript
• Implement new Architecture New Architecture #257
• Embed the custom Root CA:s as part of the library to make it easier to consume Embed the custom Root CA:s as part of the library to make it easier to consume #368
• Use the new CustomTrustStore for validating custom Root CA Use new CustomTrustStore for validating custom Root CA #366
• Use a version of Application Insights that supports connection strings
• Remove all references to manually entered PersonalIdentityNumbers (recommended by BankID)
• Move texts from resource files into code (as resource files in libraries are tricky)

Bugfixes & Refactorings

• Using JSON.NET causes System.InvalidOperationException Using JSON.NET causes System.InvalidOperationException #373, Decoupled JSON serialization from system defined serialization #374
• Use ApplicationFeatures to register the BankID UI Use ApplicationFeatures to register the BankID UI #322
• Refactor controllers Refactor controllers #199

DevOps & Misc

• New codesigning certificate for NuGet packages

Breaking changes

This a major release, with many breaking changes. Most of them should go unnoticed for the majority of installation but some changes will hit everyone.

For a full list of breaking changes, see all issues/PR:s prefixed with the Breaking change: above. Most of them should go unnoticed, but a few might have a bigger impact.

The most important ones are listed in the file BREAKINGCHANGES.md in the root of the repo.

Feedback

If you find any bugs or have feedback in general. Please file an issue!

Thanks

Thanks to the community for providing code, testing and feedback!
Thanks to our sponsor (not announced yet) for the sign feature!

---

This discussion was created from the release 6.0.0.

[nahojd]

Hi,

Is it QR-code only in the new version, even for the simulated login? In the previous version it was possible to set the personal identity number on login, but now I can't find any way to do that, not even when using the simulated environment.

I see that I can set it in the configuration in startup, but that would mean using the same personal identity number for every login, which is not really helpful. We have been using the simulated environment for two different use cases:

• Login mechanism for the internal test environment, where we want to be able to quickly log in as different users without having to set up fake bankid logins for every user (which is not feasible anyway for the non-technical users and testers), since we have to test different cases for dozens of different users.
• Login for automatic tests, where we need to be able to login as different users to trigger different behaviours in the application.

Is there any way to accomplish this in version 6?

[smuda]

Yeah, I see their point. I think we need to wait and see what BankID creates in RPv6. Personally, I'd assume personalNumber start will be removed.

But what else will be included in RPv6? Obviously there is a UX win in not requiring QR when signing after authentication but security requires us to hold on to the channel binding from the authentication. Well, as we say, "den som lever får se".

[span]

I'm not so sure they will/can drop support for PIN even if they want to. A lot of organisations are using the PIN to initiate an identification of a customer over the phone.

A typically legit example would be a customer talking to Customer Service of an organisation and the customer service agent wants to identify the caller. The customer service agent may then enter the PIN and initiate an authentication process with BankID allowing the customer to simply open the app and identify themselves.

Although this same scenario is being abused for frauds, I do not think BankID can stop supporting it without some other means of initiating the auth process.

I think we should support PIN as long as BankID supports it, but as a "deprecated mode" that will go away if/when BankID drops it.

[PeterOrneholm]

I'm not so sure they will/can drop support for PIN even if they want to. A lot of organisations are using the PIN to initiate an identification of a customer over the phone.

I know a lot of existing implementations do this, but for pretty much every scenario (se exception below) you can restructure the flow to not require PIN as input, but rather check what PIN is returned for the identification from BankID.

A typically legit example would be a customer talking to Customer Service of an organisation and the customer service agent wants to identify the caller. The customer service agent may then enter the PIN and initiate an authentication process with BankID allowing the customer to simply open the app and identify themselves.

This is a very valid scenario. I'm not sure if you have subscribed to the newsletter from BankID, but I noticed this exact scenario was addressed in their newsletter yesterday :) See image below. Basically (as I interpret it): They are aware of this scenario, there will be a specific solution for it (not ready yet) and those who are in need of it will have at least one year to implement it once announced. When they go public about it we'll see how we can incorporate that into Active Login.

I think we should support PIN as long as BankID supports it, but as a "deprecated mode" that will go away if/when BankID drops it.

The support for PIN as input to identification / sign is already gone from the UI/web parts in Active Login since v6.0.0. It added complexity to the solution and we decided to get rid of it when doing our refactorings for v6.0.0 as it isn't the long-term goal to do it that way. At the API level we still support 1:1 of that the BankID API supports, so on that level you can supply the PIN, but it shouldn't be your long term strategy.

[smuda]

According to the official information, personalNumber start will be removed from the API from 2024-05-01 so there's no rush but many orgs will need to do the transition. Honestly, the update is done to protect both individual users and relying parties, so pushing them in the right direction is a Good Thing (tm).

From what I've heard, BankID would have liked to remove the support even earlier.

(Honestly, several orgs will need that time as not all organizations is "move fast and break things". Dare I say Safe?)

About the identification over phone, I totally agree that's one use case they want to support for a long time. I'd assume that's going to be a different API and GUI altogether since that's the only way I can see how to remove personal number start over the Internet and still keep the use case.

But hey, that's just my 5-krona, you do you.

[span]

Funny. I did not read the newsletter so that's a bit of coincidence 😂

I'm perfectly fine with waiting for a proper solution from BankID.