hmmm…you just made that up didn’t you 
You are merely explaining key to key encipherement, not key holder to key holder encryption.
You are now trying to “make up new terminology” called “Technical authorization” to describe “encipherement”.
Security?
why?
you will say: because it creates a secure tunnel.
I will say: securing from who?
you will say: securing from any “unauthorized person”
I will say: how do you know the recipient is not the person you are trying to avoid?
You will say: …
because you can’t differentiate between the recipient and the people you are trying to avoid, you can’t give DV neither “security” nor “Trust” indicator. It has to be “Neutral”.
The interpretation and description of what is happening are mine.
The user is always late to the party, arrives when the dinner is already served (the webpage has been downloaded). What is left for the user to authorise? Continued communication. Or to unauthorise continued communication (leave the party). And the dinner may contain surprises, ingredients (files) from third parties, from other domains and other entities, known or unknown. Who authorised those to be downloaded to the client’s device? Not the user, who might not even be aware of them.
In TLS, authentication of the identity of the communicating parties is optional. For “key holder to key holder encryption” you need PGP, where the sender specifies the authorised recipient(s), or something like that.
Because security is… [drumroll]… technical! It’s protocols, ciphers, algorithms etc. The green padlock in Chrome or Firefox simply says that the connection is secure (click on it to see the description), not the sender/recipient at the other end of the tunnel.
To avoid going in circles (repeating what has already been said, since we both know and acknowledge the shortcomings of DV), I will skip to the indicator.
What does a neutral indicator look like? Like in the attached image (from a site with mixed content)? If so, I hope you have a plan for sites with mixed content. What is the plan for HTTP without TLS? Is that also neutral, or insecure? The plan for OV? Like in Dragon 57 (Chrome’s current EV-indicator?).
To communicate security to people with little or no knowledge, and no interest, is far from trivial. How to communicate that the connection is secure, but the guy(s) at the other end of it might not be? It is a balancing act.
And again, a name in the certificate does not guarantee that the guy(s) at the other end of the connection be “secure” (trustworthy). Should browsers ever say “Trusted” (like Opera 12 for EV)?
As long as there are insecure connections (without TLS), the use of (well implemented and configured) TLS deserves to be indicated differently than no TLS. Maybe write “TLS” in the indicator.
Or maybe something most users understand.
Neutral means no indicator
HTTP: should receive a negative indicator.
drumrolls…without users there is no internet…so you trying to create world removing users is not the world the users live in…it is the users who put the computers, certificates, internet connection…its also the user who are doing all this for a purpose…for example…a user is choosing to use encryption for a reason to make sure their data is secure by making sure it only goes to the intended recipient… so first you are trying to make up new terminology with technical authorization and now creating a world with no users…
The user shall be able to identify by indicators if the party is secure or not BEFORE entering the party (before entering private data). That’s what the indicators are for. If the party indicator shows that its secure, user can enter the party (enter details). But if the party indicator is neutral, the user has a hint to reconsider if entering the party or not (enter details or not). That is why the indicator is needed. If the party turns to be “evil” (insecure), the user will not have a happy ending even with his own bodyguards (enciphered connection).
Encipher: Convert (a message or piece of text) into a coded form.
Encryption: The process of converting information or data into a code, especially to prevent unauthorized access.
Unauthorized: Not having official permission or approval.
Do you see the difference?
Encryption: Coded data + authorized party. Secure.
Encipher: Coded data only (that’s it). Insecure.
I think the definitions are pretty clear. What JoWa is describing is the mere and simple process of encipherment because although the connection is through HTTPS, the receiving party might or might not be the authorized party to receive such information. Whereas what Melih is describing is that ONLY if the receiving party has been authorized (within an authorization process) to receive such data, the Encryption process is completed. If the receiving party is unauthorized but receives the information, encryption is not in place only encipherment.
Since Domain Validated certificates only encipher and do not encrypt, the indicator must be neutral.
Is very simple when you read the definitions.
That makes sense. Insecure should not be neutral. At least Chrome and Firefox have began to indicate that the connection is insecure login field on the page. The question is when users are ready for such an indicator on every insecure connection. Currently about forty percent of all connections are not secure. Warning fatigue is to be expected if the indicator were introduced today. More TLS is needed. That will mean more DV.
Once the insecure connections are few enough to mark them as not secure (a negative indicator), it will not make much sense to use a positive indicator for secure connections. If negative means not secure, neutral will mean secure. And that includes more than DV. Even EV is not very effective as defence against phishing, it seems. (And some mobile browsers have no special EV-indicator.)
“Jackson et al. asked study participants to identify phishing attacks and found that ‘extended validation did not help users defend against either attack’”.¹
To protect against phishing, we need good phishing protection, not different certificate indicators.
Am I not admirably and impressively creative!
Eliminate the messy users, and you eliminate the problems!
But sadly, or luckily, I did not successfully eliminate the users. And I never tried to. What I am trying to do is to see what users really do, and what happens automatically, like the authorisation, which happens silently when connecting to a server.
Also, average users care much less about various indicators than we who discuss them.
1 https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/45366.pdf
Who gave you authority to dictate how people should answer?
do differentiate between paid and free research 
Google has been reported to pay for these research…
If people don’t care about it, then why use it in the first place…you can’t have it both ways…
google use it because people do care about it…but they don’t want to admit it…because if they admitted it…then they will be at the wrong side of the argument…
so that’s why they continue to use it while claiming users don’t care…which is an oxymoron… if people don’t care…then remove it!!..But we know people do care…that’s why they continue using it.
I don’t understand your reasoning.
“google use it because people do care about it…but they don’t want to admit it”
Why would they not want to admit that people care about something they have always been doing, if that is indeed the case?
Chrome has more than one billion users. If Google makes bad security decisions for Chrome, it soon gets problematic at a very large scale. Very bad for users means very bad for Google.
Google did not introduce the padlock. I don’t know who did, maybe Netscape. Google was late to the party (2008). In the 1990s, when Netscape created SSL, the situation was very different. Very very few sites used secure connection, and then it made sense to indicate that. And so it did for a long time. Now secure is dominating, and insecure is becoming an exception. Then it makes sense to reverse the indicators. Use a negative indicator for insecure connections (until they disappear), and no indicator for secure connections, which are now standard.
To remove the positive indicator for secure connections, without adding a negative indicator for insecure connections would not make sense. Also, to use a negative indicator for insecure connections would make users get used to it and ignore it, if it is done too soon (when there are still quite many insecure connections).
“But we know people do care…that’s why they continue using it.”
How do we know that?
Recently Ryan Sleevi posted Google’s plans for indicators in Chrome¹. Here is an excerpt:
“Thus, our focus is on introducing negative indicators that accurately reflect when there is no connection security, while also working to reduce the confusion introduced by the myriad of positive indicators by aligning to a single, neutral state.”
It’s a shame that browser providers cannot get together and have a single plan for displaying the security a website has.
Without this commonality users will just continue to be baffled regarding the security of any site.
That’s my tuppence worth on that debacle 
Thats because they know they shouldn’t show a positive indicator for DV. Its wrong.
Thats why they don’t admit it.
I see, you were talking about DV specifically. I don’t recall anyone from Google (besides Ryan Hurst) ever doing that, and as soon as all insecure connections are marked as not secure, there will be no positive indicators for secure connections (including, but not limited to, DV), “a single, neutral state” in Ryan Sleevi’s words.
When you asked me, you wanted me to answer you with specifics… correct? Same here.