Title: DSS Use Cases...
Comments inline.
SOAP Signing
This scenario has a 3rd party Web service
requester or service provider calling out to the Digital Signature Service
interface for the application of a signature to some SOAP payload (and
potentially envelope elements) before sending the signed SOAP message to the
other participant. This scenario is identical to the Corporate Seal
scenario except for the entities involved. In particular, it is not
expected that the Digital Signature Server will need to understand, parse,
or formulate SOAP-compliant messages: as with the Corporate Seal
scenario, the data it receives will be an opaque binary "blob" and the data
it returns will be an XML Signature on that "blob".
A variant of this scenario has the request
coming not directly from the application itself but from a so-called SOAP
gateway sitting in front of the application. The Digital Signature Server
(and any future Relying Parties) will be unaffected by such a modification
to the architecture.
[Nick Pope]
I see this scenario as being significantly diffierent from the
corporate scenario in that the the SOAP signature is only for authentication
of the request at the time of the transaction. Hence it does not
have the need to have the same strength of evidential value as corporate
signatures indicating intent.
[Hal
Lockhart]
I disagree. As I understand it the use
of a SOAP gateway, rather than an Application Server or some other approach
is simply an implementation choice. The organization could change its
implimentation at any point and it would have no implications for
application semantics. (Rereading you comment, perhaps that is not what you
intended. If so disregard this
comment.)
You do raise an important point, which
as far as I can tell has pretty much been avoided by the groups dealing with
related standards. (Which perhaps means we should dodge it also.) That is
the semantics of signatures. Dsig, WSS nor any other standard addresses
this. I assume that this means the sematics are application specific and up
to some mutual agreement between the
parties.
I see no reason to believe the the
semantics are dictated by where the signature appears. What can't the SOAP
message be a purchase order for $4M? Why can't the corporate seal be on the
Annual Report?
<<...OLE_Obj...>>
Identified Requester
In this scenario, the Digital Signature Server is
signing on behalf of an individual requester and makes an assertion to that
effect in the returned response. This scenario differs from those of
Corporate Seal and SOAP Signing in that the identity of the requester is not
returned in the response in those scenarios.
Where the actual Service Requester is itself
acting on behalf of some other entity (e.g., a browser-based application
requesting a digital signature for the individual), it may be relevant for
the Digital Signature Server to assert the complete request chain in the
response it returns.
The Digital Signature Server may sign all data
with its own private key and simply include the name or identifier of the
requester(s) within the scope of the data that is signed.
Alternatively, the Digital Signature Server may sign on behalf of a
requester using the requester's private key, which is stored at the
Server. In either design, this use case may be motivated by
assumptions regarding efficiency (e.g., hardware-assisted cryptography),
centralized policy management and enforcement, and assurances with respect
to safeguarding of private keys.
Identified Requester can be regarded as a variant
of the other two use-case scenarios.
[Nick
Pope]
I am not sure I follow when the case of
one identity acting on behalf of another applies. I would have though
in the case of the individual reuqets the signature relates to an
individual. In the case of a corporate signature there made be
elements of the identified signatory which includes both the
corporation, on whose behalf the signature is created, and the individual or
computer system creating the acting for the corporation which may be needed
for accountability purposes.
I presume that this case of individual signatures only applies to
authentication required for real time access. Not for long term
evidence of intent.
[Hal
Lockhart]
I think many corporations would want
to use this type of scenario as an operation convenience or to better
protect the signing keys. They would consider that some other type of
authentication to the DSS, such as password/SSL was sufficient.
Afterall, companies issue checks and documents signed by the image of a
handwritten signature all the time. It is up to them to have adequate
safeguards to prevent misuse. Hell, I have worked at service bureaus that
printed checks for other companies. For that matter, all the currency inb my
wallet was "signed" by the Secretary of the
Treasury.
ADDITIONAL
SCENARIOS
Individual
Signatures
In the case of an individal signing an electronic agreement, for
example hire purchase, it is necessary to ensure the intent of the signatory
and protect again later repudiation of the signature.
[Hal Lockhart] I am not familiar with
the term "hire purchase"
Long Term Corporate
Signatures
In
the case of say a government minister issuing a statement on behalf of his
department in may be necessary for that statement to be verifiable some time
later. In the UK public electronic some records need to be kept for 30
years.
This brings in the need to ensure that signatures are checked and
re-protected on a regular basis as certificates are likely to have
expired. The revocation information applicable at the time of
signature creation also needs to be maintained.
[Hal Lockhart] This is
a difficult general problem. I suggest we not try to solve
it.
