Allow Webfinger for Actors #20
Comments
|
I thought we agreed that this group would not be using webfinger, and would instead take a "follow your nose" type approach? |
|
I also thought we were going to follow-your-nose and use discoverable endpoints. http://socialwg.indiewebcamp.com/irc/social/2015-03-18/line/1426710400225 |
|
Distributed social systems in the wild using user@domainname IDs:
I think it's quite telling that so many social networks have been designed using the same broad user-ID syntax. It's also exceedingly common for centralized networks to offer E-Mail address based "bootstrap" functionality. I understand that there is a rather strong opposition to non-dereferencable URIs from some quarters of the working group, but I'm also quite certain that telling everybody to change their ID scheme to suite the requirements of our protocol will win us no friends. It should be considered that this protocol is "as simple as possible, but no simpler". I think the removal of support for user@domain IDs is a simplification too far. That said, they should not be mandatory - we should not mandate that sites use or expose such URIs - just permit them to do so. Now, with regards to Webfinger, I'm ambivalent. There have been complaints about the need to parse a second JSON serialization format (though I'm of the opinion that said complaints are overblown - compared to the complexities of managing a distributed social network or accurately scraping tags out of HTML, parsing JRD is trivial), but I'm not deeply attached to it. I certainly don't think we have to use WebFinger for translating such names, but I certainly think we should have some support for such names. My original ActivityPump drafts had the compromise that:
This leaves the one case in which it is necessary to dereference an acct: URI to be the case where a user enters a user@domain ID into the user interface. I myself would prefer my URI to be "https://owenshepherd.net" - perhaps shortenable to "owenshepherd.net" by some normalization rules. On the other hand, contemplate a corporate deployment. Are their staff really supposed to remember their ID is "https://social.example.corp/john.smith"? In the unlikely event that a company like Google were to deploy ActivityPump, are they supposed to give people addresses like "https://user.name.gmail.com"? For such cases, aren't user@domain IDs just easier? Aren't they what people already know and use? user@domain IDs are preferred in some areas for very deliberate reasons. We should absolutely minimize their impact on the spec. We should absolutely use "follow your nose" and dereferencable URIs for the vast, vast majority of cases. But, in my opinion, we absolutely should support them, |
|
Google used to support http://profiles.google.com/{gmail id} e.g. http://profiles.google.com/kevinmarks (which still works because they added redirects for those who registered them). |
|
Sure. Are you really expecting Real People (TM) to remember that their "ID" is http://profiles.google.com/myname? |
|
They remember twitter handles and Facebook names, both of which are URLs https://twitter.com/kevinmarks https://www.facebook.com/kevinmarks and maybe even https://plus.google.com/+KevinMarks They remember the urls of their blogs: http://epeus.blogspot.com or http://kevinmarks.tumblr.com |
|
Nobody remembers their twitter or Facebook URI; they're "@oshepherd" on twitter and on Facebook (Seriously, nobody has ever given me a Twitter or Facebook link except for in the rare case they're copy and pasting it because we are interacting by PC). As for Google+, nobody has ever sent me a Google+ link (Sure, I've seen links on websites, but people who run their own websites tend to be the kind of people who remember technical arcana anyway). As for Tumblr, I have no idea there but I suspect people remember that "I'm myname on tumblr", not that their URI is "http://myname.tumblr.com/". The fact that people have so much trouble remembering their E-Mail address should be good argument for not making them remember yet another arcane address. Actually, more arcane: Now I have to remember if they are "site.com/name", "name.site.com", or something even more arcane like "site.com/~name", "site.com/+name", "site.com/user/name" or "social.corp.com/name". The triumph of the E-Mail address is that everyone to a very, very good approximation is "name@domain.tld". That still leaves a lot of margin for error (what was the TLD again? etc), but it's about as good as we can get it. |
|
I'm inclined to agree that the email address format is much easier for people to remember as it's ubiquitous, every site (Tumblr, Facebook, Google, etc.) either ask you to provide one or provide you one with your account. I would say email is the lowest common denominator as it's required virtually everywhere. People however, do seem to find Tumblr and Facebook works just fine, I suspect that is because they are centralized networks and I wonder how easy people would find URIs opposed to just their username on a federated network, which this must work for. The Working Group however has said that we are going a follow your nose style like @aaronpk linked to. If you would like to have Webfinger supported again it would seem to me that that decision needs to happen in the WG. |
|
I'm confused; I think Webfinger should count as "follow your nose", since you can discover all the endpoints using Webfinger. |
|
Mail addresses are very important for onboarding purposes. That alone is enough reason to have a close look at how they can be integrated. (I suppose there is a user story for that.) |
|
@evanp I believe in the F2F in Boston it was explicitly a decision for "follow your nose" over webfinger, those being mutually exclusive. My interpretation was that with "follow your nose" a dereferenceable URI is used that allows you to discover the user's endpoints. It would be great if this could be clarified by the WG to what was meant by that proposal. |
|
The difference was between "follow-your-nose" and having fixed URL patterns (like "/user/{nickname}/following"). |
|
Okay, we should talk about this on the call. I think I'm beginning to understand the confusion though. This was made more clear to me by reading this email thread:
and
Okay, so... a good portion of this group kind of thinks that "http/https URIs are the only URIs" and starting from that assumption, what can and can't be Follow Your Nose is pretty restricted to just HTTP/HTTPS URIs. But that's not necessarily everyone's assumption or interpretation, and with "acct:" as being an alternative URI resolver, webfinger being "follow your nose" makes sense. Should we talk about this on the call tomorrow? |
|
Also, @evanp, do you think that sounds about right, both for your reason of why webfinger is FYN (and also maybe why there's confusion)? |
|
@evanp What exactly is meant with "Allow Webfinger for Actors" ? |
|
There is really no need to fight this out. These authentication methods are not exclusive. In fact one can tie together all the indentifiers: one just needs to notice that there are direct and indirect identifiers.
You can do this using inverse functional properties ( eg. :openid, :mbox, :homePage, :account, cert:key ) like this @prefix : <http://xmlns.com/foaf/0.1/> .
@prefix cert: <http://www.w3.org/ns/auth/cert#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
<http://bblfish.net/people/henry/card#me>
:openid <http://bblfish.net/>;
:mbox <mailto:henry.story@bblfish.net> ;
:homePage <http://bblfish.net/> ;
:account [ :accountName "bblfish";
:accountServiceHomepage <http://facebook.com/> ] ;
cert:key [ a cert:RSAPublicKey;
cert:exponent 65537 ;
rdfs:comment "KeyChain OSX laptop";
cert:modulus "DAB9D1E941F6F85A0863169D0DB6328D1D4A15A71DFFE3D4F4D08752A52FB1454D7358E4A5ECF3501E3924BC0252F3004B0BB21A0D6B64CA053F0FBCB5A54EC93EBE2DC9B91E4C432B827884C4CC2AD8A102B46D2A2017BF45D9D4C88A564D420234484A1B2E446DBB4CD438E79C2466CE310F327773A779D24ED7B60A05A618B984757B946D67BA79F2E064E6AED38BD6559CE7FC9502720823D56DB1C034099367D7DB27B6BDAFDA8CC48347133F4A14675F675FB484CE32DF66C11A3638FA84D5BE69B1A6F238115DEF9B0F79BB25C0CB7E4A39459A0829B1FD35C0D1DBDD60F9C679D89415ED7EA41EB02FBC016FC0E792CB9698C9F4DB842CDAD5B5F5C9"^^xsd:hexBinary;
] .All of these different systems can be tied together declaratively, without breaking RDF semantics. because mbox is a relation that for the same object can only have one subject. ie you can think of the inverse of foaf:mbox as a function. Call that mbInv. Then It's very handy, because that for example allows one to write access control rules declaratively, and allow different authentication methods:
|
|
@bblfish sorry, we're talking about specific issue in the current version of ActivityPump. Here's the text: Webfinger URIs are used by pump.io for identifying persons and other actor-type objects, and I think it makes sense to continue supporting that. https://tools.ietf.org/html/rfc7033 It's a dereferenceable URI format that has a familiar username@domain format. |
|
from rfc7033 email URIs of the form To make this clearer, here is the isomorphic json-ld graph to the turtle one I posted above: {
"@context": {
"@base": "http://bblfish.net/people/henry/card",
"cert": "http://www.w3.org/ns/auth/cert#",
"foaf": "http://xmlns.com/foaf/0.1/",
"rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
"rdfs": "http://www.w3.org/2000/01/rdf-schema#",
"xsd": "http://www.w3.org/2001/XMLSchema#"
},
"@id": "#hjs",
"@type": "foaf:Person",
"foaf:account": {
"foaf:accountName": "bblfish",
"foaf:accountServiceHomepage": {
"@id": "http://facebook.com/"
}
},
"foaf:homePage": {"@id": "http://bblfish.net/"},
"foaf:mbox": {"@id": "mailto:henry.story@bblfish.net"},
"foaf:openid": { "@id": "http://bblfish.net/"},
"cert:key": {
"@type": "cert:RSAPublicKey",
"cert:exponent": 65537,
"cert:modulus": {
"@type": "xsd:hexBinary",
"@value": "DAB9D1E941F6F85A0863169D0DB6328D1D4A15A71DFFE3D4F4D08752A52FB1454D7358E4A5ECF3501E3924BC0252F3004B0BB21A0D6B64CA053F0FBCB5A54EC93EBE2DC9B91E4C432B827884C4CC2AD8A102B46D2A2017BF45D9D4C88A564D420234484A1B2E446DBB4CD438E79C2466CE310F327773A779D24ED7B60A05A618B984757B946D67BA79F2E064E6AED38BD6559CE7FC9502720823D56DB1C034099367D7DB27B6BDAFDA8CC48347133F4A14675F675FB484CE32DF66C11A3638FA84D5BE69B1A6F238115DEF9B0F79BB25C0CB7E4A39459A0829B1FD35C0D1DBDD60F9C679D89415ED7EA41EB02FBC016FC0E792CB9698C9F4DB842CDAD5B5F5C9"
}
}
} |
|
Thanks, and I appreciate the clarification you're doing, but I disagree that WebID is the be-all end-all of identity, and I'd like to be able to continue to use Webfinger IDs for people in Activitypump as I already do in pump.io. |
|
@evanp I did not say that WebID is the "be-all end-all of identity". I showed how all these identifiers can work together. You don't have to use any of them. Here is a correct usage without WebIDs. {
"@context": {
"@base": "http://bblfish.net/people/henry/card",
"cert": "http://www.w3.org/ns/auth/cert#",
"foaf": "http://xmlns.com/foaf/0.1/",
"rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
"rdfs": "http://www.w3.org/2000/01/rdf-schema#",
"xsd": "http://www.w3.org/2001/XMLSchema#"
},
"@type": "foaf:Person",
"foaf:account": {
"foaf:accountName": "bblfish",
"foaf:accountServiceHomepage": {
"@id": "http://facebook.com/"
}
},
"foaf:homePage": {"@id": "http://bblfish.net/"},
"foaf:mbox": {"@id": "mailto:henry.story@bblfish.net"},
"foaf:openid": { "@id": "http://bblfish.net/"},
"cert:key": {
"@type": "cert:RSAPublicKey",
"cert:exponent": 65537,
"cert:modulus": {
"@type": "xsd:hexBinary",
"@value": "DAB9D1E941F6F85A0863169D0DB6328D1D4A15A71DFFE3D4F4D08752A52FB1454D7358E4A5ECF3501E3924BC0252F3004B0BB21A0D6B64CA053F0FBCB5A54EC93EBE2DC9B91E4C432B827884C4CC2AD8A102B46D2A2017BF45D9D4C88A564D420234484A1B2E446DBB4CD438E79C2466CE310F327773A779D24ED7B60A05A618B984757B946D67BA79F2E064E6AED38BD6559CE7FC9502720823D56DB1C034099367D7DB27B6BDAFDA8CC48347133F4A14675F675FB484CE32DF66C11A3638FA84D5BE69B1A6F238115DEF9B0F79BB25C0CB7E4A39459A0829B1FD35C0D1DBDD60F9C679D89415ED7EA41EB02FBC016FC0E792CB9698C9F4DB842CDAD5B5F5C9"
}
}
}I just removed that first The turtle equivalent is: @prefix : <http://xmlns.com/foaf/0.1/> .
@prefix cert: <http://www.w3.org/ns/auth/cert#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
[] :openid <http://bblfish.net/>;
:mbox <mailto:henry.story@bblfish.net> ;
:homePage <http://bblfish.net/> ;
:account [ :accountName "bblfish";
:accountServiceHomepage <http://facebook.com/> ] ;
cert:key [ a cert:RSAPublicKey;
cert:exponent 65537 ;
rdfs:comment "KeyChain OSX laptop";
cert:modulus "DAB9D1E941F6F85A0863169D0DB6328D1D4A15A71DFFE3D4F4D08752A52FB1454D7358E4A5ECF3501E3924BC0252F3004B0BB21A0D6B64CA053F0FBCB5A54EC93EBE2DC9B91E4C432B827884C4CC2AD8A102B46D2A2017BF45D9D4C88A564D420234484A1B2E446DBB4CD438E79C2466CE310F327773A779D24ED7B60A05A618B984757B946D67BA79F2E064E6AED38BD6559CE7FC9502720823D56DB1C034099367D7DB27B6BDAFDA8CC48347133F4A14675F675FB484CE32DF66C11A3638FA84D5BE69B1A6F238115DEF9B0F79BB25C0CB7E4A39459A0829B1FD35C0D1DBDD60F9C679D89415ED7EA41EB02FBC016FC0E792CB9698C9F4DB842CDAD5B5F5C9"^^xsd:hexBinary;
] .Nobody looses, everybody gains. We can all work together in a consistent manner without loss, and with interoperability. |
|
Can the result of this discussion become a component of the FPWD ? (I hope it is in scope. If not: a non normative component could still be helpfull ;-) (If anyone is interested in creating a JSON-LD version of Webfinger: please contact me) |
|
If we used the foaf vocabulary my guess is that we could integrate the @prefix : <http://xmlns.com/foaf/0.1/> .
@prefix cert: <http://www.w3.org/ns/auth/cert#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
[] :account <acct:bblfish@identica.ca> .
<acct:bblfish@identica.ca>
:accountName "bblfish";
:accountServiceHomepage <http://facebook.com/> .in JsonLD this looks better {
"@context": {
"foaf": "http://xmlns.com/foaf/0.1/"
},
"@type": "foaf:Person",
"foaf:account": {
"@id": "acct:bblfish@identica.ca",
"foaf:accountName": "bblfish",
"foaf:accountServiceHomepage": {"@id": "http://identica.ca/"}
}
}I am sure JSON-LD gurus can make that even more beautiful. |
|
One possibility that occurs to me i that we can prohibit acct: IDs for objects, but permit them as aliases. That is to say, my ID might be "http://example.com/~oshepherd" but if somebody enters "[acct:]oshepherd@example.com" into the "Follow somebody" box, you need to do a Webfinger (or so) lookup for "acct:oshepherd@example.com", which will give you the actual ID of my account |
|
Why try to prohibit when you can get them to work nicely together in a logically consistent way through good modelling? |
|
You still haven't told me how I take "acct:oshepherd@example.com" and actually get a dereferencable resource for that. |
|
@oshepherd I think the account scheme defines that. I am not too keen on accnt urls myself: I don't think there is a need for that indirection. But that does not stop the JSON-LD written above would be correct, if my understanding of how the {
"@context": {
"foaf": "http://xmlns.com/foaf/0.1/",
"as": "http://www.w3.org/ns/activitystreams",
},
"@type": "foaf:Person",
"foaf:account": {
"as:webfinger": "bblfish@identica.ca",
"foaf:accountName": "bblfish",
"foaf:accountServiceHomepage": {"@id": "http://identica.ca/"}
}
}since the webfinger folk is about simplicity of use to the end user, it makes sense to have this as a string. It is then quite similar to the account name. But not so similar that it does not justify having another relation. It's no more work writing than the "@id" and fits the follow your nose principle. |
|
@bblfish I suppose that @oshepherd would like to know what happens when a LDP server tries to dereference |
|
@akuckartz is that not solved by my second proposal? @prefix : <http://xmlns.com/foaf/0.1/> .
@prefix as: <http://www.w3.org/ns/activitystreams> .
[] :account [ :accountName "bblfish";
:accountServiceHomepage <http://facebook.com/>;
as:webfinger "bblfish@identica.ca" ] |
|
@bblfish We would simply parse |
|
@akuckartz ( what is "FPWD" ? ) I am not sure what you mean by "simply" . All of my proposals above are simple. How would you model it? Where would you put it in the model? Can you give me an example Turtle or JSON-LD? |
|
@bblfish "First Public Working Draft" (FPWD). Harry mentioned it on the mailing list today. |
|
You meant the to-be-written document? Can you just tell me which of the modelling proposals I put forward you'd want to put in the FPWD or if you had another one? ( that was the point of the three questions above - sorry if that felt like much, just wanted to avoid a long to and fro like we are having now ). Otherwise I can't really answer your question about whether "it" should go into FPWD. Clearly I think that there is space for LDP user agents can ignore If you are interested in writing a json-ld spec to replace the xml format they have for the XSD thinggy me bob, that would certainly be an improvement as far as learnability of the whole system goes. |
|
So if we agree that acct: can be a type of URI scheme, I don't see any problem with supporting webfinger IDs and accepting that as FYN. I know some of the group would prefer all FYN to be http or https, but oh well, accepting acct: solves this problem and allows us to preserve backwards compatibility. |
|
-1 to using webfinger. I also thought it was out of scope for the group, and legacy. It's JSON format also conflicts in a breaking way with the JSON format of this group. Let's stick to HTTP identifiers and follow your nose. Well known locations are not follow your nose. |
|
How about moving it to a "MAY support webfinger via acct"? There is a recent proposal to the IETF to formalize |
|
Minting a new URI scheme is almost always a sign of desperation. Even the guy that invented it said
http://hueniverse.com/2009/08/19/making-the-case-for-a-new-acct-uri-scheme/ There was some debate during WF standardization whether it should exists at all. And I think it's failed to get widespread adoption. The acct URI scheme was much misunderstood. It was created because the systems didnt have a syntax that said
This can certainly be done with activity stream type JSON, but cant be done with JRD style JSON, hence the need to invent a scheme. Over time it served a dual purpose as an "easy" way to denote users/accounts on services, which arguably didnt get the adoption it had hoped. The acct: URI scheme does not achieve anything that cannot be readily done with current JSON standards used in this group, so I would -1 putting it in the spec. Of course where there is a data structure that accepts a URI, which is true of activity streams, any URI can go in there including mailto:, tel: etc. But generally such things should be out of scope of the spec wording, and be left to legacy systems implementation specifics. The other major problem is that creating a parser for JRD is another high barrier and non compatible with the parser for AS. This makes a larger implementation barrier. Let's not promote URI schemes that have failed to gain widespread adoption unless we have to, and stick to those that have had great success ie HTTP and HTTPS |
|
Okay, how about this as a compromise. We put in mentions of using HTTP and HTTPS, and give clear information about how they are used, and not mention (but also not exclude) the acct: schema. How about that? |
|
Works for me... |
|
I adjusted the wording in fa38a67 making HTTPS URIs the only scheme explicitly mentioned, but it does not block the possibility of Webfinger or HTTP URIs. |
No description provided.
The text was updated successfully, but these errors were encountered: