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.