RE: step 6 spec, section 3.1

 

My first fix is to suggest that one simply splits 1-7 into phase 1: 1,
2,3,4,5,7 and phase 2: 6

 

Phase 2 being yet another DAC logic of authz, guarding access to a resource.

 

My second though was: well do we want to incorporate the role of websso into
this spec?

 

In FOAF+SSL terms, we did the mini-websso demo to characterize adoption
patterns. For henry’s webnsso design, substitute SAML/openid/ws-fedp or
whatever token format someone else designs doing the same thing as all the
others.

 

The way Stephane phrased things was interesting, IF (note IF) one wants to
consider the websso mode not merely an “integration” demo but a intended
design “mode” of the core protocol. Do we consider websso something that
simply re-asserts the webid claim, or something that is the websso (vs TLS)
variant of the same abstract protocol?

 

 

 

 

From: public-xg-webid-request@w3.org [mailto:public-xg-webid-request@w3.org]
On Behalf Of Henry Story
Sent: Monday, February 21, 2011 11:31 AM
To: peter williams
Cc: WebID Incubator Group WG; Stéphane Corlosquet
Subject: Re: step 6 spec, section 3.1

 

Btw, I find it very difficult to read section 6. There are too many
underlines in there, and too much repetition. Is that necessary?

 

On 21 Feb 2011, at 19:39, peter williams wrote:





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.

 

I agree I am not quite sure what this section is about myself.

"If the
<http://www.w3.org/2005/Incubator/webid/spec/#dfn-verification_agent>
Verification Agent does not have access to the TLS layer, a digital
signature challenge must be provided by the
<http://www.w3.org/2005/Incubator/webid/spec/#dfn-verification_agent>
Verification Agent."

 

I think that may have been an attempt to speak about something like
foafssl.org's verification mechanism, but if so I think that should be a
seperate topic. 





 

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?

 

yes, agree we should not confuse authentication and authorization.





 

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.

 

Do you have some text you want to suggest? 





 

 

 

 

Social Web Architect
http://bblfish.net/