Re: comments on draft

Ok I have pushed in some changes to the spec based on David Chadwick's recent comments.
You can see the diff here.

   https://dvcs.w3.org/hg/WebID

This covers all the points below but not the WebID trust model points. I need to look at those more carefully.
The original mail was here:

  http://lists.w3.org/Archives/Public/public-xg-webid/2011Dec/0140.html


On 16 Dec 2011, at 16:08, Henry Story wrote:

> Thanks a lot David for this detailed feedback.  This is very helpful to the editors.
> 
> On 16 Dec 2011, at 14:49, David Chadwick wrote:
> 
>> Comments on WebID 1.0 (Draft 6 Dec 2011)
>> David Chadwick, 13 Dec. 11
>> 1.	We need a section called Trust Model which summarises the trust that is needed in the system. See Appendix 1 for suggested text.
> 
> thanks, that is very useful to know.
> 
>> 2.	We need to add definitions of Identification Agent, TLS Agent and WebID Verifier to section 1.2
> 
> - "Identification Agent" needs to be removed I think and replaced by "Client" and perhaps "Subject" at one point.
>  This was the old terminology I found made the document very difficult to read before. And I must have forgotten to remove it 
>  everywhere
> - "TLS Agent" is used as a synonym for "TLS Service".
>   Question: should I use TLS Agent, TLS Service, or have both? 
> - "WebID Verifier" is defined as synonym of "Verification Agent" in the definitions.  I found it useful for a few terms to have
>   Synonyms, so that the language did not become too wooden.
> 
>> 3.	Subject definition contains a couple of errors: princiap -> principal, and lisibility is not an English word, use readability instead.
> 
> Thanks! Easy fix.
> 
>> 4.	Why does Key Chain Agent have this name it does? Specifically, why is Chain in the name as its functionality does not seem to involve building or verifying certificate chains. Wouldn’t Key Ring Agent or Key Store Agent of simply Key Agent be better?
> 
> No idea which would be better. In this case I just chose the first one that came to mind. Keychain, probably came to mind because the Apple tool that stores all keys is called the Keychain.app . There the image is clearly of a chain of keys people could have in their pockets, not the chain of certificates.
> 
> But I had not thought of the TLS association of key chain with certificate chains. So given that we are speaking to TLS people here one of those other terms may be better. A bit difficult to tell. We'll try to work that out.
> 
> 
>> 5.	The definition of Guard is not quite correct. Suggest change to “..and decide if it needs to be authorised by looking at the access control rules. If the client needs to be authorised, it can first request identification and authentication and use the WebID Verifier to compete the identity checks. Finally it checks the access control rules to either grant or deny access.”
> 
> yes, that reads better. In fact that is what I wanted to write :-)
> 
>> 6.	The Issue about the Issuer of certificates. We definitely do not want O=FOAF+SSL… to be the only certificate issuer. Besides being a bottleneck to performance and a single point of failure, it also represents a choke point that has ultimate control over who can have certificates. This is very undesirable. Furthermore it is not needed from a trust perspective, since the issuer does not need to be trusted (see Trust Model) and can be anyone. Finally if a way is needed of signalling WebID certificates as being different to other  X.509 certificates, then we should define a new critical extension, say “FOAF+SSL” which means that relying parties must either understand this extension or reject the certificate (which is probably the behaviour you desire. If not, make the extension non-critical).
> 
> yes this is one of those issues that is still open ISSUE 59
> http://www.w3.org/2005/Incubator/webid/track/issues/59
> 
> Neither critical nor non critical extensions in X509 are really helpful here as the only way a server can have an effect on the client is by sending a  certificate_authorities list of Distinguished Names when requesting a client certificate.
> 
> But you are quite right:
> 1. We should not give the impression that there is a DN that is central
> 2. The way to have a standard DN was to have the the O=FOAF+SSL CA be an open CA, with a publicly known private key so that everybody
>    can mint certificates with it.
>  This is something the feasibility of which we should explore in detail next. 
> 
> 
>> 7.	3.2.5 Authz. We could add an example, based on roles or group memberships, which would show the flexibility and power of the system. Suggested text is “For example, suppose a service wishes to grant access to its resources to only those WebID users who can prove membership of a specific group or role e.g. only to users who Bob says are members of the WebID experts group. The service would first need to know the WebID of Bob, and also the URL of the page where Bob stores this information e.g. https://bob.example/webIDexperts. Then the service would read this page, which contains an RDF description of the members of the group e.g. <rdf:Description rdf:about="https://bob.example/webIDexperts">
>> <member> “https://mary.example/profile#me”</member>
>> <member> “https://joe.example/me”</member>
>> <membershipList> “https://acme.co.uk/employees”</membershipList>
>> </rdf:Description>
>> ISSUE. We should be able to nest groups of users, recursively. The last entry is an incorrect attempt to do this (since we need to specify both the WebID of the list owner and the page where the list is described).
> 
> yes, I agree that a few non controversial examples would be useful. (Currently though section 
> 3.2.4.3 Authorization is a bit too deeply nested to be able to put much in there...)
> 
>> 8.	Page 15 first line. Why do you assert that “People don’t feel comfortable authenticating to a web site on the basis of a certificate alone…..” Where is your evidence for this? Can you reference a research paper that presents this?
> 
> Ok, so that is badly expressed. 
> What I meant is that if you go to a web site and the browser first asks you for a certificate before you even can see the page then you are breaking the expectations that people have built up over the past 20 years, namely that you go to a site look around and then login if you want to. If you go to a site and are asked for your identity before you can see the page then you don't know really WHO you are identifying to. Robots will know, because they read the certificate, but humans don't do that, so the experience is for the human that he is being asked first for authentication.
> 
> I don't think we need a research paper to show this. But clearly this has to be explained in mode detail.
> 
> 
> 
>> 9.	Minor editorials.
> 
> (just a minor detail on your notes below: our spec is not numbered by page numbers, it would be easier to refer to paragraph numbers.)
> 
>> a.	p5. WebID defn “Agent as the controller” -> “Agent who is the controller” and “the document” -> “this document”.
> 
> ok
> 
>> b.	p9. can or not -> can or cannot
> 
> ok
> 
>> c.	p11 (it ->(if
> 
> thanks
> 
>> d.	p13 step 2. If the client needs authentication and authorisation.
> 
> ok
> 
>> e.	p14 a claimed WebIDs
> 
> ah yes, the s is too much
> 
>> f.	p16 an https WebID -> an http WebID
> 
> I think this is correct. but perhaps instead of writing HTTP one should write https:// webid ...
> 

Social Web Architect
http://bblfish.net/

Received on Monday, 9 January 2012 16:44:50 UTC