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

hi ben,

it might help if you think about webID as a linked data analogy to
ssh-public-key.

using a public ssh key you can log into all servers that have your
public key in say /root/.ssh/authorized_keys.

using ssh only the public key is sent to server for authentication.
using webid the public key (inside a certificate) is sent along with the
webID profile URI, first to check weather the public keys in the cert
and in the webID profile document match and secondly to retrieve info
about the user (name, depiction, whatever...)

using ssh the file authorized_keys corresponds to the simpliest form of
an ACL (SPARQL-wise this would be : if(ASK public_key in
authorized_keys) then access granted)).

a valid certificate where the public key matches the one from the webID
profile document will grant you access to something only in the only in
the rarest cases, since this is only the authentication step.
authorization depends on what you wanna do with an authenticated user
(=webID-foaf-URI).
webID realm [1] uses this information to check for roles associated with
that webID-foaf-URI and grants access to based on these roles to
different web-resources (webapps, jsps). but you can also send that
webID-foaf-URI through any number of ACLs, where the advantage is that
this process is not limited to looking up keys in a file, but to one's
phantasy.

for the rest of your questions (lost, stolen, migrate) you more or less
have the same problems like with ssh-public-keys or keys in general.
you always can get yourself into troubles with keys, no matter how smart
the system is.. 
if you set password-authentication to no and delete your public key, you
have a problem, same as if you loose the physical key to a door, which
cannot be reproduced.


wkr turnguard 

[1] http://webid.turnguard.com/WebIDTestServer/






On Wed, 2012-09-26 at 10:15 +0100, Ben Laurie wrote:
> 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?
> 

-- 
| Jürgen Jakobitsch, 
| Software Developer
| Semantic Web Company GmbH
| Mariahilfer Straße 70 / Neubaugasse 1, Top 8
| A - 1070 Wien, Austria
| Mob +43 676 62 12 710 | Fax +43.1.402 12 35 - 22

COMPANY INFORMATION
| web       : http://www.semantic-web.at/
| foaf      : http://company.semantic-web.at/person/juergen_jakobitsch
PERSONAL INFORMATION
| web       : http://www.turnguard.com
| foaf      : http://www.turnguard.com/turnguard
| g+        : https://plus.google.com/111233759991616358206/posts
| skype     : jakobitsch-punkt
| xmlns:tg  = "http://www.turnguard.com/turnguard#"