Andre,
A few more comments inlined.
On Monday 26 Nov 2001 8:30 pm, you wrote:
Andrew,
Section 3.7.2
i. Should a web site be able to reject services that an end user
wants actioned? For instance if a rogue website wanted to download a
virus laden executable should they be able to explicitly prevent the
download from passing through a virus scanner? This is against the wishes
of the end user.
Right, but what if a content owner offers a harmless file which a
specific virus scanner rejects for some reason? IRML can help in
detecting such problems. This does not necessarily mean that one
endpoint can prevent the service execution requests of the other
endpoint. The resolution of such conflicts would depend on the specific
application and also the local policy of the OPES intermediary. In the
virus scanning example, for instance, the ISP could notify the end user
that that the content owner wishes to prevent the execution of the virus
scanner on his content for some reason and then the end user could
decide whether or not to accept the content or not.
I'd be suspicious if a web site wanted to prevent virus checking on an
application I was downloading. This virus checker override could be just as
easily done by providing a disclaimer saying that virus checker A incorrectly
detects a virus, and having the virus checker say I think there is a virus,
do you want to download anyway? Either way you need to know more about the
specific interaction of the virus checker and the download file. Once you
knew a site had this virus checker issue, you could hack it, replace the
download with a virus, and hey presto infect people who thought they were
protected - indeed were probably paying to be protected.
Why should the web service protection be singled out over a virus checker
application running on the end users machine? Both are running on behalf of
the end user. The end users will need to be informed of the issue so that the
customers running virus checkers locally can manually override them.
Is it correct to have end users be able to prevent services running against
data from an origin server using a CDN's services to formulate the
completed page? I dont think so, particularly when the opportunity only
arises if you use the particular isp which hosts the CDN. This could be used
to circumvent security features and gain access to private internal data used
in the construction of the page. If DRM is being applied in the CDN, should
the end user be allowed to prevent the DRM service running?
I think its dangerous to prevent either content providers or end users from
running the services they see fit to run.
ii. Can IRML from the origin server and the end user interact?
The assumption that you can combine the preferences of the origin server
and the preferences of the end user is wrong. The likely application of
web services for a web site is in the CDN, and for the end user the ISP.
The interaction of the two IRML documents cannot happen, the IRML is
based in two different trust domains. The only way for such preferences
from the origin web site to pass into to the end user trusted domain
would be in the message itself. All actions explicitly requested by an
end point MUST be acted on.
I agree that if an OPES intermediary receives IRML rule modules from one
of the endpoints of a content transaction only, then there will be no
conflicts and thus all requested actions must generally be acted on.
However, in other cases, e.g. if an ISP also operates a CDN, OPES
intermediaries would receive IRML rules from both endpoints and would
have to deal with and resolve conflicts between the two endpoints - see
above.
Conflicts only arise when the irml is allowed to interact. Surely the content
is only finished once its passed via its services. Once the content is
finished its down to the end user to choose how they experience it.
iii. Service uri's. Should they include the host identifier, or should
they simply be a service name that can map either to a local proxylet or
a callout service as appropriate? I was thinking that some sort of
service discovery system/protocol would be appropriate.
The predominant opinion on the OPES list used to be that service
discovery is out of scope for IRML. In particular, it was considered bad
to statically link an IRML rule to a specific service instance because
this would prevent OPES intermediaries from dynamically choosing an
appropriate service instance at run-time.
I agree.
Section 6
iv. Explicitly forcing the use of signed IRML may be wrong. Clearly I
can see the benefits for doing it, particularly if IRML is stored on
public servers and delivered over the public internet. But when you are
providing services for the end user as an enterprise or an ISP, the
authentication of the end user will be carried out in a different manner.
Its likely that the ISP would store the IRML on behalf of the end user so
there will be no need for the ISP to further authenticate the user
document. The IRML documents are likely to be assigned in groups, so the
ISP may sign the IRML and the end user agrees to be put into the group.
Would the ISP need to reauthenticate its own documents?
I agree that it may not make so much sense to mandate the authentication
of IRML rule modules authored by delegates who are in the same domain as
the OPES intermediaries that will process the rule modules. However,
whenever rule modules have to be transferred to a different domain (and
this may even be the case for rule modules authored by delegates), there
will be a need for authentication. We should probably rephrase the
corresponding passage in the draft to clarify this a little bit.
I agree.
--
Regards,
Andrew Walker
Thundercrack Ltd.
17 Rathbone Street
London, W1T 1ND
UK
Phone: +44 020 7631 1000
EMail: andrew(_dot_)walker(_at_)thundercrack(_dot_)com
URI: http://www.thundercrack.com