I see two possible solutions:
1. The quick-and-dirty "trusted host" strategy: somebody suggested
crippling your client's DNS service to only know about "approved"
hosts.
Some gethostbyname() implementations support using environment
variables to control configuration, so this could be a low-hassle
solution: you could use existing pre-compiled WWW clients. You set
some environment variable like DNS_HOSTS to a file that looks like an
/etc/hosts file, but only lists www sites that you approve of.
Even simpler: most client hosts have a "nameserver" configuration
variable somewhere: in the Mac's control panel, or something like
that. Point that to a nameserver that you cripple as above, and
you're in business.
There's a lot of trust here:
* you're trusting that your local users won't fudge with the
system to get around all this
* you're trusting the administrators of the remote hosts to
maintain complete editorial control of the material on their
hosts. If you pubt www.foo.com in the list of trusted
hosts, then the webmaster there can't
let joeuser put nudy pictures in
http://www.foo.com/~joeuser/nudies/
* you're trusting that there are no "black hats" between you
and www.foo.com that would spoof DNS to make www.foo.com point
to www.playboy.com
But all of the above is reasonable, given the relatively low cost of a
"security breach."
The other model is the industrial-grade, cryptography-based solution:
2. You configure your client to not show any information unless there
is a certificate that says it's OK. The PTA (or whatever certifying
agency) could sign keys of various institutions, and those
institutions would provide digital signatures of the data they send.
This is black-hat proof, but it relies on the local users not finding
a way around it. Like somebody (Tony Sanders?) said, if local users
can write programs or install software, they can get access to
whatever they want.
This might be suitable for stand-alone kiosks and such.
Hmmm... now that I think about it, authenticated DNS will probably be
deployed long before widespread use of cryptographically strong SOAPs.
So solution #1 may turn out to be better than solution #2, even in the
long run!
Dan