RE: transaction specific policies

I think the only functionality required in xkms is to reference a policy.
just an identifier.  *not* a policy statement (useless).  *not* a policy
qualifier.  *not* policy mappings... etc.  we don't need to define how to
describe policy.  just to associate with an identifier.  something like XrML
might be useful for describing policy.

x509 only deals with certificate policies... which are supposed to have
acceptable format, meaning, etc.  these policies are bound to a key.  and
therefore any use of the key.  a potentially new capability that xkms offers
is policy bound to a transaction.  this wasn't possible in x509, or CRLs.

i would suggest for xkms to say less (nothing) about the format and meaning
of a policy than x509.  maintain the ability to bind policy to a key (for
PKIs that don't use certificates).  and to add the capability to bind policy
to a transaction (cert or certless PKIs).  identifiers only.



-dan   


-----Original Message-----
From: Stephen Farrell [mailto:stephen.farrell@baltimore.ie]
Sent: Tuesday, August 20, 2002 1:55 PM
To: Daniel Ash
Cc: 'www-xkms@w3.org '
Subject: 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