Re: FYI: proposal for client authentication in TLS

yes; perhaps confusing.

i understand use of ‘actor' is a foaf issue.

Below you state agent = Agent ( human, robot, organisation, …) - therein a mixture between legal entities and machines / services / service entry points perhaps also (etc.)

The term agent has a very broad application.  actor might best mean legal entity or FOAF:Person?  Therein, does person mean legal entity (i.e. natural or incorporated entity?) and agent mean something authorised by legal entity… 

Vint talks alot about his wine sensors; i think also, protecting his wine sensor network from hackers, etc.  I imagine he could issue his sensor controller a WebID; which could then be linked to whatever his using as a conductor (like an orchestra) to secure his sensor info… 

Whether that’s done directly or indirectly; the sensor controller in that example would be an agent. 

or; organisation is historical society (person? - incorporated legal entity); they have a heritage library (agent) that is capable of issuing ACL’s (i.e. public metadata contributions) via WebID Auth rules (Geographic, Community, etc) to other agents (i.e. a national heritage aggregation site, or an interactive educational environment served off a server somewhere) or a person (family member doing genealogical research for example)…

found https://www.youtube.com/watch?v=ZYAJaOVuyxI too

timh

On 10 Mar 2014, at 11:12 pm, henry.story@bblfish.net wrote:

> 
> 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/