Is your feature request related to a problem? Please describe.
At the moment, we do multi target our API Wrappers for both .NET Standard and .NET Framwork 4.6.1 as this is something library authors should consider.

✔️ CONSIDER adding a target for net461 when you're offering a netstandard2.0 target.

This makes our build pipeline more complicated then it has to be and makes it so we need to handle Windows different than other platforms. It takes time we could have spent improving the packages in other ways.

Please provide feedback in this thread if it would cause issues for you and your usage of our packages.

What area is it related to

• ActiveLogin.Identity.Swedish
• ActiveLogin.Identity.Swedish.TestData
• ActiveLogin.Identity.Swedish.AspNetCore

Describe the solution you'd like
We do, though plan to stop multi compile the libraries for net461 as it makes our build pipeline more complicated then it has to be. As I've understood, .NET Framework 4.6.X still can use .NET Standard 2.0, but might have issues with tooling.

Users that still uses .NET Framework 4.6.X, that might have issues with .NET Standard 2.0 can do wither of the following:

• Upgrade to .NET Framework 4.7.X
• "Upgrade" to .NET Core (preferably 3.X)

The same strategy will be applied to our Identity packages.

Describe alternatives you've considered
Keep multi targeting and handle the issues..

Additional context
N/A

A Swedish Reservnummer is mostly used within healthcare for persons that neither have a personal identity number or SwedishCoordinationNumber ,

There is a very vague definition of it,and different hospitals might do it in their own way.

• https://sv.wikipedia.org/wiki/Reservnummer
• https://www.vardgivarguiden.se/patientadministration/patientnara-rutiner/reservnummer/

Is your feature request related to a problem? Please describe.

The README.md is getting very long, and not that easy to navigate. I find it hard to find (and add) information there. And I think we might have the same issue with the README for ActiveLogin.Authentication.

I just feel that if I add more code examples in the README right now it will lead to information overload and the important stuff in the README about why you should use the library, our design decisions and sponsors will just get hidden away.

The README just won't scale when we have to add information, examples and samples for all the types of numbers we plan to support in the future.

I have looked at some other open source libraries, for example FsCheck and I think it is using a great approach that I have seen in many other open source libraries:

1. At the top of their github page they have a link to a separate documentation site using github-pages.
2. On the documentation site they have an api-reference, which I assume is auto-generated, with documentation on the functions and parameters in the api with relevant links to code on github.

Should we maybe look into something like this for ActiveLogin.Identity/Authentication? Or at the very least we should add a table-of-contents on the top of our README to make it easier to navigate and find information.

Is your feature request related to a problem? Please describe.

The samples are growing pretty long. We should do something to separate the code for the different apis (SwedishPersonalIdentityNumber, SwedishCoordinationNumber, IndividualIdentityNumber). And it should also be prepared to handle more apis (for example CompanyNumber, CompanyRegistrationNumber etc.).

Is your feature request related to a problem? Please describe.
There is a need to have the same perfect functional of parser and validator for Finnish personal identity number.

What area is it related to
New package, perhaps refactor of existing SwedishPersonalIdentityNumber parser to unify it

Describe the solution you'd like
We will have to fulfil the following checklist:

• Move common parts to a separate project
• Create its own type for Finnish Personal Identity Number since they have a bit different format
• Expose c# api with proper documentation
• Refactor existing parser, add support for delimiter parser function
• Find test data at Finnish "skatteverket" and create its own project
• Create unit tests

Describe alternatives you've considered
N/A

Additional context
After quick look there is a really good description on wiki and it does not look as complex as Swedish one:

