Re: a common understanding of profiles

On 06/28/2015 10:53 PM, Melvin Carvalho wrote:
> On 28 June 2015 at 22:13, Harry Halpin <hhalpin@w3.org> wrote:
> 
>>
>>
>> On 06/27/2015 09:10 PM, Melvin Carvalho wrote:
>>> On 26 June 2015 at 23:22, Harry Halpin <hhalpin@w3.org> wrote:
>>>
>>>>
>>>>
>>>> On 06/26/2015 11:17 PM, Melvin Carvalho wrote:
>>>>> On 26 June 2015 at 22:58, Harry Halpin <hhalpin@w3.org> wrote:
>>>>>
>>>>>> Again, I think http URIs and using #s to separate humans and documents
>>>>>> are in general good ideas and support that in RDF-based systems.
>>>>>>
>>>>>> However, as the WebID+TLS community in the past has been unable or
>>>>>> unwilling to update or change their  authentication protocol in
>> response
>>>>>> to noted and kinda well-known security/privacy issues with WebID+TLS,
>> so
>>>>>> I'm not sure further discussion is productive on this mailing list.
>>>>>>
>>>>>> Regardless of security/privacy issues, as TLS client negotiation is
>>>>>> being dropped in TLS 1.3 due to the triple handshake attack, it's
>> pretty
>>>>>> obvious that WebID+TLS should not be used as a general purpose
>>>>>> authentication protocol in the future as browser support for even how
>> it
>>>>>> works today will be phased out over time.
>>>>>>
>>>>>> Rather, the WebID community I would suggest looking at the TLS Token
>>>>>> Binding discussion, or improving WebID+RSA or the FIDO work.
>>>>>>
>>>>>> I'm happy to write these well-known issues up and send them to the WG.
>>>>>> If you doubt these points, you may wish to communicate with the TLS
>> WG,
>>>>>> the IETF SAAG, or the W3C WebSec WG to get in touch with folks in
>>>>>> industry and academia who are working on these problems and may have
>>>>>> more time to discuss these issues with you.
>>>>>>
>>>>>
>>>>> Thanks for the offer of writing up the "well known" issues, that would
>> be
>>>>> welcome.  I know you have strong views here, so, in general, a write up
>>>> or
>>>>> pointers (as above) would be appreciated.
>>>>
>>>> These issues are strangely enough well known in the larger security,
>>>> privacy, and cryptographic research community, which it seems the WebID
>>>> community could use more interaction with. Good luck!
>>>>
>>>> I'll send a doc out if I have time, but the links are below from Ryan
>>>> and Brad.
>>>>
>>>
>>> Harry, please dont say you would be "happy to" do something, unless you
>> are
>>> prepared to follow through with it.  If you claim there are well known
>>> issues with something, then you can be expected to be asked what they
>> are.
>>> I think it's clear from the conversation above, that you're not up to
>> date
>>> with the subject material, in this case.  So soon after being asked by
>>> TimBL not to quote him out of context, you seem to be doing it again.
>>
>> I am not quoting TimBL. I just said I support WebID as http URIs with
>> the use of #s.
>>
> 
> Quote: "by WebID you mean what TimBL means, i.e. identify people using URIs"
> 
> If you had been referring to the timbl's web axioms that anything of note
> should be identified using a URIs, then sure.  But that's not what WebID
> means.
> 
> WebIDs are HTTP URIs that support turtle.  Hash URIs are recommended.  That
> is what's in the webid spec that timbl authored.
> 
> I hope this is clear now.

Yes, I noted the WebID vs. WebID+TLS distinction in this e-mail, so
*why* are you repeating yourself?

https://lists.w3.org/Archives/Public/public-socialweb/2015Jun/0060.html

Note my comments on clarifiying the security/privacy issues apply to
WebID+TLS. When most people say WebID they mean "WebID+TLS", which of
course has all security/privacy issues mentioned earlier, and thus the
lack of support and implementation from the larger W3C community. IMHO
It would *definitely* be useful to decouple even further WebID as "URIs
to identify people that return a profile" from "WebID+TLS".

