Re: FYI: proposal for client authentication in TLS

oh - typo on front page: 

http://www.w3.org/2005/Incubator/webid/spec/

it should allow flexbile access control that is both easy for humans and machines to use and understand,

vs.
it should allow flexible access control that is both easy for humans and machines to use and understand,

On 10 Mar 2014, at 11:37 pm, Tim Holborn <timothy.holborn@gmail.com> wrote:

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