- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Wed, 29 Oct 2014 19:46:29 +0100
- To: Mike West <mkwst@google.com>
- Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>, Mark Nottingham <mnot@mnot.net>, Brad Hill <hillbrad@gmail.com>, Dan Veditz <dveditz@mozilla.com>, Wendy Seltzer <wseltzer@w3.org>
On Wed, Oct 29, 2014 at 4:06 PM, Mike West <mkwst@google.com> wrote: > 2. Moving the TLS checks to a new attribute on the Request's client, and on > the Response, which Anne was kind enough to add to Fetch for me. It's > currently named "authentication state", which probably needs some > bikeshedding, but the name shouldn't block progress on MIX. Authentication is confusing with HTTP authentication. Secure does not work because there is no such guarantee. Trusted does not work because trust is up to the end user. Validation might work, based on CAB's "Domain Validation". All these terms get irky when you apply them to resources created from blob or data URLs. > I don't believe there are any substantive controversies remaining, but if > I've missed anything, this CfC is a nice forcing function to get it out into > the open. :) I think it is still problematic that it tries to make claims based on origins. I thought the idea was to do away with that and instead base those checks on objects that can actually assertions about involvement of TLS or localhost, namely responses and environment settings objects. -- https://annevankesteren.nl/
Received on Wednesday, 29 October 2014 18:46:56 UTC