RE: [dss] Representing requestor's identity

["jmessing" <jmessing@law-on-line.com>]

Absolutely correct. 

But what happens in the absence of such a preliminary agreement?

If there is none, then under Anglo-American common law a corporation may be bound if it gives apparent authority to someone to affix its name. Apparent authority is derived from estoppel notions. If you are foolish enough or careless enough to allow someone to appear to others as though they are legitimately acting on your behalf, then you may well be legally bound by a transaction concluded with an innocent relying party who thought the transaction was legitimate. It is a type of corporate non-repudiation doctrine that has been around for centuries, though it is not limited to entities but may also apply to individuals. It would most probably apply to a corporate DSS.

Putting the onus on the parties to create a signature policy first in order to to express these authority relationships between them is extremely inadvisable in my view. It would be cleaner to have the option to express signature authority relationships upfront in order to have express grants of authority included in the delegated signature data. 

[The foregoing is not legal advice, there is no attorney-client relationship with anyone created by this communication, and no electronic signature is intended.]

---------- Original Message ----------------------------------
From: "Nick Pope" <pope@secstan.com>
Date:  Wed, 30 Apr 2003 14:06:00 +0100

>John,
>
>Is it not possible for two parties to agree in a contract, such as an EDI
>interchange agreement, to adopt the rules for creation and validation of
>signatures as specified in a signature policy for subsequent exchanges.
>
>Nick
>
>
>
>> -----Original Message-----
>> From: jmessing [mailto:jmessing@law-on-line.com]
>> Sent: 30 April 2003 13:47
>> To: dss@lists.oasis-open.org
>> Subject: RE: [dss] Representing requestor's identity
>>
>>
>> I don't believe the subject properly falls within signature policy.
>>
>> "If no signature policy is identified then the signature may be
>> assumed to have been generated/verified without any policy
>> constraints, and hence may be given no specific legal or
>> contractual significance through the context of a signature policy."
>>
>> The common law doctrines of apparent and express authority do not
>> fit this notion of a signature policy. Other semantics are
>> required to prevent, for example, a rogue corporate signature
>> created by an unauthorized individual as a matter of law and not
>> signature policy binding a corporation to a transaction against its will.
>>
>> Without it, a corporate signature DSS could become a legal Frankenstein.
>>
>> ---------- Original Message ----------------------------------
>> From: Trevor Perrin <trevp@trevp.net>
>> Date:  Wed, 30 Apr 2003 00:34:10 -0700
>>
>> >At 11:07 PM 4/29/2003 -0400, jmessing wrote:
>> >
>> >> >
>> >> >This sounds less like signed attributes the signer would add to a
>> >> >particular signature, and more like policies, validity
>> intervals, and name
>> >> >constraints a CA would add to the DSS Server's certificate.
>> >>
>> >>I disagree. It relates to a trust relationship expressed between a
>> >>requestor and the DSS. It has nothing to do with the DSS certificate.
>> >
>> >okay.  This sounds like a signature policy then - you'd want to
>> include a
>> >SignaturePolicyIdentifer (like in XAdES 5.2.3) as a signed
>> attribute that
>> >clarifies the semantics of the signature - in this case, it
>> would clarify
>> >the relationship between the signer and requestor.  We decided not to
>> >commit ourselves to particular representations of signature
>> policies like
>> >XAdES, but this sort of additional attribute is allowed under
>> 3.2.3 of the
>> >requirements.  Is that sufficient?
>> >
>> >http://www.w3.org/TR/XAdES/#Syntax_for_XAdES_The_SignaturePolicyI
>dentifier_element
>>
>>Trevor
>>
>>
>
>
>
>