WebID and WebFinger

[Danny Ayers]

I can't help thinking there's a fair bit of overlap between the goals
of these projects which could be leveraged to mutual benefit, yet they
seem like they're being developed in separate universes. Here are an
overview doc, draft spec and mailing list details for each:

WebFinger :

http://code.google.com/p/webfinger/

http://code.google.com/p/webfinger/wiki/WebFingerProtocol

http://groups.google.com/group/webfinger

WebId:

http://esw.w3.org/WebID

http://bblfish.net/tmp/2010/08/05/index-respec.html

http://lists.foaf-project.org/mailman/listinfo/foaf-protocols

Cheers,
Danny.

--
http://danny.ayers.name

[Danny Ayers]

On 9 August 2010 20:19, Melvin Carvalho <melvinc...@gmail.com> wrote:

> Yes, I pointed this out to Blaine Cook, too.  We've exchanged a few mails on
> the subject, on and off list.

Blaine got right back to me offlist about it...

Henry has also blogged about some of the
> options.  The W3C SWXG Social Incubator group also had a teleconference on
> Webfinger; most of the major players have been invited to speak and the take
> up rate is high.  People like Chirs Messina have downloaded and viewed our
> source code as long ago as a year ago.
>
> So im not sure why you think it's 'different universes'?

Fair enough, I do seem to have missed a lot of interaction.

> I think there's a quiet acceptance of WebID emmerging, with the attitude
> sort of becoming ... 'Show us what you can do!'
>
> Perhaps the wider question is, why have only about 1% of people who have
> interest in the semantic web, so far got themselves a webid?

Ah - now that is back in the "different universes" area. With the
WebFinger folks looking at syntactical transformations from email
addresses to URIs, potentially *everyone* with an email address will
get URIs which identify themselves.

Which raises the question around WebId of how best to deal with the
likelihood of people having multiple WebIds (one per service given the
current social net landscape), which seems ok semantically with the
aid of owl:sameAs, but problematic in practice due to the lack of
automatic discovery: a problem for both groups I reckon.

[Toby Inkster]

On Mon, 9 Aug 2010 08:14:22 +0200
Danny Ayers <danny...@gmail.com> wrote:

> I can't help thinking there's a fair bit of overlap between the goals
> of these projects which could be leveraged to mutual benefit, yet they
> seem like they're being developed in separate universes.

Not entirely separate.

My CGI::Auth::FOAF_SSL can use Webfinger to locate data about a user.
If none of the WebID URLs in the X.509 certificate dereference to an
RDF resource that confirms the certificate's ownership, then it will
fall back to attempting to look up any e-mail addresses in the
certificate using Fingerpoint and Webfinger, and hopefully find the
relevant data that way.

A slight hiccough is that there's not a natural way of embedding "acct:"
URIs in X.509 certificates. The "obvious" way is:

subjectAltName = URI:acct:j...@example.net

But this somewhat conflicts with our use of subjectAltName URI values.
We take the range of these as being effectively foaf:Agent; whereas an
"acct:" URI's range is closer to foaf:OnlineAccount. So there's a
semantic mismatch there.

That's not to say there's no scope for integration - just that it
shouldn't use that obvious route. For any Webfinger accounts which also
happen to be usable as e-mail addresses, integration is easy, as X.509
provides a specific email value type:

subjectAltName = email:j...@example.net

Here we don't need to worry about the range of subjectAltName URIs, as
we're not using them.

So anyway, there is some work being done on the overlap. You might want
to look at some of my Perl modules on CPAN
<http://search.cpan.org/~tobyink/>. Relevant ones include XRD-Parser,
HTTP-LRDD, HTTP-Link-Parser, WWW-Finger - the thing they have in common
is that they all basically treat XRD (and related technology) as an
extension of the RDF/Linked Data world. I'm happy to go into detail if
the documentation isn't clear.

--
Toby A Inkster
<mailto:ma...@tobyinkster.co.uk>
<http://tobyinkster.co.uk>

[Melvin Carvalho]

Sorry just noticed you mention owl:sameAs here :)

