Re: transaction specific policies

Dan,

Fair enough. I guess I've a (long, complicated:-) question back to you 
(and the list) though:

While it is possible to shoe-horn sufficient information about the
transaction into an xkms request, so that the responder can make
the relevant transaction policy decisions, is that a good idea, or,
is it better to let xkms simply handle keys and have some other
protocol deal with what it means for "<foo> to be a valid key that 
can verify the signature on <bar>"?

(Been a while since we opened a can of worms on this list:-)

Stephen.

> Daniel Ash wrote:
> 
> The answer is: i'm not sure.  and in any case, the spec should be more clear about managing policy
> bindings.
> 
> let me give a brief bit of history to clarify the issue.  traditionally, the use of a key is
> limited through policies in order to manage liability associated with a key.  what's emerging as a
> refinement of this concept is a model where liability can be associated with specific transactions
> rather than specific keys.  so that one key may be used within many different policy/liability
> contexts.
> 
> as an aside, one of the benefits of this approach is that transaction specific risks can be
> accomodated for in  a customized liability model, rather than one which applies to predefined set
> of uses for a key.  For example, one use may involve a payment system in which there is credit
> risk as well as identity risk.  a liability model can be established that contemplates both credit
> and identity risks.  another use may be for access control, where there is no liability since
> there is small potential damage.
> 
> so.  I haven't spent much time contemplating what part of the spec needs changing.  first, i want
> to solicit whether or not this requirement has already been considered.  sounds like it hasn't.
> 
> i can give it more thought to the spec before making suggestions.. though any thoughts would be
> helpful.
> 
> -dan
> 
> -----Original Message-----
> From: Stephen Farrell [mailto:stephen.farrell@baltimore.ie]
> Sent: Tuesday, August 20, 2002 12:27 PM
> To: Daniel Ash
> Cc: 'www-xkms@w3.org '
> Subject: Re: transaction specific policies
> 
> Dan,
> 
> Somewhere in there I got lost. Are you saying that service URL is
> fine for Identrus style environments or not?
> 
> If it is, then great!
> 
> If not, what parts of the spec need changing?
> 
> Stephen.
> 
> > Daniel Ash wrote:
> >
> > Stephen,
> >
> > I'd prefer one option as well.  It seems that useWith wasn't intended for this kind of use.
> >
> > The service URL seems to work, however, in an environment like Identrus, where a validation
> > requests is handed from one trusted third party to another, the policy binding is far more
> > manageable as part of the message itself, rather than implicit through the service URL.
> >
> > The way policy is managed within Identrus and other financial industry activities, there's a
> need
> > to bind policy to both a key and to a transaction.  key policy is always associated with a key.
> > transaction with a specific type of transaction.  I'm not sure how to bind either in XKISS.
> >
> > this seems most important if XKISS is allow third parties to manage policy bindings instead of
> the
> > user.  a user may only have one application, while a third party may manage hundreds.
> >
> > -dan
> >
> > -----Original Message-----
> > From: Stephen Farrell [mailto:stephen.farrell@baltimore.ie]
> > Sent: Tuesday, August 20, 2002 10:14 AM
> > To: Daniel Ash
> > Cc: 'www-xkms@w3.org '
> > Subject: Re: transaction specific policies
> >
> > > Daniel Ash wrote:
> > >
> > > I'm trying to understand the best way to use XKISS in a particular scenario.  one which is
> > likely
> > > to be very common in the financial community.
> > >
> > > The same key is used for multiple transaction-specific policies.  an example of this type of
> > > policy is the European Signature policy.  liability models will vary from one such policy to
> > > another.  considering the same key is used, the trusted third party must me able to monitor
> > > liability exposure in order effectively manage risks associated with the particular
> transaction
> > > type/policy.  It also would need to make the statement: "this key is valid/invalid for this
> type
> >
> > > of transaction".
> > >
> > > The options I'm aware of are:
> > > 1.)  use a different XKISS service URL for each transaction type.
> > > 2.)  extend the useWith element with custom transaction types.
> >
> > I'd generally try go for #1, but this is an implementation issue.
> >
> > > are there more options?  which is the most appropriate?
> >
> > I don't see why we want more options.
> >
> > Stephen.
> >
> > >
> > > -dan
> > > Identrus
> >
> > --
> > ____________________________________________________________
> > Stephen Farrell
> > Baltimore Technologies,   tel: (direct line) +353 1 881 6716
> > 39 Parkgate Street,                     fax: +353 1 881 7000
> > Dublin 8.                mailto:stephen.farrell@baltimore.ie
> > Ireland                             http://www.baltimore.com
> 
> --
> ____________________________________________________________
> Stephen Farrell
> Baltimore Technologies,   tel: (direct line) +353 1 881 6716
> 39 Parkgate Street,                     fax: +353 1 881 7000
> Dublin 8.                mailto:stephen.farrell@baltimore.ie
> Ireland                             http://www.baltimore.com

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:stephen.farrell@baltimore.ie
Ireland                             http://www.baltimore.com

Received on Tuesday, 20 August 2002 13:54:12 UTC