Re: a common understanding of profiles

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.

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

Received on Friday, 26 June 2015 20:18:30 UTC