So I think we need things like semantic pingback here with sparql 1.1 (update) ?
 

[Henry Story]

For WebID your missing the specs we have release recently 

  http://www.w3.org/2005/Incubator/webid/spec/

We have distinguished more clearly WebID as an identity system, and WebID+TLS as one authentication method.

We also tie it in there with Access Control.

As an identity system there are already millions of people with WebIDs ( via their foaf files ) 

What is new is that the W3C is settling on a generic protocol called LDP, which can then allow all kinds of things

You can get a demonstration of how all that ties together in a practical way on the rww-play server:

   https://github.com/read-write-web/rww-play/wiki/Curl-Interactions

( of course curl interactions is not what end users will end up doing )

[Henry Story]

As to how WebFinger and webid interact. From the linked data point of view the two can be simply tied together

in the WebID profile document like this:

<#me> foaf:mbox <mailto:henry...@bblfish.net>, <accnt:henry...@bblfish.net> .

I am not sure if foaf:mbox is exactly the right relation, one may or may not require a more precise relation.

[Jon Richter]

Funny to see that question comes up again here, as I've done some further investigations into that domain exactly the same day.

Please find my notes/questions over at https://plus.google.com/+JonRichter/posts/RL41rv6fAaW : until now, that's only a sketchy investigation.

But surely there is a correlation.

From a workflow point of view, I would love seeing this:

1. Set the us...@domain.tld scheme the primary comprehensible identification token for end-users.

2. Have a lookup of available services for that address:

  * Webfinger leading to WebID

  * WebID referencing other accounts, that follow the same convention, i.e.

    * XMPP > Jabber, BuddyCloud

    * remoteStorage

    * pump.io

    * E-Mail

    * SIP

    * ... what else can you think of?

3. Have distinguishable channels for different purposes:

  * Notifications 

    > Any robot generated E-Mail that is created by services

      One-time password tokens (why not always login like that? kill passwords), 

    > XMPP

      Fallback: E-Mail

  * Federated Messaging

      Every inter-human interaction : Helpdesks, Mailing Lists,

    > pump.io

      Fallback: XMPP, remoteStorage, E-Mail

  * The fallback strategy makes sure any message will be delivered at any time. The WebID would therefore be held responsible for publishing preferred orders of services.

That way we could make the federated social web understandable to non-tech-savvy people that tend to be afraid of anything else than E-Mail, because it works so well.

As they are not aware of all the problems the E-Mail system brings (to some extent still Spam and Phishing, but MIME parts, HTML E-Mail, BASE64 encoded files, SPF, DKIM, end-to-end encryption, etc.), something similar to the above would allow them to work with the same metaphores, but experience greater outcomes by possible federation of their data.

All the ideas above imply there is a central aggregation dashboard available, similiar to SocketHub and many more (which I could try to list), that makes it easy to blend the multitude of sources.

<#me> foaf:mbox <mailto:henry...@bblfish.net>, <accnt:he...@bblfish.net> .

[Melvin Carvalho]

On 10 June 2014 18:01, Jon Richter <jon.r...@gmail.com> wrote:

Funny to see that question comes up again here, as I've done some further investigations into that domain exactly the same day.

Please find my notes/questions over at https://plus.google.com/+JonRichter/posts/RL41rv6fAaW : until now, that's only a sketchy investigation.

But surely there is a correlation.

From a workflow point of view, I would love seeing this:

1. Set the us...@domain.tld scheme the primary comprehensible identification token for end-users.

-1,000.000

On the web we use URIs. 

 

2. Have a lookup of available services for that address:

  * Webfinger leading to WebID

  * WebID referencing other accounts, that follow the same convention, i.e.

    * XMPP > Jabber, BuddyCloud

    * remoteStorage

    * pump.io

    * E-Mail

    * SIP

    * ... what else can you think of?

Buzz work city.  Nothing interoperable here.

 

