Re: [foaf-protocols] WebID status recap?

On 14 June 2013 18:23, Henry Story <henry.story@bblfish.net> wrote:

>
> On 14 Jun 2013, at 17:42, Peter Williams <home_pw@msn.com> wrote:
>
> that's a big change - doing away with the notion that https (because its
> ubiquitous ) had/has some mystical privacy-enhancing power; or that certs
> in x.509 or jwt form have some special properties.
>
> Folks now know now generally that crypto solves nothing (if the trusted
> vendors are not so trustworthy as previously believed). Folks do now assume
> that AT ONE LEVEL OR ANOTHER technology subject to public policy (and that
> includes the web) is tracking you; and the crypto present in
> commodity-grade https does nothing to address that. IN fact, its there to
> facilitate and make it easier to accomplish.
>
> The more security engineering folks should have been taught that crypto is
> about the exact opposite - being actually all about (security policy)
> accountability. I.e. track that document number, track that distribution
> list, track that set of edits, and track those changes in security markings
> (every 10 years...). Its there to impose “double entry” bookkeeping, for a
> distributed set of books.
>
> I have seen three security model and philosophies applied to FOAF: i)
> PGP-ish key distribution that actually used the metadata-approach to
> design, ii) the DARPA-sponsored use of SPARQL-like queries to define remote
> operation protocols, iii) webid, and its early attempt to bridge the 2 2
> worlds of information queries and data protocols while not straying from
> the assumptions of REST - that defines how the web world is supposed to
> build such bridges.
>
> is obscurity number four? is his the return of the world of personal
> codebooks, semantic and semiotic countermeasures? This is likely to be more
> successful than pitching a defense based on using machines to guard against
> machine attack.
>
>
> The idea of security through Obscurity is purely Melvin's own.
>
>
> As always security scheme design is about designing for the complexity of
> decoding. So design encoders that force use of (time-) expensive decoders.
> In that window of complexity, you have a security measure (the time it
> takes to decode). Your security model has to be based on the military
> notion that: I want it secret for X time (after which the metadata has
> little value, anyways).
>
>
> Sent from Windows Mail
>
> *From:* Melvin Carvalho
> *Sent:* Friday, June 14, 2013 8:40 AM
> *To:* Peter Williams
> *Cc:* public-webid Group, Henry Story,
> foaf-protocols@lists.foaf-project.org
>
>
>
>
> On 14 June 2013 17:20, Peter Williams <home_pw@msn.com> wrote:
>
>> When it was written, the public didn't know the meaning of the term
>> metadata. Now they do - educated by means of showing privacy
>> vulnerabilities specific to a web “founded on” insecure metadata.  And they
>> have a good intuition of specifically -”social” class of threat models
>> specific to metadata.  They also have a mental model of how vendors,
>> contractors and security professionals may be part of the threat (to
>> personal privacy invasion); willingly or otherwise.
>>
>> For a specifically social trust protocol the change in the public’s
>> perceptions and education level on the threats they face does changes the
>> (scope of the) problem. The freedom box is now perceived to be not so free
>> (depending on context); and may be actually rather worthless, unless you
>> count the “feel good” factor.
>>
>> How does WebID - in its updated philosophy - address the newly revealed
>> threat of specifically institutional snooping?
>>
>
> WebID is no longer tied to X.509 certs, it's just a linked data
> identifer.  This is useful for discovery, friending, annotation and a whole
> host of other things, one of which is auth.
>
> WebID+TLS is an X.509 based method to use RSA keys to authenticate over
> TLS.
>
> WebID+WebKeys is a method to use any kind of key to authenticate over any
> protocol including javascript/websockets.
>
>
> WebID Simple (proposed) is a way to identify and authenticate via security
> by obscurity
>
>
> Melvin is alone to back this here I think.
>
>
> You can add many more auth systems onto this list, as you come up with
> them.
>
>
>
> It's nice to see Melvin list all these new possibilities. Given that
> he never implements any of these protocols, and only suggests
> that others develop and implement them, his enthusiasm is always
> the same as on the first days of WebID, and clearly will still be
> in 10 years time.
>

