[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Another suspenseful note
> I agree that the use of a suspense feature until the user confirms receipt
> could be handled in many, perhaps most cases, by a not valid until date,
> and if the user hasn't responded by then you revoke it. The suspense
> feature might offer a little more finesse, but this application by itself
> wouldn't justify implementing it.
It has just occurred to me that what you may be referring to is what is
common in the card industry today, which is: send the customer a card
and don't honor it until he acknowledges receipt. My solution to this
would be far simpler, and conforms to my third suggestion: a policy cert
that grants the privilege only in the presence of both the just-issued
certificate and the one issued by the user confirming receipt (and also,
I suppose, contractually obligating him to responsibility for use of the
privilege). This eliminates the deadline problem, and deals with the
granting of privilege, in my view, in a more intuitive manner than
passing out a credential and immediately canceling it, which is still
vulnerable to the traditional weakness of hotlists, which is dependence
on reliable and timely delivery.
Again, the CRCert process lets the 'real' runtime credential be
generated from the original cert and the confirming cert, bound
together by the policy cert. Put another way, since the relying party
is the issuer, that analysis can be done and a certificate created that
represents the conclusion reached by the relying party and then signed
by the relying party and returned to the user for future use. This
certificate need not be available in a public directory, but only given
to the user for convenience.
Brian Thomas - Distributed Systems Architect bt0008@entropy.sbc.com
Southwestern Bell bthomas@primary.net
One Bell Center, Room 23Q1 Tel: 314 235 3141
St. Louis, MO 63101 Fax: 314 331 2755