Subject: Re: [apps-discuss] Working Group Last Call for draft-ietf-appsawg-webfinger-09

From: Salvatore Loreto <[email-masked]>
Date: Fri, 1 Feb 2013 18:21:01 +0200

someone pointed out that
the embedded link to WF, in the original announcement, takes you to the 
acct uri draft.

sorry it was a cut and paste error!

*here the right one:*
http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-09

/Salvatore

On 1/28/13 8:16 PM, Salvatore Loreto wrote:
> FYI
>
> the 2 weeks WGLC on draft-ietf-appsawg-webfinger is started.
> Please see the mail below and note that the right venue for discussion is
> the *webfinger* mailing list
>
> best regards
> Salvatore
>
> -------- Original Message --------
> Subject: 	[webfinger] Working Group Last Call for 
> draft-ietf-appsawg-webfinger-09
> Date: 	Mon, 28 Jan 2013 20:13:48 +0200
> From: 	Salvatore Loreto <[email-masked]>
> To: 	<[email-masked]>
> CC: 	Murray S. Kucherawy <[email-masked]>
>
>
>
> Dear WG partecipants,
>
>
> I would like to initiate a 2 weeks WG Last Call on
> draft-ietf-appsawg-webfinger-09.txt ("WebFinger")
> http://tools.ietf.org/id/draft-ietf-appsawg-webfinger-09.txt
>
>
> Please send your reviews, as well as expression of support regarding
> document readiness for IESG (or not) either to the *webfinger* mailing 
> list ([email-masked]),
> or directly to the WG chairs (Murray Kucherawy and myself).
>
> Comments like "I've read the document and it is Ok to publish" or
> "I've read the document and it has the following issues"
> are useful and would be gratefully accepted by chairs.
>
>
> The WG LC will end on Friday, February 8th.
>
>
> Thank you,
> Salvatore as an APPSAWG co-chair.
>
>
>
>
>
>
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 04 Feb 2013 16:03:07 -0700

On 1/30/13 10:33 AM, James M Snell wrote:
> First off, The ? syntax is already well established practice for
> many URI structures, particularly http and mailto, it makes a lot
> of sense to reuse that, particularly since many existing URI
> parsers will give you support for for free.
> 
> Second, the most I am suggesting for acct uri is the allowance of 
> optional query parameters. I am not suggesting, right now, that we
> ought to change the semantics of WebFinger's resolution... but I do
> want to leave the door open for alternative resolution mechanisms
> later. I used the ?provider=bar.com <http://bar.com> as an example
> of the basic motivation for the parameters, but there very well
> could be other interesting parameters that are worth considering.
> 
> Hypothetically, for instance, in the future we could have something
> like:
> 
> <a href="acct:[email-masked]?rel=weblog 
> <http://acct:[email-masked]?rel=weblog>" rel="weblog">Find my
> blog!</a>

Isn't <a href='https://blogs.example.net/blog'>my blog</a> a lot
easier? Why the level of indirection if all you really want to do is
link to the blog?

> Allowing for optional query parameters gives us more flexibility
> long term without introducing significant new complexity now.

Flexibility is not necessarily a good thing. The whole idea behind the
'acct' URI scheme (as I understood it) was to provide a mere
identifier of an account, not flexible ways of interacting with that
account.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 04 Feb 2013 15:56:32 -0700

[ changing both message subject and discssion venue ]

