Security
Requirements
A flexible framework for security which allows
- A choice of encryption technology
- A choice of security level
- Possible use for setting up a secure channel
- Possible use in exchanging security information
with a fview to optionally incluing signed or encrypted information
within a communication or object
- A separation of policy (not to be specified) and protocol
(to be specified)
- Where possible, adopotion or overlap with the equivalent function
in other Internet protocols
- Interoperability between any parties for whom common
encryption technology and mutually acceptable levels of security
exists.
- Working with out-of-band transfer or storage of security information
Products
- A protocol for the exchange of security information
- A standard for the secure encapsulation of arbitrary objects
for secure transmisstion, given the exchange.
- A standard for the encryption of a protocol stream
- A standard for payment protocols
- Reference code implementing the above protocols
(Note that reference code will be limited to security protocol
engines, and the access control and local adminitsration
software will be minimal. This is an area in which we expect
members products to compete, and in which a major investment in
design would be useful but would be inappropriate for
the W3C)
Currrent situation
See security overview
and W3C security group.
Next move
The work is divided into two areas
Basic secure communication
The S-HTTP and SSL protocols have been put forward as a starting points for
development of the future protocol.
There are technical advantages to each, and though one might start with one, it would
be to inclde functionality of the other.
(See minutes). In this area two parallel
efforts are underway: to provide a set of scenarios which should
be enabled by the protocol, as input to the requirements process;
and a bottom-up drive to develop code modules for implementation
of the building blocks from which a reference implementation can be made.
Payment protcols
Work contributed to the group by IBM starts off
a subgroup whose aim is to define a suite of payment protocols using
common parts to achieve combination of feature set and assumptions.
TimBL
Webmaster