3. Have distinguishable channels for different purposes:

  * Notifications 

    > Any robot generated E-Mail that is created by services

      One-time password tokens (why not always login like that? kill passwords), 

    > XMPP

      Fallback: E-Mail

  * Federated Messaging

      Every inter-human interaction : Helpdesks, Mailing Lists,

    > pump.io

      Fallback: XMPP, remoteStorage, E-Mail

  * The fallback strategy makes sure any message will be delivered at any time. The WebID would therefore be held responsible for publishing preferred orders of services.

That way we could make the federated social web understandable to non-tech-savvy people that tend to be afraid of anything else than E-Mail, because it works so well.

As they are not aware of all the problems the E-Mail system brings (to some extent still Spam and Phishing, but MIME parts, HTML E-Mail, BASE64 encoded files, SPF, DKIM, end-to-end encryption, etc.), something similar to the above would allow them to work with the same metaphores, but experience greater outcomes by possible federation of their data.

All the ideas above imply there is a central aggregation dashboard available, similiar to SocketHub and many more (which I could try to list), that makes it easy to blend the multitude of sources.

Build interoperable solutions, and everything will work together.  Chasing ambulances does not help.

 

--

---
You received this message because you are subscribed to the Google Groups "WebFinger" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webfinger+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jon Richter]

Am Freitag, 20. Juni 2014 02:59:16 UTC+2 schrieb melvincarvalho:

On 10 June 2014 18:01, Jon Richter wrote:

1. Set the us...@domain.tld scheme the primary comprehensible identification token for end-users.

-1,000.000

On the web we use URIs.

Well; if my grand mother is ever going to understand these. Mail addresses she does.

Webfinger can help in transforming one to the other, doesn't it?

 

Buzz work city.  Nothing interoperable here.

Which cross-plattform, interoperable communication services do you know?

 

Build interoperable solutions, and everything will work together.  Chasing ambulances does not help. 

 

I see a conflict here. Primarily between IndieWeb and W3C efforts.

The ones are just building and creating things that work; the others are waiting for something usable to emerge out of a social process that feels like a dinosaur to many.

How do you assure long-term interoperability and accessibility in the same time? Or will federation just mean, that we all talk many languages (=protocols)?

I'm curious in your opinion.

[Kingsley Idehen]

On 6/20/14 5:45 AM, Jon Richter wrote:
> I see a conflict here. Primarily between IndieWeb and W3C efforts.
> The ones are just building and creating things that work; the others
> are waiting for something usable to emerge out of a social process
> that feels like a dinosaur to many.

But you already use the Web. I assume you like the Web and appreciate it
utility. If what I assert is true, then what's the problem with HTTP
URIs as denotation mechanism?

Identifiers denote things [1] .
An HTTP URI is a kind of Identifier [2] .
An HTTP URL is a kind of HTTP URI that specifically denotes a Web
Document (or Web Resource) [3].
A WebID is an HTTP URI that denotes an Agent [4].

The W3C simply provides specifications for Open Standards. Of course,
they sometimes mangle their messages which end up utterly skewing intent
etc..

Links:

[1] http://bit.ly/SXww64 -- Identifier
[2] http://bit.ly/1lQFoBq -- HTTP URI
[3] http://bit.ly/1iPYhEB -- HTTP URL
[4] http://bit.ly/1no2dxJ -- WebID
[5] http://slidesha.re/1hF48QL -- Understanding Data
[6]
http://kidehen.blogspot.com/2014/03/world-wide-web-25-years-later.html
-- World Wide Web, 25 Years Later .

--

Regards,

Kingsley Idehen
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen

[Melvin Carvalho]

On 20 June 2014 11:45, Jon Richter <jon.r...@gmail.com> wrote:

Am Freitag, 20. Juni 2014 02:59:16 UTC+2 schrieb melvincarvalho:

On 10 June 2014 18:01, Jon Richter wrote:

1. Set the us...@domain.tld scheme the primary comprehensible identification token for end-users.

-1,000.000

On the web we use URIs.

Well; if my grand mother is ever going to understand these. Mail addresses she does.

Webfinger can help in transforming one to the other, doesn't it?

 

Buzz work city.  Nothing interoperable here.

Which cross-plattform, interoperable communication services do you know?

 

