Azure-activedirectory-identitymodel-extensions-for-dotnet: SAML2 Token KeyInfo: should it inherit prefix or be set to no prefix?

[Tarig0]

In the old .net 4 the key info element has no prefix.

Looks like the code may be meaning to use a no prefix start element but the behavior doesn't match

https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet/blob/6e7a53e241e4566998d3bf365f03acd0da699a31/src/Microsoft.IdentityModel.Xml/DsigSerializer.cs#L630

[brentschmaltz]

@Tarig0 we will get this into 5.3.1

[brentschmaltz]

@Tarig0 5.3.1 became 5.4.0 as we have breaking changes.
Will try for next release

[brockallen]

5.3.1 became 5.4.0 as we have breaking changes.

Wouldn't that need to be a 6.0 if you have breaking changes?

[brentschmaltz]

@brockallen et al.
Thanks for the feedback.
We discussed this as a team and decided to roll back any breaking changes till 6.x.
We also are going to remove our "Obsolete" flags until we have some way of providing 'helper' methods. The reason is some companies will not allow using Obsolete and we need some easy workaround for those. Also some users builds will start breaking as warnings will occur.

Our plan is to release a follow up indicating what will be breaking.
We can use the Obsolete tag, but I would like to hear suggestions.

[brockallen]

I don't have any specific recommendations for this feature, but in general it would be nice to have a more stability.

[brentschmaltz]

@brockallen
I hear you on stability and as NET Core now is fairly stable and the transistion from .NET to Core almost complete, we should be able to have far fewer breaking changes. Certainly not at the level of 4.x to 5.x.

We really improved our back-compat this release, you can thank @GeoK for this.

Our biggest issue ahead is removing third party libraries from IdentityModel. Newtonsoft is the only one, but that is everywhere and will have some breaking issues. We can wait until we have some better strategy helpers for that.

TokenValidationResult (needed async TokenValidation) was put in the wrong namespace. We could have another one in M.IM.Tokens and derive from it, but now base class definitions will be an issue.