[37] in WWW Security List Archive
Re: GSS API...
daemon@ATHENA.MIT.EDU (Jeff Hostetler)
Tue Aug 16 20:43:38 1994
From: jeff@spyglass.com (Jeff Hostetler)
To: dmk@allegra.att.com (Dave Kristol)
Cc: jeff@fido.spyglass.com, www-buyinfo-request@allegra.att.com,
www-security@ns1.rutgers.edu
In-Reply-To: (Your message of Tue, 16 Aug 94 15:40:32 EDT.)
<9408161942.AA05635@spyglass.com>
Date: Tue, 16 Aug 94 16:23:11 -0600
> > 2) server response:
> > 402 payment required
> > Authorization-Accept: visa ... c=US, v=$4.50
> > Authorization-Accept: amex ... c=US, v=$4.50
> I had envisioned using the Cost: response header. I think it needs
> to specify:
> - amount (e.g., 4.50)
> - currency-unit (e.g., dollars)
> - country (e.g., U.S.)
> In this context, I suspect specifying U.S. cents will be better than
> dollars. (No round-off problems or floating point....)
>
> I agree you need to specify acceptable payment methods. For some
> payment methods, like anonymous credit cards
> (http://www.research.att.com/#acc), the server might want to pass
> encrypted bank information to the client.
I'm suggesting that each 'Authorization-Accept:' line be self-contained
and that the values past the 'authorization/payment domain' be somewhat
dependent upon the domain. In this way a merchant could offer a
different cost (if, for example, they had different discounts from
different providers) and could specify multiple providers in different
countries with different costs & currencies. [There is the *delicate*
problem of how a web server legally collects money from clients in
different parts of the world and pays the necessary taxes to the
proper authorities, etc. -- I'll ignore that for now.]
> I had envisioned using the Cost: response header.
> HTTP already has ChargeTo: set aside.
Yes. These fields are available, as is the "Authorization:" header.
For these discussions, I don't want to collide with existing uses
of them.
> >
> > 3) If the user wanted to pay, the client would contact a 'payment
> > service provider' and arrange for payment via the 'visa'
> > protocol (or the 'amex' protocol). As part of the
> > transaction the client would be given an authorization
> > token.
> >
> > 4) client to http server:
> > get url
> > Authorization-From: visa ...
>
> HTTP already has ChargeTo: set aside. You could use that.... I
> imagine the client passing the server a payment limit as well as
> payment method. A client could actually forward a ChargeTo
> (Authorization-From) form to every server with a payment limit,
> assuming the user directed the client to do so. Then the server could
> apply the charge immediately, rather than reject with a 402 code.
> >
> > 5) At this point the http server would ask the 'payment service
> > provider' if it issued the token. If it did, the http
> > server sends the requested document to the client. If
> > not, it repeats the response in step 2.
In suggesting this triangle of messages, I'm trying to minimize
the assumptions of trust. In step 3 the client authorizes a
fixed amount with the 'payment service provider' (much like a
certified check where the user's account is marked). In step 4
the client sends the certificate to the http server. In step 5
the http server verifies the certificate and in doing so causes
the service provider to debit the user's account (for the
pre-approved amount) and credit the merchant's account.
By allowing the service providers to be different in step 3 and 5,
we allow the client and http server to each 'do business' with a
party they trust (ie, have an account established with). It remains
a responsibility of the service provider institution to maintain
trusted service providers and to handle the details of communication
between them. Just as banks do when cashing certified checks.
Also, I favor the triangle to foil replay attacks, if we assume
that the service provider will only validate an 'Authorization-From:'
token once (or for validate multiple times within a given time
limit, but only debit the client's account once). This assumes
that the service provider is stateful, but that seems reasonable
considering its keeping track of your account balance.
> > 2) The server may also need to issue an "Authorization-Receipt:"
> The authorization receipt should come from the payment service provider,
> no?
I meant this as a receipt from the HTTP server, indicating that
it 'cashed your check'. This might be useful to the client in
reconciling its account at, say, the end of the month. It might
also be used by the client to request documents related to the
pay-per-view document (such as the images and side-bars associated
with a journal article).
jeff
