Chris Ross

> With this code do you still need forwarders? You may still need them for the scheme ('https'), or you could set that the same way if you always require...

@brentschmaltz talk to @rynowak, he has some thoughts about how this should be exposed.

Somewhere around here? https://github.com/aspnet/AspNetCore/blob/86728ecc17c339f699d21c8abd5ee93037b51a1e/src/Security/Authentication/OpenIdConnect/src/OpenIdConnectHandler.cs#L1213-L1220 Since this is custom data I assume you'd need an extension point where people could manipulate it to suite their scenarios.

Oh, JwtBearer would be here: https://github.com/aspnet/AspNetCore/blob/4cb86bc15160e493e6331190da9973736f0fc240/src/Security/Authentication/JwtBearer/src/JwtBearerHandler.cs#L91-L99

I agree that the PII model is very confusing for users, `IDX10205: Issuer validation failed. Issuer: 'System.String'. Did not match: validationParameters.ValidIssuer: 'System.String' or validationParameters.ValidIssuers: 'System.String'` looks like a bug, not...

Is there any integration available with Microsoft.Extensions.Logging? That would be helpful to ASP.NET Core consumers, and others.

> @Tratcher we currently use System.Diagnostics.Tracing.EventSource, does Microsoft.Extensions.Logging play well with that OR would we need to re-tool? @shirhatti?

> @Tratcher / @kevinchalet , was #1725 helpful to that end. Agreed we still have improvements to be made around this but hopefully that was a step forward on this...

Which settings did you have in mind? I hope they're only the diagnostic ones.

Changing functional parameters based on some envronmetal state seems dangerous, you may unintentionally affect other applications on the machine. If you restrict it to diagnostics at least you won't break...