Re: [apps-discuss] delegation of acct URIs (was: Re: [webfinger] Working Group Last Call for draft-ietf-appsawg-webfinger-09)

[James M Snell <[e-mail]>]

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 <[e-mail]>wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> [ 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:[e-mail]?provider=bar.com
> > <http://acct:[e-mail]?provider=bar.com>
> >
> > In a WebFinger type of scenario, resolving this would involve
> > something like...
> >
> > GET /.well-known/webfinger?resource=[e-mail]
> > <mailto:[e-mail]> 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:[e-mail]?provider=isv1.com
> > <http://acct:[e-mail]?provider=isv1.com> vs.
> > acct:[e-mail]?provider=isv2.com
> > <http://acct:[e-mail]?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:[e-mail]'>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 [e-mail] 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/
>
>
> -----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-----
>