You can also read my previously mentioned email to see a hopeful but
realistic take on #s and Turtle being adopted outside the community
already using them. Thus, you may want to make #s and Turtle optional
for WebID, and focus on interop in terms of JSON-LD (JSON with a good
default context) if you want people outside the RDF community to use
WebID and thus have the ability to link profiles. Turtle is a great
syntax for RDF, but I imagine RDF-aware people can roundtrip quite
easily between the two.In terms of #s, you could always auto-append a #
to a URI of a non-# using system (i.e the majority of systems out there)
for RDF inference purposes.

Of course, if the WebID community wishes to not engage with the rest of
the non-RDF world, that's fine but that's a loss for you all obviously,
since as the Social Web WG shows, we have to bring together very
disparate communities to create a standard for interop in terms of
decentralization. Otherwise, a 'decentralized' solution just ends up
being a small, decentralized silo.

   cheers,
       harry




> 
> 
>>
>>>
>>> In future, If you provide pointers to back up your opinions, It will be
>>> more productive, and that much easier to take seriously.
>>
>> Did you not see the poiners below from Brad Hill (Facebook) and Ryan
>> Sleevi (Google)?
>>
>> You just have to scroll down. However here they are:
>>
>>  https://lists.w3.org/Archives/Public/public-xg-webid/2011May/0126.html
>>
>>
>> https://lists.w3.org/Archives/Public/public-webcrypto-comments/2015Jun/0001.html
>>
>>
>> https://lists.w3.org/Archives/Public/public-webcrypto-comments/2015Jun/0003.html
>>
>> It may take me a week or so to write this down, I can't do it overnight
>> nor do I have lots of spare time. Again, all of these points were
>> brought up privately (last time by Nadim from INRIA at the Social Web
>> F2F) and ignored for a long time.
>>
>> That being said, the WebID+TLS community could use the fact that TLS 1.3
>> is dropping support as an opportunity: The idea of using private key
>> material to authenticate in a decentralized fashion is a *great idea*
>> and everyone agrees (i.e FIDO, WebID+RSA with separate
>> signing/encryption keys, etc.) it makes lots of sense.
>>
>> A redesign that works with privacy and security concerns would be
>> welcomed. However, that would require the WebID community leaving its
>> comfort zone and engaging with the security and privacy community
>> seriously, which could would be very productive for all concerned. I
>> hope you all can actually do that.
>>
> 
> Regarding the 'well known' issues as you describe.
> 
> Your pointer is from 2011 and concerns in part performance.  Thanks for
> sharing but a lot has changed since 2011.
> 
> The other two are from this month (June 2015), and are not directed at
> WebID.  So one wonders to see how an issue raised just 4 days ago can be a
> 'well known' problem with WebID+TLS.
> 
> From my experience, I have found Ryan Sleevi to be very conservative,
> wanting to block ajax connections to localhost and web crypto api running
> on http are things I think he had a hand in.
> 
> So, if you want to raise criticisms of WebID or WebID+TLS, either here, or
> unprompted in other working groups, it would be helpful if you were
> prepared to be asked to write up a summary of your concerns.
> 
> 
>>
>>    cheers,
>>       harry
>>
>>
>>>
>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> Brief links below:
>>>>>>
>>>>>>
>>>>>> On 06/26/2015 10:25 PM, Melvin Carvalho wrote:
>>>>>>> FYI: I've moved this discussion to public-webid, I hope I can field
>>>> some
>>>>>> of
>>>>>>> the comments / criticisms.
>>>>>>>
>>>>>>> On 26 June 2015 at 21:51, Harry Halpin <hhalpin@w3.org> wrote:
>>>>>>>
>>>>>>>> On 06/26/2015 09:22 PM, Melvin Carvalho wrote:
>>>>>>>>> On 26 June 2015 at 19:25, Harry Halpin <hhalpin@w3.org> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 06/26/2015 05:04 PM, Melvin Carvalho wrote:
>>>>>>>>>>> On 26 June 2015 at 14:23, Evan Prodromou <evan@e14n.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On 2015-06-26 07:37 AM, Melvin Carvalho wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Regarding the URI above.  It can become slightly problematic
>>>>>>>> attaching
>>>>>>>>>>>>> key value pairs to an HTTP document, also doubling as a Person.
>>>>>>>>>>>>>
>>>>>>>>>>>> I'm pretty sure I didn't do that in the example I gave.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Well I thought you were tying (for example) the key "@type" and
>>>> value
>>>>>>>>>>> "Person" to the http doc : https://evanprodmorou.example/profile
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> So, how to get interoperable profiles?
>>>>>>>>>>
>>>>>>>>>> Note this question was explicitly scoped to the Social Interest
>>>> Group,
>>>>>>>>>> as obviously profiles are going to vary alot across systems and
>> only
>>>>>> the
>>>>>>>>>> most generic pieces of syntax. So, could we move this discussion
>>>>>> there?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks, that's good to know.  However I dont think all members here
>>>> are
>>>>>>>>> members of the IG (im not for example).  To the extent that a
>> common
>>>>>>>>> understanding of profiles is a pre requisite for implementing a
>>>> social
>>>>>>>> api,
>>>>>>>>> it would be good to get that understood.
>>>>>>>>
>>>>>>>> Anyone can join the IG.
>>>>>>>>
>>>>>>>> Again, the way to solve this is probably to look at Activity
>>>> Vocabulary
>>>>>>>> carefully first, and then vCard, and then FOAF and see what is
>>>> missing,
>>>>>>>> then pull requests with proposed modified changes/mapping to
>> Activity
>>>>>>>> Vocabulary.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> Pick a data standard, and a way to find the profiles. Then,
>>>>>> everybody
>>>>>>>>>>>> implements that.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> +1 good to re-use a well-known standard.  Typically, that would be
>>>>>> VCard
>>>>>>>>>> (support across most of the ecosystem), which basically merged
>> with
>>>> a
>>>>>>>>>> good deal of PortableContacts in VCard 4.0. It's got an XML
>>>>>>>>>> serliazation, it maps to hCard for microformat users, and there's
>> a
>>>>>> RDF
>>>>>>>>>> serialization for RDF users (not sure why FOAF didn't closely
>> align
>>>>>>>>>> more, but that could fixed).
>>>>>>>>>>
>>>>>>>>>> For things that aren't part of core vCard, the IG is empowered to
>>>>>> create
>>>>>>>>>> and maintain vocabularies (published as Interest Group Notes), and
>>>> we
>>>>>>>>>> imagined there would be lots of activity and iterations and
>>>>>> maintenance
>>>>>>>>>> of these vocabularies might go beyond the lifetime of the WG. The
>>>> W3C
>>>>>> is
>>>>>>>>>> happy also co-ordinate as needed with schema.org and IETF on
>> these
>>>>>>>> issues.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -1 to vcard, I dont think everyone can be expected to implement
>> that,
>>>>>>>> does
>>>>>>>>> anyone here do that so far?
>>>>>>>>>
>>>>>>>>> In general, I think it's unrealistic to propose "one profile
>> standard
>>>>>> to
>>>>>>>>> rule them all", unless there's a very strong reason to do so -- but
>>>> if
>>>>>>>> the
>>>>>>>>> WG wants to go in that direction I would say a stand out candidate
>> is
>>>>>>>> WebID
>>>>>>>>> because
>>>>>>>>>
>>>>>>>>> - It's already a documented spec
>>>>>>>>> - It is already based on standards, and is 5 star linked data
>>>>>>>>> - It is already implemented by SoLiD
>>>>>>>>> - It is already implemented by facebook
>>>>>>>>> - It already has about 1 billion profiles, out there
>>>>>>>>> - It provides a discovery mechanism for feeds, followers, friends
>>>> etc.
>>>>>>>>>
>>>>>>>>> Once again, I dont advocate this as being the single choice, I
>> would
>>>>>>>> rather
>>>>>>>>> look for common ground for interop.
>>>>>>>>
>>>>>>>> If by WebID you mean what TimBL means, i.e. identify people using
>>>> URIs,
>>>>>>>> I am sure almost everyone agrees that using URIs is the way to go. I
>>>>>>>> think there's wide agreement there. I believe Facebook and most
>> sites
>>>>>>>> indeed do that.
>>>>>>>>
>>>>>>>> If by WebID you mean FOAF, see above re mapping FOAF into vCard 4
>> and
>>>>>>>> Activity Vocabulary and seeing what the diff is. Most of the known
>>>> world
>>>>>>>> implements vCard and there are very mature libraries for almost all
>>>>>>>> platforms. Convergence between FOAF/ActivityVocabulary/vCard would
>> be
>>>>>>>> great, but should be done in IG. FOAF is not supported natively by
>>>>>>>> Facebook to my knowledge and has very little developer take-up
>> outside
>>>>>>>> the RDF community, although Matt Rowe had some excellent export
>> tools.
>>>>>>>>
>>>>>>>
>>>>>>> FOAF is not part of webid, but it is used in the examples.  Do you
>>>> have a
>>>>>>> pointer to the tools you mention?
>>>>>>
>>>>>> http://www.matthew-rowe.com/?q=foaf-generator
>>>>>>
>>>>>> Might not work any more due to bit rot.
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Authentication mechanisms such as WebID+TLS is *out of scope* for
>> this
>>>>>>>> WG. Even if it was, the necessary cryptographic and security
>> expertise
>>>>>>>> is clearly not here as well. WebID+TLS is not implemented by
>> Facebook
>>>> or
>>>>>>>> any other user-facing vendors to my knowledge (Facebook implements,
>> as
>>>>>>>> is widely known, a variant of OpenID Connect i.e. Facebook Connect
>> and
>>>>>>>> my guess will likely support FIDO). People at Facebook, such as Brad
>>>>>>>> Hill and chair of the W3C WebAppSec WG, have come out quite strongly
>>>>>>>> against WebID+TLS.
>>>>>>>>
>>>>>>>
>>>>>>> Pointer to Brad Hill's comments?
>>>>>>
>>>>>>
>> https://lists.w3.org/Archives/Public/public-xg-webid/2011May/0126.html
>>>>>>
>>>>>> It's been forwarded before without adequate response or change in
>>>>>> protocol about four years ago :(
>>>>>>
>>>>>> See Ryan Sleevi (Google) in WebCrypto on cleartext/privacy issues:
>>>>>>
>>>>>>
>>>>>>
>>>>
>> https://lists.w3.org/Archives/Public/public-webcrypto-comments/2015Jun/0001.html
>>>>>>
>>>>>> More datapoints:
>>>>>>
>>>>>>
>>>>>>
>>>>
>> https://lists.w3.org/Archives/Public/public-webcrypto-comments/2015Jun/0003.html
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> To summarize the well-known arguments about why WebID+TLS is
>>>> considered
>>>>>>>> harmful and thus unlikely to be standardized: From a privacy
>>>> perspective
>>>>>>>> client certificates send personal data (i.e the URI in the SAN for
>>>> their
>>>>>>>> WebID profile) in the cleartext, unlike even usernames and passwords
>>>>>>>> over TLS. From a security perspective (see triplehandshake attack)
>>>> there
>>>>>>>> are so many security bugs in client certificate authentication that
>> it
>>>>>>>> is being deprecated by the IETF in TLS 1.3.
>>>>>>>>
>>>>>>>
>>>>>>> This comment sounds like flame bait, and is IMHO damaging.  I think,
>> in
>>>>>>> general your hostility towards WebID + TLS is not shared by all at
>> the
>>>>>>> W3C.
>>>>>>
>>>>>> It's not hostility, its requests for corrections so you should
>>>>>> fix/change the protocol. WebID+RSA may make more sense (although you
>>>>>> should use a different signing and privacy key - and you may need
>>>>>> key-wrapping, which has some issues in WebCrypto in terms of attack
>>>>>> surfaces) in the long-run if you want a lightweight key authentication
>>>>>> mechanism.
>>>>>>
>>>>>> In terms of authentication protocols, for passwords SRP makes a lot of
>>>>>> sense, w/o passowords there is also HOBA at the IETF:
>>>>>> https://tools.ietf.org/html/rfc7486
>>>>>>
>>>>>>>
>>>>>>> More than 50% of the population of Estonia use TLS with X.509 to
>> vote,
>>>> do
>>>>>>> banking and identify themselves.  The system is now being rolled out
>> to
>>>>>>> Finland.
>>>>>>>
>>>>>>> Does this also fail your personal litmus test?
>>>>>>
>>>>>> They do not use TLS client certs or negotiation, they use X.509 certs
>>>>>> transmitted over an already established TLS connection. I've discussed
>>>>>> this with them, and they are actively monitoring WebCrypto and FIDO as
>>>>>> they plan to upgrade their infrastructure when the newer standards are
>>>>>> deployed.
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> That being said, the general concepts behind something like
>> WebID+TLS
>>>>>>>> (use of proof of key material for authentication) is of interest,
>> and
>>>>>>>> should be discussed in the W3C Web Security Interest Group and the
>>>>>>>> Security Area (SAAG) at the IETF for further evolution, rather than
>> in
>>>>>>>> this WG. In detail, a privacy-preserving technique known as channel
>>>>>>>> binding (i.e. binding authentication to a TLS channel without
>>>> revealing
>>>>>>>> personal information) is being worked on actively in the TLS Token
>>>>>>>> Binding at the IETF. User-centric authentication with
>>>>>>>> proof-of-possession of key material done using the same-origin
>> policy
>>>> is
>>>>>>>> currently being developed by the FIDO Alliance, with the backing of
>>>>>>>> Google, Microsoft, Paypal, and others. I suspect authentication
>>>> without
>>>>>>>> passwords be a solved problem shortly.
>>>>>>>>
>>>>>>>> So, let's remain on topic and focus on what is chartered for the WG.
>>>>>>>> Thanks!
>>>>>>>>
>>>>>>>>    cheers,
>>>>>>>>       harry
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>    cheers,
>>>>>>>>>>       harry
>>>>>>>>>>>>
>>>>>>>>>>>> It would be wrong to assume that the point of this working group
>>>> is
>>>>>> to
>>>>>>>>>>>> make Melvin's site implemented in FOAF with Turtle talk to
>> Aaron's
>>>>>>>> site
>>>>>>>>>>>> implemented in HTML with microformats.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I guess Im not quite seeing it how to implement an interoperable
>>>>>> social
>>>>>>>>>> API
>>>>>>>>>>> without interoperable social profiles.  However, Kingley's reply
>>>>>> seems
>>>>>>>> to
>>>>>>>>>>> make sense. I'll fwd them to the public list.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> We're here for the important goals of defining a social syntax,
>>>> and
>>>>>>>>>> social
>>>>>>>>>>>> API, and a federation protocol for the seven billion people on
>> the
>>>>>>>>>> entire
>>>>>>>>>>>> planet -- not to build ad hoc bridges for the few dozen people
>>>>>>>>>>>> participating in this group.
>>>>>>>>>>>>
>>>>>>>>>>>> Ultimately, that means some people here are going to have to
>>>>>>>> compromise,
>>>>>>>>>>>> hold their nose, and implement a data standard that they don't
>>>>>> usually
>>>>>>>>>> use
>>>>>>>>>>>> or like.
>>>>>>>>>>>>
>>>>>>>>>>>> -Evan
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Received on Sunday, 28 June 2015 21:31:36 UTC