Build interoperable solutions, and everything will work together.  Chasing ambulances does not help. 

 

I see a conflict here. Primarily between IndieWeb and W3C efforts.

Absolutely. 

Indie web have branched away from awww and are doing their own thing based on the premise, 'your homepage is your identity'. 

This is not how the web was devised *at all*.  Web pages are supposed to be exactly that, pages.  Like a piece of paper on which you can write things.  When the paper becomes the message, you've confused the medium and the content.  That's why indieweb can only scale to itself, at least for now. 

 

The ones are just building and creating things that work; the others are waiting for something usable to emerge out of a social process that feels like a dinosaur to many.

I applaud the dog fooding mentality.  But there's lots of it going on, in different places.  There's a small cross section of the indie web group that look at other things, eg Sandeep and Tom, who produce good work, but for the most part it's a silo.

 

How do you assure long-term interoperability and accessibility in the same time? Or will federation just mean, that we all talk many languages (=protocols)?

I'm curious in your opinion.

Just follow awww and you'll be sure to have a interoperable solution.  In short, listen to timbl.  People that dont, tend to regret it years down the line.

[Melvin Carvalho]

On 20 June 2014 11:45, Jon Richter <jon.r...@gmail.com> wrote:

Am Freitag, 20. Juni 2014 02:59:16 UTC+2 schrieb melvincarvalho:

On 10 June 2014 18:01, Jon Richter wrote:

1. Set the us...@domain.tld scheme the primary comprehensible identification token for end-users.

-1,000.000

On the web we use URIs.

Well; if my grand mother is ever going to understand these. Mail addresses she does.

I suspect your mother doesnt understand pointers, but then again, most web developers are not in that category either.

A skilful UI will hide the complexity from the user.  Most users wont know they are a primary key in a database somewhere, or have a URL with a profile page.  They simply will see names, avatars and comments of people they know.  This is an example of leveraging awww into a good user experience, 'that just works'.

Obviously facebook lead the way here, but there's promising proofs of concept coming up now such as http://cimba.co/

 

Webfinger can help in transforming one to the other, doesn't it?

 

Buzz work city.  Nothing interoperable here.

Which cross-plattform, interoperable communication services do you know?

 

Build interoperable solutions, and everything will work together.  Chasing ambulances does not help. 

 

I see a conflict here. Primarily between IndieWeb and W3C efforts.

The ones are just building and creating things that work; the others are waiting for something usable to emerge out of a social process that feels like a dinosaur to many.

How do you assure long-term interoperability and accessibility in the same time? Or will federation just mean, that we all talk many languages (=protocols)?

I'm curious in your opinion.

--

[Paul E. Jones]

Melvin,

 

First, I apologize for jumping in so late.  I didn't see messages were dropped into my WebFinger folder.

 

Don't be so harsh :-)  One reason the acct URI is constructed as it is is to make it easy for people to be able to use user@domain style addresses. For example, pau...@packetizer.com can reveal info about me and is also the point of contact for me using XMPP, H.323, SMTP, etc.  Ordinary users don't need to know or understand that there is an xmpp: or h323: or acct: URI scheme tacked on the front.

 

Paul

[Melvin Carvalho]

On 6 July 2014 13:24, 'Paul E. Jones' via WebFinger <webf...@googlegroups.com> wrote:

Melvin,

 

First, I apologize for jumping in so late.  I didn't see messages were dropped into my WebFinger folder.

 

Don't be so harsh :-)  One reason the acct URI is constructed as it is is to make it easy for people to be able to use user@domain style addresses. For example, pau...@packetizer.com can reveal info about me and is also the point of contact for me using XMPP, H.323, SMTP, etc.  Ordinary users don't need to know or understand that there is an xmpp: or h323: or acct: URI scheme tacked on the front.

Thanks for the comments.  Sorry, if i came across harsly! :)

Webfinger does the job it was designed for very well.

But it doesnt easily, at least in its current form, interoperate so well with the growing linked data eco system, and serializations such as JSON LD.

I'm not sure there's any way to easily build a bridge from JSON LD to JRD, as JSON LD is a more expressive serialization.