In Finland, the Personal Identity Code (Finnish: henkilötunnus (abbreviated as HETU), Swedish: personbeteckning), also known as Personal Identification Number, was introduced in 1964 and it is used for identifying the citizens in government and many corporate and other transactions. It consists of eleven characters of the form DDMMYYCZZZQ, where DDMMYY is the day, month and year of birth, C the century sign, ZZZ the individual number and Q the control character (checksum). The sign for the century is either + (1800–1899), - (1900–1999), or A (2000–2099). The individual number ZZZ distinguishes persons with the same date of birth from each other and it is odd for males and even for females and for people born in Finland its range is 002–899. Numbers 900–999 are used for temporary personal identification, for example in hospitals, when an official ID is not known or has not yet been given to a child born. Temporary IDs are not logged in the Finnish Population Information System.

An example of a valid code for a fictional female born on 13 October 1952 is 131052-308T. The control character, either a number or a letter, is calculated as the remainder of DDMMYYZZZ divided by 31, i.e. by dropping the century sign and dividing the resulting nine-digit number by 31. Taking the number series, in this case .806451613 appearing after the decimal point and multiplying it by 31 and rounding the resulting number to the nearest whole number gives the remainder. The corresponding character is then picked from the string "0123456789ABCDEFHJKLMNPRSTUVWXY" (ambiguous letters G, I, O, Q, and Z are not used). For remainders below ten, the remainder itself is the control character whereas 10 corresponds to A, 11=B, 12=C, ending up with 30=Y. In this example, 131052308 / 31 = .806451613 x 31 = 25.000000003 rounded to 25=T.
Source

Is your feature request related to a problem? Please describe.
NuGet and NuGet.org now supports Packaging Documentation within the nupkg. This allows for docs to be versioned for the specific package you use, offline scenarios and documentatyion next to the package at nuget.org.

https://github.com/NuGet/Home/wiki/Packaging-Documentation-within-the-nupkg

What area is it related to
All packages

Describe the solution you'd like
Embed a small Readme.md per package, that is more to the point on what that package does.

The method is defined as: public static void Equal<T>(T expected, T actual),
but some of the tests have flipped expected and actual, resulting in misleading error messages when the tests fail.

It seems to be only in the the tests for Parse but in that class nearly all the calls to Assert.Equal uses the wrong order.

It's easy to mess up and it makes me miss the Assert.That-syntax from nUnit, or the .Should()-syntax from FluentAssertions where you rarely make these mistakes.

Describe the bug
When requesting a list of random Swedish PersonalIdentity Numbers (SwedishPersonalIdentityNumberTestData.GetRandom(x)) it returns a FSharpList (Microsoft.FSharp.Collections.FSharpList), even when consumed from the C# facade.

What area is it related to
SwedishPersonalIdentityNumberTestData

Expected behavior
Return an IEnumerable as the rest of the methods does.

Actual behavior
Returns Microsoft.FSharp.Collections.FSharpList.

Screenshots
If applicable, add screenshots to help explain your problem.

NuGet package version
1.0.0

Runtime version
.NET Core 3.1.0

