- From: peter williams <home_pw@msn.com>
- Date: Mon, 21 Feb 2011 10:39:29 -0800
- To: "'WebID Incubator Group WG'" <public-xg-webid@w3.org>
- Message-ID: <SNT143-ds5FF42E718FF6C28839C0D92D90@phx.gbl>
http://www.w3.org/2005/Incubator/webid/spec/#authorization step 6 in section 3.1 needs to be eliminated, or otherwise fundamentally re-characterized. Authentication must complete (having done current step #7) before one attempts to perform authorization. In a typical security course, a student who intersperses authentication with authorization generally fails the class (often railing about the injustice, and how everyone is stupid.because they ignored KISS). One needs the assurance of authentication, so that authorization has a basis on which to stand. HTTP web-auth is a famous case of poor security architecture, conflating topics. Now, if it helps, within authentication there is indeed the step of getting assurance that the authentication claims are valid. (If authentication depends on a control system, you need evidence that the control system itself is not being spoofed.) The act of garnering assurance is often confused with the term: authorization. You hear folks new to the space say things like: I need to know the authority for authentication was authorized, else how can I trust it? If one wants a professional-level conversation with security specialists (what are these anyway? And, do they include the 75,000 CISSPs of ISC2?) don't fight the security ontology. It's got 30+ years of thought built into it, 15 years of which thought long and hard about applying it to the [commercial] web. In summary, step 6 is wrong formally, and its wrong in order. Its placement implies that some about SSL mutual authn should occur, long after the webid has been obtained (from) a cert) and a document recovered. Its wrong if its trying to capture something about authz, since authn has yet to complete.
Received on Monday, 21 February 2011 18:40:11 UTC