So in the general case, it would not make much sense to mix the two, but rather, to do so in certain well defined use cases, ie when you want to get existing meta data from an email address

I'm not a huge fan of trying to popularize new URI schemes (such as acct: vs mailto or http), because the work is double.  Both technical and evangelization, and the lead time is long, years, or a decade, perhaps.  But if it becomes popular, there is certainly an argument to build more tooling for it.  Tho, that can often be a chicked and egg problem.

[Melvin Carvalho]

On 6 July 2014 13:47, Melvin Carvalho <melvinc...@gmail.com> wrote:

On 6 July 2014 13:24, 'Paul E. Jones' via WebFinger <webf...@googlegroups.com> wrote:

Melvin,

 

First, I apologize for jumping in so late.  I didn't see messages were dropped into my WebFinger folder.

 

Don't be so harsh :-)  One reason the acct URI is constructed as it is is to make it easy for people to be able to use user@domain style addresses. For example, pau...@packetizer.com can reveal info about me and is also the point of contact for me using XMPP, H.323, SMTP, etc.  Ordinary users don't need to know or understand that there is an xmpp: or h323: or acct: URI scheme tacked on the front.

Thanks for the comments.  Sorry, if i came across harsly! :)

Webfinger does the job it was designed for very well.

But it doesnt easily, at least in its current form, interoperate so well with the growing linked data eco system, and serializations such as JSON LD.

I'm not sure there's any way to easily build a bridge from JSON LD to JRD, as JSON LD is a more expressive serialization.

Let me give a simple example of this.  Let's take Tim Berners-Lee's FOAF profile (you can think of this as similar to a webfiger record)

http://graphite.ecs.soton.ac.uk/browser/?uri=http%3A%2F%2Fwww.w3.org%2FPeople%2FBerners-Lee%2Fcard%23i#http://www.w3.org/People/Berners-Lee/card#i

Now here we see that he has TWO nicknames:

foaf:nick → "TimBL", "timbl"

In webfiger you are limited to AT MOST one value in this field:

http://tools.ietf.org/html/rfc7033#section-4.4.3

So now we have an interoperabilty issue (one of many).  You could not translate this foaf profile to a webfinger like record, but you could translate a webfinger record to JSON LD, FOAF etc.

So it makes sense, IMHO, to go with the less constrictive serialization than the more constrictive, if that makes sense.

It all depends on your use case.

[Paul E. Jones]

Melvin,

 

That's not an accurate interpretation of that text.  We never defined how to convey a person's name via WebFinger.  The section to which you refer is just an example of properties.

 

I would personally like to use a property to convey a name, but the URI could be constructed to allow for any number of names.  For example, we could do this:

http://example.org/ns/name#1

http://example.org/ns/name#2

 

However, that's admittedly a rather unfortunate way to do it.

 

A better way might be to put the information into "links".  This, we could represent a person's name using this:

 

       "links" :
       [
         {
           "rel" : name",
           "titles" :
           {
             "en-us" : "Paul E. Jones",
           }
         },
         {
           "rel" : name",
           "titles" :
           {
             "en-us" : "Paul Jones",
           }
         }
       ]

Alternatively and perhaps more appropriate, we simply refer to one's vCard or jCard:

 

       "links" :
       [
         {
           "rel" : "http://webfinger.example/rel/businesscard",
           "type" : "application/vcard+json",
           "href" : "https://www.example.com/~bob/bob.jcf"
         }
       ]

 

You could specify any number of jCards or you could put all of the nicknames into the single jCard.

 

Remember, WebFinger is not intended to define all of the information one might want to discover, but merely point to that information.

 

Cheers,
Danny.

--
http://danny.ayers.name/

--

---
You received this message because you are subscribed to the Google Groups "WebFinger" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webfinger+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

---
You received this message because you are subscribed to the Google Groups "WebFinger" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webfinger+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

---
You received this message because you are subscribed to the Google Groups "WebFinger" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webfinger+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Melvin Carvalho]

