Re: a common understanding of profiles

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.


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