On 1/29/13 11:03 AM, James M Snell wrote:
> I'm really just now starting to turn my attention to the acct uri
> aspect of the WebFinger discussion.. generally speaking I'm +1 on
> the current draft. When going through various implementation
> scenarios, however, one thought did strike me, although it may be a
> bit too late in the game to put this on the table at all. I
> apologize for making this late suggestion...
> 
> In some scenarios, such as hosted cloud application environments,
> a service provider may wish to host the information about a given
> user within a different domain. For instance, suppose Company
> Foo.com utilizes services from ISV Bar.com. The user accounts,
> however, are drawn from Foo.com, but Bar.com is the provider that
> actually hosts the profiles and account information. What I want is
> something that identifies the user account AND the service
> provider.
> 
> Example:
> 
> acct:[email-masked]?provider=bar.com 
> <http://acct:[email-masked]?provider=bar.com>
> 
> In a WebFinger type of scenario, resolving this would involve
> something like...
> 
> GET /.well-known/webfinger?resource=[email-masked] 
> <mailto:[email-masked]> Host: bar.com <http://bar.com>
> 
> Encoding the third party provider into the URL in this way provides
> a fairly flexible way of enabling the third party support without 
> complicated redirects from foo.com <http://foo.com> to bar.com 
> <http://bar.com>. It also gives domains a way of enabling bits of 
> information to be shared from multiple sources... 
> acct:[email-masked]?provider=isv1.com 
> <http://acct:[email-masked]?provider=isv1.com> vs. 
> acct:[email-masked]?provider=isv2.com 
> <http://acct:[email-masked]?provider=isv2.com>
> 
> To enable this kind of thing, it would be helpful if the basic acct
> URI syntax allowed for optional parameters like the mailto URI
> scheme does (RFC2368). The specific parameters themselves can be
> figured out later...

<snark>
Um, isn't that what SRV records are for? Oh, yeah, I forgot, there's
no SRV for HTTP. ;-)
</snark>

There are all sorts of security issues with this kind of delegation.
In XMPP we have delegation via SRV and it's only recently (with the
promise of wider availability for DNSSEC) that we've started to
describe best practices for secure delegation.

With regard to WebFinger and 'acct' URIs, first of all we're
discouraging people from doing things like this:

<a href='acct:[email-masked]'>more about John</a>

However, people keep assuming they can do that kind of thing, so I
really do need to add some strong language to the spec discouraging
it, eh?

Second, unless such a link (with your suggested "?provider=bar.com"
query) is served over HTTPS, the delegation can't be secure.

Third, you'd need to ensure that the domainpart of the 'acct' URI
matched the domain to which you sent the HTTP request that resulted in
the return of an HTML page (say) containing said hyperlink.

Fourth, even a match there might not indicate that the author of the
HTML page (say) is authorized to say that requests for information
about [email-masked] can legitimately be served by bar.com.

IMHO this kind of delegation needs to happen at the DNS layer with
DNSSEC to be anything close to secure. However, you *might* be able to
do something slightly more secure than query parameters on the 'acct'
URI using an approach similar to the "PKIX Over Secure HTTP" proposal
that Matt Miller and I have been working on for XMPP:

http://tools.ietf.org/id/draft-miller-xmpp-posh-prooftype-01.txt

In any case, I think this is way beyond the scope of the 'acct' URI
scheme and needs to be pursued in other ways.

Peter

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

---

From: James M Snell <[email-masked]>
Date: Mon, 4 Feb 2013 19:39:18 -0800

Certainly not going to argue any of those points... the only thing I will
say is that, for now, all I'm advocating is that the acct URI ought to
allow for optional query parameters... without defining exactly what those
parameters are or what the relevant concerns are about their specific use.

- James

On Mon, Feb 4, 2013 at 2:56 PM, Peter Saint-Andre <[email-masked]>wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlEQPKAACgkQNL8k5A2w/vxwsgCdEkiU7jiI+2guubPeh6nPOOrC
> ziIAn0dcRD0dCgspsfEELREbqUUGoi8q
> =udaO
> -----END PGP SIGNATURE-----
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 18 Feb 2013 20:58:24 -0700

On 2/4/13 8:39 PM, James M Snell wrote:
> Certainly not going to argue any of those points... the only thing
> I will say is that, for now, all I'm advocating is that the acct
> URI ought to allow for optional query parameters... without
> defining exactly what those parameters are or what the relevant
> concerns are about their specific use.

To date I haven't seen anyone mention uses for query parameters on
'acct' URIs, so I'd prefer not to introduce them at this point.  If
indeed there are use cases in which a query component is needed in
order to identify or retrieve resources associated with an 'acct' URI,
I'd love to hear about them. At present my limited imagination does
not envision a compelling need for the query component here (and as
far as I can see, a query component of provider=foo does not identify
a resource associated with an account, but a method for interacting
with the account).

Peter

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