Re: a common understanding of profiles

On 26 June 2015 at 22:18, Harry Halpin <hhalpin@w3.org> wrote:

>
>
> On 06/26/2015 09:59 PM, Melvin Carvalho wrote:
> > 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.
> >>
> >
> > I mean webid as defined in the link I shared in top post, which is what
> > TimBL means (he was the author)
> >
> > http://www.w3.org/2005/Incubator/webid/spec/identity/
> >
> > There's a couple of other nuances that were discussed at TPAC in
> > preparation to this document at the federated social web workshop, some
> of
> > this group were at.
>
> This document says normatively
>
> 1) "use HTTP" URIs.
>
> As stated, I think most people would agree, although some system may
> want to use Acct URIs. Regardless, I think here we can get agreement. As
> shown in our f2f where this has been discused, it may be difficult. This
> could be fruitful for discussion.
>
> 2) Make two different URIs for a person and a document, using a "#" for
> the person.
>
> In detail, if you want agreement that people should be distinguished
> from their websites using a # fragment identifier (which is mostly used
> to identify fragments of HTML on the client side, not divide humans and
> documents), I'm sure not you can get agreement but no one can stop you
> from using this convention. I doubt many other people will see utility
> in it but it clearly has some for the RDF community due to it use in
> RDF/OWL inference - however, IndieWeb and the rest of the Web don't do
> this.  A whole spec around this in the Social WG is probably unnecessary
> and I'm not sure if it's fruitful to discuss further given our
> unfruitful discussions of this in F2Fs.
>
> 3) Require Turtle.
>
> I am sure people could convert from JSON-LD into Turtle without
> requiring native Turtle as a MUST. However, of course people who use
> Turtle could use it as an alternative syntax to the JSON-LD syntax as
> some find it much easier to understand. Our charter does not mandate
> Turtle right now, just JSON.
>
> If you really need Turtle and # URIs, I think you'd have to convince the
> WG something actually breaks without it.
>

Thanks for reading the document.

So, I think (1), (2) and (3) are (among others) possible points for a
common understanding.  Please note that facebook do implement all 3 of
these.


>
>
> >
> >
> >>
> >> 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.
> >>
> >
> > I dont know why you would think that.  FOAF Is used in the examples, but
> is
> > not a pre requisite.  I'd suggest reading the doc.
> >
> >
> >>
> >> 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.
> >>
> >
> > Again, I dont know why you would bring this up, it's not in the doc.
>
> I was clarifying what you meant, as the WebID community usually uses the
> term "WebID" to mean "WebID+TLS", which was "FOAF+TLS". Obviously both
> FOAF and WebID+TLS have limited developer mindshare, with WebID having
> serious security and privacy issues that prevent uptake, and so I was
> making sure you understood why and how nonetheless at least with FOAF
> you could contribute productively to the profile discussion in the IG.
>
> >
> >
> >>
> >> 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 is off topic.
> >
> >
> >>
> >> 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.
> >>
> >
> > This is off topic.
> >
> >
> >>
> >> So, let's remain on topic and focus on what is chartered for the WG.
> >> Thanks!
> >>
> >
> > Harry, it is you that is going off topic.  Please do read the material
> > provided.
>
> See above.
>
> >
> >
> >>
> >>    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
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >
>