RE: transaction specific policies

Here's my first stab at it.  might not be the most appropriate name.  and
i'm not sure if everyone will agree on including the example reference
(though it's good example).  also, not sure if it should go in KeyBindings
or not.

Element <TransactionPolicy>

The <TransactionPolicy> element specifies a URI identifier for the policy
terms associated with a validation request/response.  The URI MAY be a name
(URN), a locator (URL) or anything else permitted by the URI specification.
This standard does not prescribe content or format of such policies.

The policy identifier is not intended to provide viewable set of terms to a
client.  The actual policy, or viewable set of terms, SHOULD be negotiated
prior to the subscription of a trust service.  The purpose of the identifier
is to allow the trust service to assert that the key in question is valid in
the context of the specified use, or policy.  The policy MAY contain any
rules, or liabilities associated with the validation service and the
application for which the service applies.  An example of a transaction
policy is described in the ETSI Signature Policy Report (ETSI TR 102 041).


-dan

 >-----Original Message-----
 >From: Stephen Farrell [ mailto:stephen.farrell@baltimore.ie
<mailto:stephen.farrell@baltimore.ie> ]
 >Sent: Wednesday, August 21, 2002 10:12 AM
 >To: Daniel Ash
 >Cc: ''www-xkms@w3.org ' '; 'reagle@w3.org '
 >Subject: Re: transaction specific policies
 >
 >
 >
 >
 >> Daniel Ash wrote:
 >>
 >> Many Policy Identifiers will likely be the shared across
 >multiple providers.  So a policy URI
 >> would probably be more suitable.
 >
 >Hmm. Personally, I'm not convinced, since I think URIs are
 >cheap, except when they
 >have to be configured into clients - I prefer munging as many
 >xkms settings as possible
 >into the responder URI, since that way the client has less
 >(and possibly minimal)
 >configuration.
 >
 >However, I realise that others might not agree.
 >
 >> I can draft a description of transaction policy, and how it
 >can be used to give meaning to
 >> 'validate', if someone else can deal with where to put it
 >and the xml.
 >
 >Ok. Why not do that and then we can see if there's concensus
 >on including it
 >in the spec. (Thanks for volunteering.)
 >
 >> As for "unbelievable stuff" being embedded, i would be more
 >worried about elements like
 >> 'ProcessInfo', and 'UseWith'.  these are loosely defined
 >and left open for extensibility (for
 >> what?).
 >
 >One of the problems with extensibility I guess - people make
 >unexpected uses
 >of it.
 >
 >Cheers,
 >Stephen.
 >
 >>
 >> -dan