using HTTP 'From' request header

[elf Pavlik]

Hello,

Just watched old video on webfinger with Blane:
http://vimeo.com/14830050
where he also mentions it at 19:20

I also now found this draft 'Privacy-over-Webfinger' mentioning it as well:
https://lists.gnu.org/archive/html/social-discuss/2010-07/msg00027.html#subscription_request

For a while i look forward to use this header, mostly to have customized experience while browsing by using my PUBLIC profile:
* don't ask me to click-select which language i want to see the website (using public computer on Iceland ;)
* if you support multiple calendars please show me dates using 'dreamspell' rather than 'gregorian'
* etc

Almost 2 years ago I've asked on chromium-extensions mailing list about API for making simple extension to set this header. But it still looks like not moved forward =(
https://groups.google.com/a/chromium.org/group/chromium-extensions/browse_thread/thread/2f625ad0c75b992d/e6553d86f8a3a345

for Firefox I can use Modify Headers plugin:
https://addons.mozilla.org/en-US/firefox/addon/modify-headers/
not designed for non-devs...

Anyone else here still working on this topic?

=)
~ elf Pavlik ~
--
(living strictly moneyless already for over 2 years)
http://wwelves.org/perpetual-tripper
http://moneyless.info
http://hackers4peace.net

[Paul E. Jones]

We're still working on it. We published a draft here:
http://tools.ietf.org/html/draft-jones-appsawg-webfinger

I've already received a number of comments and plan to make a lot of changes to the text and re-submit a revised draft when I get a moment.

My thinking for the link relations is that we ought to investigate using the registry that was established by RFC 5988. So, rather than have link relations sprinkled around the web, should we centralize them at IANA?

Paul

[Peter Saint-Andre]

On 12/14/11 10:18 AM, Paul E. Jones wrote:
> We're still working on it. We published a draft here:
> http://tools.ietf.org/html/draft-jones-appsawg-webfinger
>
> I've already received a number of comments and plan to make a lot of
> changes to the text and re-submit a revised draft when I get a
> moment.

Excellent.

> My thinking for the link relations is that we ought to investigate
> using the registry that was established by RFC 5988. So, rather than
> have link relations sprinkled around the web, should we centralize
> them at IANA?

s/investigate using/use/

;-)

/psa

[Kingsley Idehen]

On 12/14/11 12:18 PM, Paul E. Jones wrote:
> We're still working on it. We published a draft here:
> http://tools.ietf.org/html/draft-jones-appsawg-webfinger
>
> I've already received a number of comments and plan to make a lot of changes to the text and re-submit a revised draft when I get a moment.
>
> My thinking for the link relations is that we ought to investigate using the registry that was established by RFC 5988. So, rather than have link relations sprinkled around the web, should we centralize them at IANA?

+1

Kingsley

--

Regards,

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

[Gonzalo Salgueiro]

I'm in full agreement here and immediately see the benefit of such centralization. 

Peter - What is the best way to kick that off?  I suppose a separate draft/RFC would be required  to establish an IANA registry for link relations.  If so, I can get started on making that happen.

Regards,

Gonzalo

;-)

/psa

[Gonzalo Salgueiro]

Kindly disregard this question. I just noticed 5988 did just this...Doh!

Regards,

Gonzalo

'

Regards,

Gonzalo

;-)

/psa

[Peter Saint-Andre]

On 12/14/11 12:11 PM, Gonzalo Salgueiro wrote:
>
> On Dec 14, 2011, at 12:26 PM, Peter Saint-Andre wrote:
>
>> On 12/14/11 10:18 AM, Paul E. Jones wrote:

<snip/>

>>> My thinking for the link relations is that we ought to investigate
>>> using the registry that was established by RFC 5988. So, rather than
>>> have link relations sprinkled around the web, should we centralize
>>> them at IANA?
>>
>> s/investigate using/use/
>>
> I'm in full agreement here and immediately see the benefit of such
> centralization.
>
> Peter - What is the best way to kick that off? I suppose a separate
> draft/RFC would be required to establish an IANA registry for link
> relations. If so, I can get started on making that happen.

