Andre,
A great improvement in the draft. I like most of it. However, I have a few
reservations detailed below.
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.
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.
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.
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?
Is it wrong for a document type to force an authentication method? Not sure.
Its definately right to support XML signing as an authentication method.
--
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