I'm trying to say that the authorization of the issuer is unimportant. The
restriction
applies to the instrument. The person cashing the check needs no more than
proof of identity. Nowhere in this scenario is an authorization certificate
needed,
only identification certificates.
In the computer world you would receive a content which satisfies a type
definition.
I could imagine the following (partial) definition:
PersonalCheck ::= SIGNED SEQUENCE {
number INTEGER,
date UTCTime,
issuer Name,
recipient Name,
statedValue Money,
guarantor Name
memo OCTET STRING
accountNumber AccountNumber
restrictions RestrictionList OPTIONAL,
...
}
...
If this object (instrument) were widely recognized, it could serve as a
reasonable analog for
a personal check. All attributes are constrained to the object.
Authenticating this object
would consist of validating the signature AND checking the internal
components of the object
including whether the issuer is a known check bouncer etc.
I believe that the important elements of the cheque are that an issuer I
(backed up by a gurantor) proxies to the recipient R the rights to withdraw
the stated value.
This sounds like an authorisation certificate to me containing a
capability and granted to R by I. I think that referring to it is an
"instrument" is more of a terminology issue than something fundamental.
Consider:
a) For the example you cite, R needs to present the cheque and a proof of
identity in order for the teller to encash the cheque.
b) In a distributed computing environment, say DCE1.1, a principal presents
a PAC and service ticket in order for the server to provide a service.
There seems little difference between these two cases except the
generality of the authorisation information.
Piers
Ps. I eliminated the cc:pem-dev in my previous reply to your mail as I
feel reasonably sure that this sub-thread is tangential - though I find it
interesting. I defer to your judgement in pursuing it on the list.