Henry, I love your optimism.

Implementing security by obscurity is trivial.  Send someone an unguessable
URI out of band, and allow them to identify their WebID via a header.

The fact that only this person has that URI allows relatively safe
communication.


>
>
>
>
>
>>
>> If I look back at the concept of the VeriSign cert in netscape-grade
>> https, it was specifically intended (by VISA) to be a feel good security
>> technology, note, no ifs, no buts, no caveats. It was to change nothing
>> (but make you feel good about the new internet threats that came into the
>> concept set of the general public, circa 1994).
>>
>>
>> Sent from Windows Mail
>>
>> *From:* Henry Story
>> *Sent:* Friday, June 14, 2013 2:36 AM
>> *To:* public-webid Group
>> *Cc:* foaf-protocols@lists.foaf-project.org
>>
>>
>> On 13 Jun 2013, at 22:31, Henry Story <henry.story@bblfish.net> wrote:
>>
>> > Yes, we have two specs:
>> >
>> > https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/tls-respec.html
>> > https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/identity-respec.html
>> >
>> > I am not sure why we don't get the full html view anymore.
>> > Anyone know what we need to change?
>>
>> I fixed these. The problem is related to the move to the new
>> respec.js https://github.com/darobin/respec/
>>
>> It no longer allows one to add spec refs to the js as one used
>> to be able to
>>
>> see diff https://dvcs.w3.org/hg/WebID/rev/7f01174c75b0
>>
>> So the TLS spec now is missing two references
>>
>> [[
>>   berjon.biblio["RFC5746"] = "E. Rescorla, M. Ray, S. Dispensa, N.
>> Oskov,  <a href=\"http://tools.ietf.org/html/rfc5746\"><cite>Transport
>> Layer Security (TLS) Renegotiation Indication Extension</cite></a> February
>> 2010. Internet RFC 5246. URL: <a href=\"
>> http://tools.ietf.org/html/rfc5746\">http://tools.ietf.org/html/rfc5746</a>
>> ";
>>
>>   berjon.biblio["WEBID"] =  "Andrei Sambra, Stéphane Corlosquet. <a href='
>> https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/identity-respec.html'
>> ]]
>>
>> Any idea how one can get those added to the code using the new specref?
>>
>>    https://github.com/tobie/specref
>>
>>
>>
>>
>> >
>> > We split the identity part from the TLS part, and we have a definition
>> > of WebID that is simple and implementable. Also a bit of philosophical
>> >
>> > We should be close to a new release. All we need is one document
>> > to describe the other two docs. And perhaps a few tweaks....
>> >
>> > Henry
>> >
>> > Begin forwarded message:
>> >
>> >> From: Dan Brickley <danbri@danbri.org>
>> >> Subject: [foaf-protocols] WebID status recap?
>> >> Date: 13 June 2013 21:39:26 CEST
>> >> To: foaf-protocols@lists.foaf-project.org
>> >>
>> >> It's mid-2013. Can someone share an overview of the current status of
>> >> WebID aka foaf+ssl, in terms of implementations, adoption and
>> >> documentation at W3C?
>> >>
>> >> Thanks,
>> >>
>> >> Dan
>> >> _______________________________________________
>> >> foaf-protocols mailing list
>> >> foaf-protocols@lists.foaf-project.org
>> >> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
>> >
>> > Social Web Architect
>> > http://bblfish.net/
>> >
>>
>> Social Web Architect
>> http://bblfish.net/
>>
>> _______________________________________________
>> foaf-protocols mailing list
>> foaf-protocols@lists.foaf-project.org
>> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
>>
>
> Social Web Architect
> http://bblfish.net/
>
>