RE: transaction specific policies

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