Re: WebID questions -- was: [dane] Call for Adoption: "Using Secure DNS to Associate Certificates with Domain Names For S/MIME"

On 26 September 2012 09:54, Henry Story <henry.story@bblfish.net> wrote:
>
> On 26 Sep 2012, at 10:42, Ben Laurie <benl@google.com> wrote:
>
>> On 25 September 2012 23:19, Henry Story <henry.story@bblfish.net> wrote:
>>>
>>> On 25 Sep 2012, at 23:31, Ben Laurie <benl@google.com> wrote:
>>>
>>>> On 25 September 2012 20:16, Kingsley Idehen <kidehen@openlinksw.com> wrote:
>>>>> On 9/25/12 2:44 PM, Henry Story wrote:
>>>>>>
>>>>>>  I am just ccing Andrei, because Ben
>>>>>> (http://research.google.com/pubs/author9639.html  ) - has found a bug
>>>>>> inhttps://my-profile.eu/  . (see below) My guess is that Ben logged in with
>>>>>> a certificate that is not WebID enabled. So that's a good extra test case to
>>>>>> add. Of course for people like Ben, the failure of having a Logout button on
>>>>>> chrome is going to add to that inconvenience - because having logged in with
>>>>>> a certificate that may not be signed by a CA my-profile.eu knows about, he
>>>>>> won't be able to change his certificate later after having made a new one.
>>>>>
>>>>>
>>>>> Ben,
>>>>>
>>>>> Wondering if you evaluated WebID using any other services or scenarios? Your
>>>>> feedback would be much appreciated.
>>>>>
>>>>> Henry: I keep on telling you, one implementation doesn't canonically reflect
>>>>> WebID. As you can imagine, Ben is time challenged, if he plays with a
>>>>> solution that's pitched as canonical its natural for him to draw blanket
>>>>> conclusions.
>>>>>
>>>>> I continue to encourage you to separate the concept and virtues of WebID
>>>>> from a specific WebID solution that aligns with your personal world view
>>>>> etc..
>>>>>
>>>>> In my world view, the simplest demonstration of WebID's value takes the
>>>>> following form:
>>>>>
>>>>> 1. A resource is published to the Web
>>>>> 2. The resource is ACL protected
>>>>> 3. Existence of the resource is published via email, tweet, blog post etc..
>>>>> 4. A user tries to access the resource -- they fail or succeed subject to
>>>>> ACL membership
>>>>> 5. User requests access to resource by providing their WebID to resource
>>>>> owner -- this is also where signed email are useful since the WebID can be
>>>>> nipped from the senders signed email certificate.
>>>>>
>>>>> In addition to the above, the resource acl document can itself have ACLs
>>>>> that enable a variety of users expand its ACL memebership thereby making an
>>>>> organic social network.
>>>>
>>>> Gah! What does this have to do with WebID? If I substitue "magic pixie
>>>> dust" for "WebID" in the above, well, I have a fantastic example of
>>>> how magic pixie dust secures the web. Great. Now what?
>>>>
>>>> OK, I guess there's one nugget in there: apparently magic pixie dust
>>>> can be nipped from unauthenticated email I sent.
>>>>
>>>> I'm not feeling very enlightened.
>>>
>>> I think Kingsley was pointing out that an important use case of WebID that talking only about web browsers can hide, is for agents exchanging data on the Web. Think about an agent trying to access a resource on a remote web server. With WebID the agent can use his client certificate to authenticate as he accesses the resource, without having to search for a login form to fill out. It is built into the transport layer so is very efficient too.
>>
>> OK, so the point is that WebID identifies you. I think I got that.
>>
>>>
>>> You will find something like the example of this kind of use of WebID in the descriptions of how to use the read-write-web server here
>>>
>>>   https://dvcs.w3.org/hg/read-write-web/
>>>
>>> or in code the following use case gives an idea of how a robot can create an identity using only HTTP, add an ACL which then restricts access to a resources to a particular webid, etc...
>>
>> You realise that I'm not a big fan of ACLs, right?
>
> I did not, no.
>
>> IMO, object
>> capabilities are the better way to go. WebIDs could probably also do
>> those, but then you'd be in the business of managing a very large
>> number of them.
>
> Given that we are using linked data and RDF semantics to express those ACLs it may be that they don't have that much  to do with the ACLs you are used to. So perhaps worth being open about what we mean by ACL. One would have to look at the details of your objects to see if it still holds under the new circumstances.
>
>>
>>>  https://dvcs.w3.org/hg/read-write-web/file/258d2757ef3d/src/test/scala/auth/CreateWebIDSpec.scala#l122
>>>
>>> This type of work is important in Linked Data spaces where linked data crawlers are moving from one host to another following links (see http://linkeddata.org/ )
>>>
>>> But even there user interface issues are important. It is important for the client to know why the server did not accept the authentication. We can use HTTP codes for this, but we could complement them with further information sent back in the response body in addition to a the response codes. So for example looking at http://en.wikipedia.org/wiki/List_of_HTTP_status_codes
>>> the server could return
>>>
>>>  401 Unauthorized -- here the server could say why? did the webid verification process fail?
>>>  403 Forbidden --- perhaps the response could say what foaf:Group had access
>>>  495 Cert Error (Nginx)  - what kind of error? No trusted CA? No WebID ?
>>>  496 No Cert (Nginx)  - ok that says enough by itself. No WebID auth if no cert was sent
>>>
>>> We could then have a very specific test page which when authentication was successful returned
>>>
>>>  200 + an Echo of the certificate sent perhaps
>>>
>>> But we still need to work this out more here. These are just things we could do to improve the data
>>> sent and so could be used to improve human oriented UIs.
>>
>> Once more, I remain unenlightened about the answers to my fundamental questions.
>
> Can we perhaps start back at your fundamental question again? We got sidetracked here a bit because of my-profile.eu
> no working well for you.
>
> The last thing I remember you stating is that authenticating with one ID across multiple sites is in your view a horrendous thing. Is that the fundamental problem?

One of them. And not just my view - the view of many. Here's a
presentation from a colleague that illustrates our thinking on the use
of client certs for authn:
http://tools.ietf.org/agenda/81/slides/tls-1.pdf.

In case its not obvious, the problem is that its a massive privacy invasion.

Next:

1. Usability in the browser is only part of the problem. But
nevertheless it remains a problem.

2. If am all signed up to WebID and I get a new device, how do I get
it signed up? I know your stock response is "you just go through the
flow again" - once for every site I'm registered with - using what to
identify myself? Bear in mind that there has to be a per-site
certificate.

3. Related: if I lose all my devices, how do I recover?

4. How do I revoke access when my laptop is stolen?

5. How do I migrate my existing username/password accounts to WebID?

Note that these are all _usability_ questions - I can easily imagine
technical mechanisms that would achieve them, the question is: how do
you do these things usably?

Received on Wednesday, 26 September 2012 09:30:43 UTC