Re: a common understanding of profiles

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.


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