The existing behavior with -Credential is left untouched. When not supplying -Authorization , A user will not receive an error when using -Credential over unencrypted connections.

We could write non-terminating error or just terminating error w/o explicitly -AllowUnencrypted. I think we should. Security is in high priority.

Why 'Authorization' ? Right term is 'Authentication'. It's confusing. I think better 'AuthorizationHeaderType' and '-AllowUnencryptedAuthentication'.

We could write non-terminating error or just terminating error w/o explicitly -AllowUnencrypted.

I considered that but I wasn't sure if that should be done in this PR or something separate. This PR is adding new features only without altering existing behavior. It's still not clear to me what is too much for one PR and what is not.

Why 'Authorization' ? Right term is 'Authentication'. It's confusing. I think better 'AuthorizationHeaderType' and '-AllowUnencryptedAuthentication'.

I would take that up with IETF. They are the crazy ones that decided that Authorization is the correct term here regardless of what the dictionary begs to differ. 😆

I think -Authorization is fine. I asked for feedback in the issue and there seemed to be an agreement on it being ok. The originally proposed parameter was -Authentication. To most people the words are interchangeable. But to those familiar with HTTP, Authorization is less ambiguous. 'AuthorizationHeaderType' or 'AuthorizationType' is a bit verbose and redundant in my opinion.

'-AllowUnencryptedAuthentication' How about '-AllowUnencryptedSecrets'? Assuming there may be more uses outside of the 'Authorization'. I wouldn't want to have -Authorization and -AllowUnencryptedAuthentication mixing. so if one is Authorization so should be the other unless we decide on something completely different.

Travis CI fail due to #5062

I believe that the use of Authorization term on the client side is a crude distortion of its classical definition of AAA. Steve Lee (@SteveL-MSFT) pointed out this in the Issue discussion. When I started with the PR, I came here in a bit of confusion about what we wanted to do on the client side?! Turns out we need classical authentication by means of setting HTTP authorization header. We have to be more precise in using long-known terms to prevent users from being misled.
So I think 'AuthorizationHeaderType' is good. IntelliSense help us with long parameters. But '-AuthHeaderType' is also good. Perhaps -AllowUnencryptedAuth too.

What is the consensus on the parameter names? leave them? change them?

I think adding "HeaderType" is more of an impl detail than the average user will care about. And while the header is named Authorization, in articles and papers the overall process is referred to as Authentication as in Basic Authentication, Digest Authentication, etc. Perhaps you just call the parameter -Auth and let the user interpret it as they see fit. :-)

To be consistent with other cmdlets, I think we should call it -Authentication. People can use -Auth as it will resolve correctly.

I agree with Steve Lee (@SteveL-MSFT) - really a client do an authentication.

Ok. I have switch Authorization with Authentication,

Steve Lee (@SteveL-MSFT) Ilya (@iSazonov) can I get some guidance on the public enum for the -Authentication parameter? Should we do this? What namespace do I use? Suggestions for name (WebCmdletAuthenticationType?) I assume the file location is in the WebCmdlet folder?

I think an enum is good because we rid from many string constants and string comparitions, our code becomes more readable. I only worry about extensibility.
It seems namespace Microsoft.PowerShell.Commands is good.
WebCmdletAuthenticationType - we could use the type not only in web cmdlets.

Mark Kraus (@markekraus) Please correct the PR header and description (Authentication).

Ilya (@iSazonov)

we could use the type not only in web cmdlets.

Then we would probably need to include logic that limits the subsets allowed by the authentication parameter. For example, if this enum were used in another cmdlet and it was extended to include Shiboleth for support in that cmdlet but the web cmdlets lack logic to handle that.

It's overkill. I mean, this is a public type and users can use it. Although it may be better to mark it as obsolete and document that it is for internal use only.

Ilya (@iSazonov) I guess it is overkill. I looked a how other enums are being implemented for parameter options and have tried to follow their conventions. I chose the name WebAuthenticationType to make it a bit more generic and to give it some clarity vs other Auth enums used in various other cmdlets.

Steve Lee (@SteveL-MSFT) is a comittee review required for the new public enum or is your blessing good enough?

Ilya (@iSazonov) and Steve Lee (@SteveL-MSFT) the other outstanding question in this PR is to add a warning to the legacy -Credential usage when being sent over non-HTTPS schemes. Should this be done in this PR or in a separate PR?

You can add one commit for the warning :-)

Mark Kraus (@markekraus) I'll see if I can get a quick committee review on this

@PowerShell/powershell-committee brief discussion is that adding an enum used as a parameter type doesn't require committee approval, code review feedback is sufficient. The current name and namespace seems appropriate to me.

Mark Kraus (@markekraus) Thanks for your contribution. I'll allow 24 hours for the code owners to review. Dan Travison (@dantraMSFT) , Paul Higinbotham (@PaulHigin) , & James Truher (@JamesWTruher)

😄 I've been dragged the PR.