W3C home > Mailing lists > Public > public-xg-webid@w3.org > December 2011

comments on draft

From: David Chadwick <d.w.chadwick@kent.ac.uk>
Date: Fri, 16 Dec 2011 13:49:41 +0000
Message-ID: <4EEB4C75.4090506@kent.ac.uk>
To: public-xg-webid@w3.org
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.
2.	We need to add definitions of Identification Agent, TLS Agent and 
WebID Verifier to section 1.2
3.	Subject definition contains a couple of errors: princiap -> 
principal, and lisibility is not an English word, use readability instead.
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?
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.”
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).
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>
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).
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?
9.	Minor editorials.
a.	p5. WebID defn “Agent as the controller” -> “Agent who is the 
controller” and “the document” -> “this document”.
b.	p9. can or not -> can or cannot
c.	p11 (it ->(if
d.	p13 step 2. If the client needs authentication and authorisation.
e.	p14 a claimed WebIDs
f.	p16 an https WebID -> an http WebID

Appendix 1. WebID Trust Model.
Assumptions: There is a server somewhere on the Internet that contains a 
web page identified by a Web ID URL. This web page contains a public key 
and the Web ID URL. The trust model for Web ID is as follows:
1.	The DNS is trusted to correctly resolve a WebID URL into the correct 
IP address for the server hosting the WebID URL.
2.	The Internet routing infrastructure is trusted to correctly route 
messages to destination IP addresses.
3.	A server hosting a WebID URL is trusted to only allow the subject 
holding the private key corresponding to the public key published at 
this URL to modify the contents of this page, but not to modify the 
referent component of the WebID URL published on this page i.e. the 
WebID URL minus the trailing fragment.
4.	This server is further trusted to ensure that the subject’s public 
key certificate containing the public key published at this URL contains 
this WebID URL in its subjectAltName extension (Q. is this the whole 
WebID URL or the referent part only?). Note. The server is effectively 
acting as a Certification Authority, verifying that the public key and 
the subjectAltName belong to the subject who “owns” the page at this URL.
5.	A Key Store is trusted to not divulge the private keys that it holds 
to anyone other than the key store owner i.e. the subject of the 
corresponding public key certificates.
6.	Subjects are not inherently trusted, and are assumed to be capable of 
inserting any WebID URLs into any WebID certificates. Subjects may also 
divulge their private keys to someone else without a relying party being 
able to determine that this is the case. Note. It is outside the scope 
of the WebID specification how a relying party determines whether a 
subject is trusted or not
7.	A certificate verifier has trust in the cryptographic components to 
correctly verify certificate chains mathematically. However, none of the 
issuers of the certificates in a WebID Certificate chain need to be 
trusted. If a WebID Certificate is not self-signed, then the certificate 
chain will have to be verified up to either a self-signed certificate to 
ensure that no contents of any of the certificates in the chain have 
been tampered with, or a trusted certification authority.
8.	The outcome of the WebID trust model is that a relying party can 
trust that the client is identified by the WebID and does possess the 
private key corresponding to the public key in the WebID certificate.


David W. Chadwick, BSc PhD
Professor of Information Systems Security
School of Computing, University of Kent, Canterbury, CT2 7NF
Skype Name: davidwchadwick
Tel: +44 1227 82 3221
Fax +44 1227 762 811
Mobile: +44 77 96 44 7184
Email: D.W.Chadwick@kent.ac.uk
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

Received on Friday, 16 December 2011 13:50:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:39:50 UTC