On 7 July 2014 07:43, 'Paul E. Jones' via WebFinger <webf...@googlegroups.com> wrote:

Melvin,

 

That's not an accurate interpretation of that text.  We never defined how to convey a person's name via WebFinger.  The section to which you refer is just an example of properties.

Im going from

"Properties are used to convey additional information about the subject of the JRD"

 

 

I would personally like to use a property to convey a name, but the URI could be constructed to allow for any number of names.  For example, we could do this:

http://example.org/ns/name#1

http://example.org/ns/name#2

Defining N new predicates to express value1, value2, value3 ... of a nick is a possible work around, but looks like an interoperability nightmare, when other systems have a single predicate and multiple values.

 

 

However, that's admittedly a rather unfortunate way to do it.

Agreed

 

 

A better way might be to put the information into "links".  This, we could represent a person's name using this:

 

       "links" :
       [
         {
           "rel" : name",
           "titles" :
           {
             "en-us" : "Paul E. Jones",
           }
         },
         {
           "rel" : name",
           "titles" :
           {
             "en-us" : "Paul Jones",
           }
         }
       ]

Do you mean registering a "name" type with IANA as per rfc5988.  Are you sure that you can have a literal as a value?

My understanding of webfinger was that the links array gave URIs and the Properties set gave values.  Im happy to be corrected here.

Seems registering a bunch of predicates for literals with IANA each time has scalability issues.

 

Alternatively and perhaps more appropriate, we simply refer to one's vCard or jCard:

 

       "links" :
       [
         {
           "rel" : "http://webfinger.example/rel/businesscard",
           "type" : "application/vcard+json",
           "href" : "https://www.example.com/~bob/bob.jcf"
         }
       ]

 

You could specify any number of jCards or you could put all of the nicknames into the single jCard.

 

Remember, WebFinger is not intended to define all of the information one might want to discover, but merely point to that information.

That may work for an acct: URI, but webfinger as a general purpose lookup mechanism it was deemed could also take anyURI including http URIs.  So this means that since JRD is a mandatory serialization you'd lose information in the case of timbl's profile, without an extra layer of indirection, which is kind of messy.

This is only one issue I raise re interop, there's others such as LD supports numbers, and JRD supports strings etc.

Perhaps webfinger 2.0 could demonstrate interop with LD, but I dont see that it's a good match today, imho.

[Paul E. Jones]

Melvin,

 

One could register a token with IANA or one could use a URI where I presently show the rel type "name".  Whether  it should be registered or not, IMO, depends on how widely used this is or is expected to be.

http://graphite.ecs.soton.ac.uk/browser/?uri=http%3A%2F%2Fwww.w3.org%2FPeople%2FBerners-Lee%2Fcard%23i#http://www.w3.org/People/Berners-Lee/card%23i

[Melvin Carvalho]

On 8 July 2014 06:52, 'Paul E. Jones' via WebFinger <webf...@googlegroups.com> wrote:

Melvin,

 

One could register a token with IANA or one could use a URI where I presently show the rel type "name".  Whether  it should be registered or not, IMO, depends on how widely used this is or is expected to be.

I didnt realize that the href/object was optional, it's not in linked data, although the subject is. 

Seems slightly confusing, so if you can stuff literals in the titles element of a link, when would you use that and when would you use properties?

[Paul E. Jones]

Melvin,

 

Using "titles" like that is a bit abusive, arguably.  I just showed it as one example.

 

Titles is intended to define the name of the thing to which the link refers.  For example, an appropriate use would be the name of the blog, if the link referred to the blog.  Using "titles" without a link is syntactically valid, but one should really question whether that should be done.  I would not recommend that approach myself.

 

Anyway, "titles" is a name for the thing to which the link refers.  "Properties", which can also be specified under a link, and those are just name/value pairs identified using a URI.  A good example of properties is in an earlier draft where I had an example of email client configuration: http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-14#section-3.3.

 

That example was removed, since there was a separate effort to define how to auto-provision clients, which would have used WebFinger to refer to configuration documents.  I'm not sure where that effort is at the moment, but I sure wish it was done already.