Mark Nottingham (cc'd) already did that work for you... :)

http://tools.ietf.org/html/rfc5988

The registry is here:

http://www.iana.org/assignments/link-relations/link-relations.xml

Instructions for registering new relations are here:

http://tools.ietf.org/html/rfc5988#section-6.2.1

However, Mark might be simplifying those procedures (in line with recent
thinking about making it easier to interact with IANA).

Some examples of forthcoming relation registrations can be found in
three documents that I'm currently shepherding at the IETF:

https://datatracker.ietf.org/doc/draft-ohye-canonical-link-relation/

https://datatracker.ietf.org/doc/draft-amundsen-item-and-collection-link-relations/

https://datatracker.ietf.org/doc/draft-yevstifeyev-disclosure-relation/

Peter

--
Peter Saint-Andre
https://stpeter.im/

[Peter Saint-Andre]

On 12/14/11 3:07 PM, Mark Nottingham wrote:
> Would be glad to help if people need it; as Peter mentioned, we're
> starting to talk about making registration simpler (see
> <http://www.w3.org/wiki/FriendlyRegistries> and related for a sense
> of where that's going).

Thanks, Mark.

> P.S. Where does 'From' come into this?

I don't remember that part of the thread. :)

[elf Pavlik]

Excerpts from Peter Saint-Andre's message of 2011-12-14 22:13:12 +0000:

i started 2 threads within 30min. and they got mixed up...
my original post on Common Link Relations in webfinger you can see here:
https://groups.google.com/group/webfinger/browse_thread/thread/5e3bd11c4595de5b

which mentions relations like:
rel="http://www.w3.org/2002/07/owl#sameAs"

and links to webfinger wiki with more uri based relations:
https://code.google.com/p/webfinger/wiki/CommonLinkRelations

i'll just FWD it to you... so we get back on thread with matching subject ;)

cheers!

[elf Pavlik]

Excerpts from Paul E. Jones's message of 2011-12-14 17:18:43 +0000:

> We're still working on it. We published a draft here:
> http://tools.ietf.org/html/draft-jones-appsawg-webfinger
>
> I've already received a number of comments and plan to make a lot of changes to the text and re-submit a revised draft when I get a moment.

thanks! looks promising =)

but what about using HTTP 'From' header which I mention in subject, anyone still investigates it?
BTW after pinging the old thread from chromium, i found out that they have beta API which should make possible creating extension for it...

>
> My thinking for the link relations is that we ought to investigate using the registry that was established by RFC 5988. So, rather than have link relations sprinkled around the web, should we centralize them at IANA?

ok, let's maybe move conversation on link relations back on the other thread to avoid confusion because of unrelated subject...

cheers!

[Paul E. Jones]

Oh, I missed the question about the "From" header. Where is that proposed?

Paul

> -----Original Message-----
> From: webf...@googlegroups.com [mailto:webf...@googlegroups.com] On
> Behalf Of elf Pavlik

[elf Pavlik]

Excerpts from Paul E. Jones's message of 2011-12-15 00:41:20 +0000:

> Oh, I missed the question about the "From" header. Where is that proposed?

I've spotted Blane mentioning it in a video which I linked in my original mail:
http://vimeo.com/14830050 (at 19:20)

as well as in an old Blane's experimental spec draft:
'Privacy-over-Webfinger'
https://lists.gnu.org/archive/html/social-discuss/2010-07/msg00027.html#subscription_request

I've investigated taking advantage of it a bit while ago and have found it exciting that it have already appeared in webfinger community =)

[Paul E. Jones]

With the syntax I saw, there is no associated security, so it's not clear to me what benefit "From" would offer.

Blaine, can you share more about this? Is "From" something we should introduce into Webfinger, or is this something that should be considered at a later point?

Paul

> -----Original Message-----
> From: elf Pavlik [mailto:perpetua...@wwelves.org]
> Sent: Thursday, December 15, 2011 5:17 AM
> To: Paul E. Jones
> Cc: webfinger; romeda; henry.story
> Subject: RE: using HTTP 'From' request header
>

[elf Pavlik]

Excerpts from Paul E. Jones's message of 2011-12-16 14:10:43 +0000:

> With the syntax I saw, there is no associated security, so it's not clear to me what benefit "From" would offer.

well, once i set it in a browser a site which i vist for the first time doesn't need to ask me for it, and for example can set language and variant of calendar which i state (somehow) in the referenced PUBLIC profile =)

> Blaine, can you share more about this? Is "From" something we should introduce into Webfinger, or is this something that should be considered at a later point?

i would also like to heae Blaine comment on it! IMHO we don't need to go at this moment any further than mentioning this possibility in some 'informative' section...

[Blaine Cook]

On 16 December 2011 14:10, Paul E. Jones <pau...@packetizer.com>
wrote:> With the syntax I saw, there is no associated security, so

it's not clear to me what benefit "From" would offer.>> Blaine, can
you share more about this?  Is "From" something we should introduce
into Webfinger, or is this something that should be considered at a
later point?

The "From" header is something that's been included in HTTP[1] since
very early days, but, as Paul points out, there's no security
associated with it so it was never used. Therefore, the header itself
doesn't need to be specified.

The proposal that I've passed around and talked about is to combine
the From header with webfinger to enable secure, authenticated HTTP
requests. I've always considered this to be more important in the
federated social web case, and less important for authenticating users
who are using a web browser (or desktop / mobile client) since
cookies, Basic Auth and OAuth already handle those cases, though
various schemes can be imagined for the latter.

Essentially, the use case is that Bob wants to subscribe to Alice's
private feed on alice.com, but Bob wants to do so without signing up
at alice.com; he wants to use bob.com for his subscription.

Currently the web offers no way to make this happen. Either Alice
publishes public data (as happens with RSS / Atom), or Bob signs up to
alice.com to gain authorisation.

Using the From address, combined with Webfinger and a (hypothetical)
rel=delegate link, Bob can designate requests from bob.com as being
trusted by "him"; i.e., his email address.

I've attached a flow diagram that describes the process for the
PubSubHubbub scenario. Note that cryptography could be used instead of
dial-back authentication, but I worry that cryptographic approaches
will be too complicated, especially for early deployment.

I've resisted standardising this process, since the only place I've
seen it work is over XMPP, and I'd like to see some examples in the
wild before working on standards to support the process (especially
given that each delegation and negotiation flow will vary slightly
from application to application).

Hope that helps explain my thinking on this – there was broad
consensus that it's a Good Idea™ at the W3C TPAC in San Jose recently,
and I'd be glad to elaborate more on specific points where it'd be
helpful.

b.

[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.22

[Kingsley Idehen]

On 12/16/11 10:30 AM, Blaine Cook wrote:
> Essentially, the use case is that Bob wants to subscribe to Alice's
> private feed on alice.com, but Bob wants to do so without signing up
> at alice.com; he wants to use bob.com for his subscription.
>
> Currently the web offers no way to make this happen. Either Alice
> publishes public data (as happens with RSS / Atom), or Bob signs up to
> alice.com to gain authorisation.

You can achieve this using WebID based ACLs and Semantic Pingbacks
(Pingback Protocol + WebID)

1. Alice and Bob both obtain WebIDs.
2. Alice publishes her feeds with an ACL specifically for her friend /
circles network (Bob might not be a member, just yet).
3. Bob sends a Ping to Alice (this will show up in her stream i.e., no
different to seen a new blog post re. old blogosphere patter prior to
Pingback death by Spam)
4. Alice adds Bob to her feeds ACL.

WebID leverages PKI, but PKI doesn't need to be hard for users. It can
be simple across multiple platforms.

See:

1. http://id.myopenlink.net/certgen/ - simple Cert. Generator that
produces x.509 certs. with WebID watermarks (these can include mailto:
and acct: scheme URIs, and this service also leverages Webfinger when
such are used as WebIDs in Certs. SAN)
2. http://id.myopenlink.net/ods/webid_demo.html -- simple WebID
verification service
3. http://goo.gl/Ffg7R -- using Facebook as a WebID IdP
4. http://goo.gl/C1g4K -- using Twitter as a WebID IdP
5. http://goo.gl/a8InL -- using an AtomPub compliant blog (e.g., Blogger
/ Blogspot and WordPress) as a WebID IdP .

[Blaine Cook]

On 16 December 2011 16:25, Kingsley Idehen <kid...@openlinksw.com> wrote:
> You can achieve this using WebID based ACLs and Semantic Pingbacks (Pingback
> Protocol + WebID)
>
> 1. Alice and Bob both obtain WebIDs.
> 2. Alice publishes her feeds with an ACL specifically for her friend /
> circles network (Bob might not be a member, just yet).
> 3. Bob sends a Ping to Alice (this will show up in her stream i.e., no
> different to seen a new blog post re. old blogosphere patter prior to
> Pingback death by Spam)
> 4. Alice adds Bob to her feeds ACL.
>
> WebID leverages PKI, but PKI doesn't need to be hard for users. It can be
> simple across multiple platforms.

There are all sorts of ways to accomplish this use-case, and as far as
I'm concerned, WebID == Webfinger + Crypto, so I see this proposal as
pretty much isomorphic to the one I've offered (hence my reluctance to
forward written-down standards – we won't know how this will actually
work until it actually works).

One thing I would caution is that ACLs shouldn't be part of whatever
spec ends up being written; OAuth, for example, has a large assumption
that the service provider will manage some kind of ACL, but it's
entirely up to the service provider to determine what that looks like;
the ACLs aren't published, nor should they be (at least in the core
specification).

b.

[Kingsley Idehen]

Yes, I agree re. ACLs. They aren't part of WebID just an application of
WebID :-)

[Paul E. Jones]

Blaine,

I like the idea of having a callback to verify that the subscriber is really the subscriber. I noted in the flows, though, that you're not proposing use of "From" with Webfinger, but with the subscription request.

Getting off topic, but...

This certainly looks like a good approach to enable distributed and "controlled" microblogging to happen ... something I think would be useful. Taking the "circles" concept into consideration, when Alice requests to subscribe to Bob, would Bob's server provide a unique feed for each circle? What I think would be interesting is that if Alice subscribed the his feed, but the server actually provided her with her own URI. This would allow Bob to place Alice into whatever circle he wanted and querying the microblog given one URI or another would result in a different feed based depending on how the subscriber is put into circles. (I assume you're not proposing a push mechanism... if so, I'd be curious to know how that would work.)

Paul