Given a valid company registration number we can use an external service to validate if it actually exists (http://ec.europa.eu/taxation_customs/vies/?locale=sv). We can also get some additional information from this service. We should provide this in our api in an async manner.

This test will fail:

[Fact]
public void Bug_Reproduction()
{
    var pin = SwedishPersonalIdentityNumber.ParseInSpecificYear("960207-9809", 1895);
    var expected = new SwedishPersonalIdentityNumber(1896, 02, 07, 980, 9);
    Assert.Equal(expected, pin);
}

// Expected: 189602079809
// Actual:   179602079809

Expected Behaviour
I think we should throw an ArgumentException. I do not think we have enough information to figure out what the user is expecting the result to be.

Some unit tests are failing on my mac because the exception messages will only use "\n" to indicate a new line instead of \r\n which is hard coded into the test assertions.

An improvement would be to use Environment.NewLine instead of "\r\n" in the assertions, but I am wondering if we really should be doing exact assertions on the exception messages anyways? It seems too fragile in my opinion

e.g.
Assert.Equal($"Invalid year.{Environment.NewLine}Parameter name: year{Environment.NewLine}Actual value was {year}.", ex.Message);

instead of

Assert.Equal($"Invalid year.\r\nParameter name: year\r\nActual value was {year}.", ex.Message);

I just supposed TryParse should return false when parsing any kind of invalid personal identification number.
However it seems to return true when the personal id number contains for example invalid day (99).
And the out param contains the invalid day (in this case).
Is this by purpose or bug? Shouldn't it be possible to check a personal id number with one call?
I can't see how to check for invalid personal number witch correct syntax but invalid day/month, etc.

When we are supporting Coordination number, it no longer is useful to have a special error message for potential Coordination numbers when parsing a Personal Identity Number.

Either you are using SwedishPersonalIdentityNumber.parse/create and expect the operation to fail when it's not a personal identity number.

Or you are using SwedishCoordinationNumber.parse/create and expect the operation to succeed when it's a coordination number.

Or you are using IdentityNumber.parse/create which can handle both.

Since we have removed the FSharp api, we no longer need the Error types since we are not exposing them in the api.

Without losing any type safety we can simply throw the exception directly when validating. This means we can remove some boiler-plate code for dealing with the Result-type that we no longer need.

Right now we are only wrapping any validation errors (or parsing errors) in a Result-type, and the unwrapping it just to throw the exception.

Today builds are done using Azure Pipelines, which we love. Though, all build configuration is defined as tasks using the UI. I'd suggest we rewrite the builds using Cake and define the parts we need in Azure Pipelines as YAML. This would make it easier to build on your local machine and the build process would be more transparent.

Is your feature request related to a problem? Please describe.
Bogus is a great way to generate fake data in .NET:
https://github.com/bchavez/Bogus

It has support for "randomizing" national identity numbers for US, Norway, Finland etc. but lacks support for Swedish personal identity numbers. You should not randomize this, but rather use test numbers that we provide in our TestData-package.

What area is it related to

• PersonalIdentityNumber
• CoordinationNumber

Describe the solution you'd like
If we create a small adapter that maps our testdata-package to the Bogus "API" (using extensions to the Person object) it would be easier to use.

We have found out that validating the age, and maybe the gender of a person, might be a common usecase that could be implemented as part of the validation attribute(s).

I see two potential ways of doing this.

1. Implement it as options on the current SwedishPersonalIdentityNumber
   • Example: [SwedishPersonalIdentityNumber(MinimumAge = 18, MaximumAge = 30, Gender = Gender.Female)]
2. Add two additional attributes, such as SwedishPersonalIdentityNumberAge and SwedishPersonalIdentityNumberGender
   • Example: [SwedishPersonalIdentityNumber]
   • Example: [SwedishPersonalIdentityNumberAge(MinimumAge = 18, MaximumAge = 30)]
   • Example: [SwedishPersonalIdentityNumberGender(Gender.Female)]

I'd vote for number 1, cleaner and easier to find out what validation options you have.

What do you think?

Problem

At the moment we support these input variations (7 in total), plus that we trim leading and trailing whitespace:

10 digit string

• YYMMDD-BBBC
• YYMMDD+BBBC
• YYMMDD BBBC (Treated as YYMMDD-BBBC)
• YYMMDDBBBC (Treated as YYMMDD-BBBC)

12 digit string

• YYYYMMDDBBBC
• YYYYMMDD-BBBC (Treated as YYYYMMDDBBBC)
• YYYYMMDD BBBC (Treated as YYYYMMDDBBBC)

Though, after some offline discussions with @jgbptl (who has implemented this before), I've realized users are writing personal identity numbers in far more format than these. Just a few examples:

• YYYY-MM-DD-BBBC
• YYMMDD.BBBC
• YYMMDD BBBC (two whitespaces)

Suggestion

I'd vote for expanding the variations we allow for input, while still having the possibility to parse in a more strict mode (as we have now). Ideally adding support for more variations could be done in a none breaking way so that we can release it as (something like) 1.1.0.

We should accept pretty much any character and just strip it away, while still handling the + sign in the 10 digit version as a special case. Because we have the checksum, we can be very confident that we actually are parsing a valid PIN.

Solution

The pseudo code for how to parse basically all versions would be:

1. Strip out all chars except numbers (0-9) and plus (+).
2. If the value now ends with +XXXX (where X is a digit), treat the delimiter as plus (+), otherwise hyphen (-).
3. Strip out all remaining plus (+) chars.
4. If the length is 12 chars, don't care about the delimiter and instead parse it as a full year.
5. If the length is 10 chars. parse it and take the delimiter into account.

My proposed solution is to follow roughly how DateTime does this:
https://docs.microsoft.com/en-us/dotnet/api/system.globalization.datetimestyles?view=netstandard-2.0

In our case it would mean adding overloads to the .Parse(), .ParseInSpecificYear(), .TryParse() and .TryParseInSpecificYear() that would accept an SwedishPersonalidentityNumberStyles that would specify some rules for what to parse. Either we do it exactly as they do, with bitflags, but I think an enum could be enough, with these three values:

• SwedishPersonalidentityNumberStyles.Strict (Would only allow the strictly correct versions, YYYYMMDDBBBC, YYMMDD-BBBC and YYMMDD+BBBC. No trimming of white space etc.)
• SwedishPersonalidentityNumberStyles.Default (Would work as of today, trim leading and trailing white space and supporting the 7 versions described above).
• SwedishPersonalidentityNumberStyles.Loose (Would try the best it can to actually parse it, basically removing all invalid chars etc.)

If not specified, SwedishPersonalidentityNumberStyles.Default would be used.

So, what do you think? Good approach and what should we name things?

Is your feature request related to a problem? Please describe.
By moving the extension methods from test data (SwedishPersonalIdentityNumberTestDataExtensions ) into the namespace for SwedishPersonalIdentityNumber (ActiveLogin.Identity.Swedish) the IsTestData() would be available immediately, without the need to import any additional namespace. Microsoft follows this convention for a lot of its extension methods.

What area is it related to

• SwedishPersonalIdentityNumbers

Describe the solution you'd like
Change namespace as described above.

The names of many types are very long. Since the types are already in a ActiveLogin.Identity.Swedish-namespace we can remove "Swedish" from the type names I think.

We have been using SerialNumber as that's what Wikipedia describes the "födelsenummer" as, but the correct way to translate this into English seems to be BirthNumber.

https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2773709/

The test data provided for coordinationnumbers from Skatteverket contains several numbers where the "month" part is 0. This is to my understanding invalid. All the links with information on coordination numbers (see #13) state that the 6 digits of the 10-digit coordination number follow the same rules as in a personal identification number with the exception that 60 is added to the date.

I have sent a question to Skatteverket asking for clarification, but in the meantime I will remove any such numbers from the test data set.

So depending on what we find out, we either need to fix our implementation for coordination number to allow for month=0. And re-add these numbers to the test data set. Or in the other cas we can close this issue.

If I try to create an identity number with invalid year and date, as a consumer the API, do I expect to only get one exception for the first error (year), one exception with InnerExceptions for both errors, or an AggregateException containing the two exceptions?

It might be fine the way we do it now, but that behavior is not asserted by any tests, I think.

Originally posted by @viktorvan in #17 (comment)

Hi,

It seems to be a bug in GetAgeHint.
It seems to return wrong age for some combinations of identity number and dates.
Probably due to usage of DateTime.DayOfYear without taking into account it returns different day for same date (after leap day) depending on leap year or not (https://docs.microsoft.com/en-us/dotnet/api/system.datetime.dayofyear?view=netcore-2.1)

Please note "Fails" comment below for assumed failing scenarios.
`
[Theory]
// Birth non leap year, before "leap day"
[InlineData("201701052399", "20180104", 0)]
[InlineData("201701052399", "20180105", 1)]
[InlineData("201701052399", "20190104", 1)]
[InlineData("201701052399", "20190105", 2)]
[InlineData("201701052399", "20200104", 2)]
[InlineData("201701052399", "20200105", 3)]

    // Birth non leap year, after "leap day"
    [InlineData("201703052397", "20180304", 0)]
    [InlineData("201703052397", "20180305", 1)]
    [InlineData("201703052397", "20190304", 1)]
    [InlineData("201703052397", "20190305", 2)]
    [InlineData("201703052397", "20200304", 2)] // Fails. Actual 3
    [InlineData("201703052397", "20200305", 3)]

    // Birth leap year, after leap day
    [InlineData("201603102383", "20170309", 0)]
    [InlineData("201603102383", "20170310", 1)] // Fails. Actual 0
    [InlineData("201603102383", "20180309", 1)]
    [InlineData("201603102383", "20180310", 2)] // Fails. Actual 1
    [InlineData("201603102383", "20190309", 2)]
    [InlineData("201603102383", "20190310", 3)] // Fails. Actual 2
    [InlineData("201603102383", "20200309", 3)]
    [InlineData("201603102383", "20200310", 4)]

    // Birth leap year, on leap day
    [InlineData("201602292383", "20160229", 0)]
    [InlineData("201602292383", "20170228", 0)]
    [InlineData("201602292383", "20170301", 1)]
    [InlineData("201602292383", "20200228", 3)]
    [InlineData("201602292383", "20200229", 4)]
    public void GetAgeHint_ActualDate_ExpectedAge(string personalIdentityNumber, string actualDate, int expectedAge)
    {
        // Arrange
        var swedishPersonalIdentityNumber = SwedishPersonalIdentityNumber.Parse(personalIdentityNumber);
        var date = DateTime.ParseExact(actualDate, "yyyyMMdd", CultureInfo.InvariantCulture, DateTimeStyles.AssumeLocal);

        // Act
        var age = swedishPersonalIdentityNumber.GetAgeHint(date);

        // Assert
        Assert.Equal(expectedAge, age);
    }

`

Swedish companies all have a unique number (Organisationsnummer), called company registration number, that is used for taxes and similiar places when you need to identify a company.

As it's a common usecase and an implementation would be very similar to a PersonalIdentityNumber we aim to implement this.

Info and definitions:

• http://bolagsverket.se/ff/foretagsformer/organisationsnummer-1.7902
• https://sv.wikipedia.org/wiki/Organisationsnummer
• http://www.mira.se/knowledge-base/vad-heter-personnummer-och-samordningsnummer-pa-engelska/
• https://www.skatteverket.se/foretagochorganisationer/startaochdrivaforetag/startaochregistrera/organisationsnummer.4.361dc8c15312eff6fd235d1.html

It turns out that the delimiter in an Swedish personal identity number goes from - into +, not on the very day you turn 100, but the year you do so. We should update our code to reflect this.

When throwing exceptions from .*Parse(string s) it seems that we should throw either ArgumentNullException (when null) or FormatException (when invalid of other reasons).

https://docs.microsoft.com/en-us/dotnet/api/system.formatexception?view=netstandard-2.0

Will be fixed in #64

We should use the constructor instead of .Create() to harmonize with rest of .NET for this thing. For example, DateTime, throws exceptions from constructor when invalid.

Is your feature request related to a problem? Please describe.
There could potentially be an issue with serializing/deserializing the number types in this library.

Describe the solution you'd like
We should investigate this and add unit tests for some common scenarios.
Look at
https://github.com/dotnet/runtime/blob/master/src/libraries/System.Private.CoreLib/src/System/DateTime.cs#L49
Maybe we should implement ISerializable.

Describe alternatives you've considered
Using the 12-string representation for persistence will always work.

Describe the bug
We cannot represent a pin if the subject would be 200 years old. We do not have a century number and the only valid delimiters are - and +.

What area is it related to
PersonalIdentityNumber, to10DigitString and to10DigitStringInSpecificYear

To Reproduce
Steps to reproduce the behavior:
N/A

Expected behavior
We should throw an exception if the parseYear is invalid. I.e. if it is a year on or after the subject turns 200.

Is your feature request related to a problem? Please describe.
After numerous emails with Skatteverket, we now have verified two things regarding Swedish Coordination Number:

• Month=0 and day=60 are to be expected. This means month and day are set to 00 and they might be so when day and/or month can't be verified.
• Days too high for a given month as found in the test data is not valid. The test data is invalid.

What area is it related to

• Coordination Number

Describe the solution you'd like

• Update the docs to describe that this is the official definition
• Update the implementation not to allow to high days
• Decide on how to handle month/day == 00.
• Update test data.
• Update unit tests.
• Bring back Date and Age hints for CoordinationNumber

Major question is, can/should we bring back the hints? Now we now that only when month/day is 00 the data can't be verified. Can we return all hints, but throw an exception if date is not verified? It should be edge cases.

At the moment a SwedishPersonalIdentityNumber can be serialized into two kind of standardized string formats, these are:

• .ToShortString(): YYMMDD[- or +]SSSC (Example: 990807-2391 or 990913+9801)
• .ToLongString(): YYYYMMDDSSSC (Example: 199908072391 or 189909139801)

Note: Technically only .ToShortString() produces a correct way of representing a Swedish PIN, but because that format is not optimized for storing (as the delimiter changes from - to + when you turn 100) it is recommended to store it as the long version (with the century as part of the number).

.ToShortString() and .ToLongString() is not very explaining, even if the (Intellisense) docs explain and show examples. Could the name of these be improved in any way?

DateTime uses .ToLongDateString() and .ToShortDateString().

Could similar names be applied here, like: .To*SwedishPersonalIdentityNumberString() or .To*SwedishPinString()?

I can sort of understand the docs:

The date to decide wheter the person is older than 100 years. That decides the delimiter (- or +).

But I cannot really figure out the usecase for when this would ever be needed.

All the tests pass if I replace the parameter with DateTime.UtcNow, so either the parameter is not needed and we should remove it, or we are missing some tests showing what requirement it is closing.

Is your feature request related to a problem? Please describe.
We are using the licenseUrl and iconUrl that are now deprecated. We treat warnign as errors and therefore our builds are breaking.

What area is it related to
All packages.

Describe the solution you'd like
Embed the license and icon in the package as described here:

• https://github.com/NuGet/Home/wiki/Packaging-License-within-the-nupkg
• https://github.com/NuGet/Home/wiki/Packaging-Icon-within-the-nupkg

While on it, might be relevant to package the docsas well.

• https://github.com/NuGet/Home/wiki/Packaging-Documentation-within-the-nupkg

Describe alternatives you've considered
None

Additional context
We are specifying these properties in csproj, but the documentation for those props are not yet updated. Will have to give it a try.

We have had some offline discussions about implementing the business logic in F# and we decided to add the code and continue the discussion in this issue instead.

I have added a new branch with a project that implements the same business logic in F# and exposes both a new api in F# and one in C# (which should exactly the same api as in the current solution).

Right now the original C# project and the new C# api from the F# project are using the same namespace ActiveLogin.Identity.Swedish, so ideally you should be able to just switch your references and everything should still work. I imagine that there will be problems if you try to reference both the old C# project and the new F# project at once.

The exact same unit tests have been copied to a new test project and run against the F# implementation to verify that the two implementations are fulfilling the same requirements.

The ConsoleSample has been updated to use the C#-api from the F#-project (no code changes, it is just using a new project reference). There is now also an FSharpConsoleSample that runs through the same samples using a functional approach in F#.

TODO: Add documentation comments to the public F# api and update README.md with information about the F# api.

So, here are a few alternatives with what we can do with this F# code to get a discussion going:

1. We simply replace the current C# implementation with this new F# implementation. No C# users would be affected since we are using the same public api and fulfil the same requirements.
2. We switch to using the F# implementation, but keep the C# implementation around in an ActiveLogin.Identity.Swedish.CSharp.Example namespace in case anyone is interested in seeing what a C# implementation would look like.
3. We keep using the C# implementation, but add the F# as an example instead.

I vote for 1. because that option would not actually change anything for our C# users while it adds an F# api for any F# users.
And of course it has the added benefit that the contributors/maintainers of this repo gets a chance to learn more F#!

Inspired by Microsoft Open-source library guidance we should add another target for net461 in addition to the existing netstandard20.

CONSIDER adding a target for net461 when you're offering a netstandard2.0 target.

The fsharp api was removed in #112 and the readme should be updated to reflect this.

At the moment, SwedishPersonalIdentityNumber is implemented in C# targeting .NET Standard, which (kind of) limits it to server side use. Implementing it in JavaScript (using TypeScript) and publish it as an NPM package would enable client side parsing and validation scenarios as well as using it from node.js on the server.

When we have implemented more types of IdentityNumbers there will probably be a usecase for parsing an unknown number and get back the type that it is.

The returned type might be something like:

type IdentityNumber =
    | SwedishPersonalIdentityNumber of SwedishPersonalIdentityNumber
    | CompanyRegistrationNumber of CompanyRegistrationNumber
    | PersonalIdentityNumberOrCompanyRegistrationNumber of SwedishPersonalIdentityNumber * CompanyRegistrationNumber
    | SwedishCoordinationNumber of SwedishCoordinationNumber

and in C# we cannot be quite as helpful and would have to let the client check themselves what number types that were returned.

public class ParseResult
{
    public SwedishPersonalIdentityNumber SwedishPersonalIdentityNumber { get; }
    public CompanyRegistrationNumber CompanyRegistrationNumber { get; }
    public SwedishCoordinationNumber SwedishCoordinationNumber { get; }
}

We propose that we separate facts about the Personal Identity Number (such as checksum, serial number and so on) from data that can be extracted from the PIN (DateOfBirth / Age / Gender). The main reason is that due to limitations in the number of PIN Swedish government can issue per day, it's not always the truth that the first part is your date of birth.

Use cases

Valid use cases, even if these data are not treated as facts, are:

• Populate a form of your date of birth / gender when you register for a new service.
• Validate if you (probably) are above 18 years old.

The proposed changes are:

1. Rename methods and properties with an Hint suffix to reflect that it's not a fact.
2. Move them into extension methods on class SwedishPersonalIdentityHintExtensions as all data they return can be extracted from public data on the PIN. By doing so, properties will turn into methods.

The changes would result in these renamings:

• .DateOfBirth > .GetDateOfBirthHint()
• .GetAge() > .GetAgeHint()
• .Gender > .GetGenderHint()

Originally posted by @PeterOrneholm in #11 (comment)

In Sweden, if you don't are a registered Swede and have a Personal Identity Number, you can still have a lightweight version of that called co-ordination number.

A co-ordination number is an identification for people who are not or have not been registered in Sweden. The purpose of co-ordination numbers is so that public agencies and other functions in society are able to identify people even if they are not registered in Sweden.

The Swedish Tax Agency allocates co-ordination numbers upon request. All Government authorities and certain private higher education institutions have the right to request co-ordination numbers.

Info and definitions:

• http://www.mira.se/knowledge-base/vad-heter-personnummer-och-samordningsnummer-pa-engelska/
• https://sv.wikipedia.org/wiki/Samordningsnummer
• https://www.skatteverket.se/privat/skatter/internationellt/bosattutomlands/samordningsnummer.4.53a97fe91163dfce2da80001279.html

Right now all the unit tests are at the level of SwedishPersonalIdentityNumber and SwedishCoordinationNumber. I think we have full coverage of the parsing/validation-logic from there, but we should add just a few tests for the IndividualIdentityNumber wrapper as well.

Describe the bug
The inequality operator != is currently using referential comparison when called from C#.

What area is it related to
PersonalIdentityNumber, CoordinationNumber.

To Reproduce

SwedishPersonalIdentityNumber.Parse("680164-2395") != SwedishPersonalIdentityNumber.Parse("680164-2395")

Expected behavior
It should use structural equality

When working on support for CoordinationNumbers and CompanyRegistrationNumbers it became clear that we have been exposing to many internals of the F# types. It turns out the different parts of the identity numbers have less in common that we initially expected. This means we would have to expose even more types when adding the new types of numbers.

It makes sense to keep the types internal and use them for validation and type safety, but when exposing properties on the public classes we should use more primitive types.

In the process of thinking of what a new F# api would look like then I come to the conclusion that it would be almost exactly the same as the current C# api.

My suggestion then is that we simply expose all our functionality through a single api (the C# one). This would drastically decrease the amount of code and documentation we need to maintain.

Is your feature request related to a problem? Please describe.
We want to make sure it runs and works with the latest stable version of .NET.

What area is it related to
Samples and tests.

Describe the solution you'd like
Update TargetFramework to netcoreapp3.0.

Describe alternatives you've considered
Stay on 2.1, not relevant.

Additional context
None

Describe the bug
Missing xml-comments in metadata for the C# api

What area is it related to
SwedishPersonalIdentityNumber.TryParse and
SwedishPersonalIdentityNumber.TryParseInSpecificYear

To Reproduce
Steps to reproduce the behavior:
Try to view xml-comments for the above mentioned methods, for example by hovering on the method names.

In the source code the methods have xml-comments:

    /// <summary>
    /// Converts the string representation of the personal identity number to its <see cref="SwedishPersonalIdentityNumber"/> equivalent  and returns a value that indicates whether the conversion succeeded.
    /// </summary>
    /// <param name="s">A string representation of the Swedish personal identity number to parse.</param>
    /// <param name="parseResult">If valid, an instance of <see cref="SwedishPersonalIdentityNumber"/></param>
    static member TryParse((s : string), [<Out>] parseResult : SwedishPersonalIdentityNumberCSharp byref) =
        let pin = parse s
        match pin with
        | Error _ -> false
        | Ok pin ->
            parseResult <- (pin |> SwedishPersonalIdentityNumberCSharp)
            true

But if you look in the comments file ActiveLogin.Identity.Swedish.xml there are no entries for the two functions with out-parameters.

Expected behavior
The xml-comments should be displayed. But they are not.

Screenshots

NuGet package version
2.0.1

Runtime version
.net core 2.2.104

Additional context
Visual Studio Code 1.31.1

Inspired by Microsoft Open-source library guidance we should add another target for net461 in addition to the existing netstandard20.

CONSIDER adding a target for net461 when you're offering a netstandard2.0 target.

The methods GetGenderHint and GetAgeHint is not present in the class SwedishPersonalIdentityNumber when having installed SwedishPersonalIdentityNumber v2.0.1

What's up with that? I don't understand what I might be doing wrong? I had to go down to 0.3.2 to get hold of the old age/gender methods.

Active Login loves contributions from the community! We have seen initiatives from other companies like DigitalOcean and Microsoft to hand out t-shirts for OSS contributions during October. This year we are doing the same!

The first 10 PR:s from the community to be accepted during October will get a Active Login t-shirts! Exact design will be presented later :) Please see details below:

• The contribution should follow our Contribution guidelines. First and issue, then PR, write tests etc.
• You should follow our Code of conduct.
• The PR should be merged before the end of October. We might approve some days into November as well... :)
• The applicable repos are:
  • https://github.com/ActiveLogin/ActiveLogin.Authentication
  • https://github.com/ActiveLogin/ActiveLogin.Identity
• We do accept PR:s for documentation and samples as well, but don't forget to write an issue first so we agree on that it should be fixed/implemented!
• Once merged, drop us an email (found in our profile) with a link to your PR and we'll get back with details on shirt size etc.
• We send it for free within Sweden. If you live abroad, you can pick it up on our Stockholm office :)
• We like if you Star our repo(s) as well ;)

Inspired by Microsoft Open-source library guidance we should strong name the assemblies to support beeing referenced from other strong named assemblies.

CONSIDER strong naming your library's assemblies.