- From: <henry.story@bblfish.net>
- Date: Mon, 10 Mar 2014 13:12:13 +0100
- To: Timothy Holborn <timothy.holborn@gmail.com>
- Cc: public-webid <public-webid@w3.org>
On 10 Mar 2014, at 10:35, Timothy Holborn <timothy.holborn@gmail.com> wrote: > Agent = a certified or authorised actor of a legal entity? An Agent is what you mean by an Actor. We could have used actor, but we have widely used the term agent. > > A machine or account is not a legal entity; vs. a natural or incorporated legal entity. Therein, a legal entity provides a machine the authority to do something on it's behalf.... > > Ie: I authorise my rww data space to share specific protected resources / data, to others (inc other agents) on my behalf without human intervention on an event basis? > > A bit WAC (or alternative) but hope u see the webID/foaf/IoT (Internet of things / web of things) concept therein... yes, you could have a WebID for a machine, or service. > > Timh. > > Sent from my iPad > >> On 10 Mar 2014, at 8:23 pm, "henry.story@bblfish.net" <henry.story@bblfish.net> wrote: >> >> The draft-thomson-tls-care comes with a draft-thomson-httpbis-catch. >> I wrote to the https-bis mailing list with the following suggestion. >> >> Begin forwarded message: >> >>> From: "henry.story@bblfish.net" <henry.story@bblfish.net> >>> Subject: Re: FYI: proposal for client authentication in TLS >>> Date: 10 March 2014 10:16:01 CET >>> To: Martin Thomson <martin.thomson@gmail.com> >>> Cc: HTTP Working Group <ietf-http-wg@w3.org>, Tim Berners-Lee <timbl@w3.org> >>> >>> >>>> On 9 Mar 2014, at 08:37, Martin Thomson <martin.thomson@gmail.com> wrote: >>>> >>>>> On 8 March 2014 11:39, Martin Thomson <martin.thomson@gmail.com> wrote: >>>>> Pursuant to our discussion on TLS renegotiation, I've submitted part 1 >>>>> of the solution I proposed as an internet draft. >>>>> >>>>> http://datatracker.ietf.org/doc/draft-thomson-tls-care/ >>>>> >>>>> If we agree to a mechanism whereby we augment the 401 status code with >>>>> a "go away and make a new TLS connection with client authentication", >>>>> then this is necessary, so that the server knows to request a client >>>>> certificate. >>>> >>>> Now with part 2: >>>> >>>> http://datatracker.ietf.org/doc/draft-thomson-httpbis-catch/ >>> >>> I really like both of these. I allready responded on the TLS mailing list >>> about draft-thomson-tls-care [1]. For draft-thomson-httbis-catch I would >>> like to suggest an improvement that would be essential for "self-signed" >>> or rather "unknown server signed" certificates, i.e., certificates signed >>> by some server that is not a CA. This allows for much more widespread >>> creation of client certificates, since they don't anymore need to be >>> verified by a few CAs, but instead allows the deployment of a web of >>> trust - a linked data web of trust to be precise. This allows one client >>> side certificate to be used to sign on to any web site. >>> >>> A WebID is just an http(s) URL that refers to an Agent ( human, robot, >>> organisation, ...) We have defined it in the spec "WebID 1.0" [2]. One >>> can then place a WebID in the Subject Alternative Name (SAN) field of an X509 >>> certificate as shown in WebID Authentication over TLS [3] ( or even in the >>> Issuer Alternative Name field (IAN)). The last spec relies on TLS as it is >>> currently, but would be redundant if draft-thomson-httpbis-catch went through. >>> (Until wide deployment of TLS1.3 which I suppose may take some time). >>> >>> Now I am not absolutely sure where this improvement I want to suggest, >>> needs to be added: at the HTTP layer, or at the TLS layer. Currently TLS >>> allows a server to specify using the certificate_authorities list what >>> the list of Certificate Authorities the server accepts, so that the client >>> does not send Certificates that are not signed by one that is known to the server, >>> and which the server would then have to refuse. >>> But with WebID Authentication we don't need a CA, so it would be nice to be >>> able to specify that the server knows how to do WebID verification, ie part >>> 5 and 6 of >>> http://www.w3.org/2005/Incubator/webid/spec/tls/#authentication-sequence >>> bB >>> If in TLS the server sends the empty certificate_authorities list. But that >>> is too wide, since that means the client can send ANY Certificate. The >>> server may not know what to do with most of them ( other than perhaps >>> identify the user indirectly by the public key, but that is only minimally >>> interesting - it does not allow one to build a web of trust ). >>> >>> My guess is that since this could evolve faster than the TLS layer, it may >>> be better if this were done in the HTTP header. So perhaps a header like >>> >>> WWW-Authenticate: ClientCertificate,SAN=WebID >>> >>> would do. One could also imagine a >>> >>> WWW-Authenticate: ClientCertificate,IAN=WebID >>> >>> so that services with a lot of WebIDs could allow people to verify certificates >>> by verifying the issuer. A client seeing this would know that if the >>> server sent the empty certificate_authorities list, that it could filter its >>> available certificates by those that have the SAN or IAN fields filled in. >>> >>> We have quite a few implementations of WebID on numerous servers, and in >>> pretty much every language, and we are finding it very useful. To get >>> a full overview of how this ties into a bigger picture including Web Access >>> Control, other authentication schemes, Linked Data Protocol, etc... see our main >>> intro page >>> >>> http://www.w3.org/2005/Incubator/webid/spec/ >>> >>> Hope this helps. >>> >>> Henry >>> >>> >>> [1] http://www.ietf.org/mail-archive/web/tls/current/msg11449.html >>> [2] http://www.w3.org/2005/Incubator/webid/spec/identity/ >>> [3] http://www.w3.org/2005/Incubator/webid/spec/tls/ >>> >>> >>> Social Web Architect >>> http://bblfish.net/ >> >> Social Web Architect >> http://bblfish.net/ >> >> Social Web Architect http://bblfish.net/
Received on Monday, 10 March 2014 12:13:19 UTC