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

[Peter Saint-Andre <[e-mail]>]

-----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-----