diffuse - guide to trust services and building blocks of trust - ttp

8/14/2019 Diffuse - Guide to Trust Services and Building Blocks of Trust - TTP

http://slidepdf.com/reader/full/diffuse-guide-to-trust-services-and-building-blocks-of-trust-ttp 1/27

What's New

Reference Business Guides Standards List Standards Fora List RTD Project List

News Electronic Commerce

Information Management Information Society RTD Standards Conferences

User Support Index Search Help Desk

Background

About IST About Diffuse Diffuse FAQ RTD Initiatives IPR Statement Disclaimer

This guide examines trust services from theperspective of open information interchange. Ithas the following structure:

1. A System of Trust 2. Trusted Third Parties 3. The Building Blocks of Trust 4. Examples of Trust Services

This guide should be read in conjunction with the Diffuse Guide to Information Security, whichprovides further information on the guidelines,criteria and technical building blocks for themanagement and use of trusted third partyservices, as well as guidelines on themanagement of information security in general.

1. A System of TrustA System of Trust is an environment wherebyentities (Administrations, Businesses,Consumers) may trade or transact with eachother with the confidence that all entities are whothey claim to be, conduct business in accordancewith their functional obligations, and in which allexchanges between parties are secure.

It should be noted that 'security' is a subjectiveterm, but may be defined as an acceptablebalance of threats against safeguards for aparticular circumstance. Central to a system of trust is an acceptable level of security for a giventask or activity. Further information is provided

Guide to TrustServices

of 27Diffuse Guide to Trust Services

7/6/2003http://www.diffuse.org/trust.html



in the Guide to Information Security.

In open information interchange, and particularlyin the context of Electronic Commerce, a trustedsystem typically involves the presence of one or

more third parties who act as an intermediarybetween the main transacting entities. Suchintermediaries may change the value of thetransaction by altering or adding to it (e.g. agoods forwarding agent). Alternatively, they mayprovide information/support services which donot fundamentally alter the value of thetransaction itself (e.g. electronic catalogue

hosting). These intermediaries are termed'Trusted Third Parties' or 'TTPs'; they collectivelyprovide the 'System of Trust'.

TTPs are widespread and divergent. They arepresent in the traditional trading environments,for example, a bank as a TTP between a buyerand a seller; or in less apparent environments, forexample, a security alarm company as a TTP

between a household and the police. Within thecontext of an electronic open informationinterchange environment, the status andimplementation of a system of trust and the useof TTPs are of considerable interest andimportance. Two features highlight theimportance of the role of TTPs:

! Electronic Commerce has brought new

business models and practices to the tradingenvironment and user confidence is requiredfor the new electronic systems. TTPs cansignificantly enhance confidence in thesesystems

! The global and virtual nature of ElectronicCommerce means that buyers and sellers





often do not, and need not, have anyphysical contact or direct knowledge of eachother. TTPs can be used to provide such alink.

As well as the confidence in the management of the infrastructure of a trusted environment, userswould need to be satisfied that there is anadequate technical environment available so thatthe transactions within that environment canthemselves be trusted.

Moreover, in the context of open informationinterchange, users would need to know moreabout the content so that they can decide whetheror not to retrieve an information object or who isassociated with an object that is provided. If theinformation object is a report, who has reviewedthe report and given it a "seal of approval"? Doesthe information really originate from the claimedauthor? If the information object is a softwareprogram, who has checked it to see that it does

what it claims to do and does not contain anyviruses? What computing resource does it need?What support is available for it?

Users therefore require information about theinformation ("meta-information") so that theycan reach conclusions about trusting what isprovided via open networks such as the Internet.Underpinning trust services is a Common Trust

Management Environment. The main aspects of this environment are:

! Provisioning and operation of Trusted ThirdParties and specific services that TTPs offer

! Technical building blocks to provide acommon and interoperable basis for the





system of trust -- The Building Blocks of Trust.

2. Trusted Third Parties

2.1 Overview

Trusted Third Parties (TTPs) offer a vehicle bywhich an entity can deliver assurances betweenits subdivisions, between itself and its customers,and between itself and its correspondentinstitutions. An institution may choose to set upan internal TTP function or use an externalprovider of TTP services. The provision of TTP

function/services includes the provision of guidance for designing and implementing a TTP,management and operation of the TTP, and theinterworking of TTPs.

Entities that intend to use TTP services shouldconsider the following aspects of trustedservices, which are particularly important formost communities:

! Generic security requirements of TTPs! Establishment of a security policy! Provision of security solutions and

mechanisms! Operational use and management of TTP

service security! Responsibilities of TTPs!

Services levels which TTP's can provide! Interworking constraints/rules of TTPs! The roles, positions and relationships of

TTPs and other related entities (e.g. network service providers, end users, etc.)

These can be categorized and are addressed in





the following subsections.

! Management and Operation ! Network of TTPs ! Basic Obligations ! Basic Services ! Supplementary Services.

2.2 Management and Operation

A TTP function, whether internally or externallyprovided, can only add value when the users of the services are assured of the quality of the TTPfunction. Before contracting with a provider or

starting operation of an internal system, the entitymust satisfy itself that the following issues areaddressed (these issues are often known asassurances):

! Trust: Is the TTP organized, controlled andregulated in such a way that its operationcan be relied upon, checked and verified?

! Accreditation: Is the TTP accredited byrecognized national, regional, orinternational groups?

! Quality of service: For example, when is theTTP service available? What is the minimallevel of service offered?

! Audit and accountability: Are the quality of service criteria being met? How is thisindependently proven? To whom is the TTP

accountable if the criteria are not met?! Compliance: Is the TTP operating in

compliance with accepted industry standardsand all relevant regulation?

! Contract: Is there a legally binding contractin place covering the provision of serviceand addressing all the relevant issues? Are





there contracts with co-operating TTPs thatalso address these concerns?

! Liability: Is there a clear understanding as toissues of liability? Under what circumstancesis the TTP liable for damages? Does the TTPhave sufficient resources or insurance tomeet its potential liabilities?

! Policy Statement: Does the TTP have asecurity policy covering technical,administrative, procedural and organizationalrequirements?

! Confidentiality: How is the confidentiality of information ensured?

Standards and Specifications There are no specific standards withinthis area. The following genericarchitecture specifications are, however,of relevance:

! ISO/IEC 10181:1996 Informationtechnology - Open Systems Interconnection -

Security frameworks for open systems. (Part1: Overview; Part 2: Authenticationframework; Part 3: Access controlframework; Part 4: Non-repudiationframework; Part 5: Confidentialityframework; Part 6: Integrity framework; Part7: Security audit and alarms framework)

! ISO/IEC TR 13335:1996 Informationtechnology - Security techniques - Guidelines

for IT Security (GMITS) ! ISO/IEC 15408 Information technology --

Security techniques -- Evaluation criteria for IT Security

! ISO/IEC TR 15443 A framework for IT security assurance

! ISO/IEC 15446 Guide on the Production of





Protection Profiles and Security Techniques ! ETSI EG 201 057 V1.1.2 (1997)

Requirements for TTP services ! BS 7799:1999 British Standard for

Information Security Management ! ISO/IEC 17799:2000 Information

technology -- Code of practice for information security management (equivalent to BS 7799-1:1999)

! US DoD 5200.28-STD (December 1985) Department of Defense (DoD) Trusted Computer System Evaluation Criteria

! US NIST Common Criteria for Information

Technology Security Evaluation ! The Open Group Common Data Security

Architecture (CDSA)

Please refer to the Guide to ElectronicCommerce Regulation regarding developments inthis area.

2.3 Network of TTPs

The electronic TTP concept is relatively new anda network of co-operating TTPs must bedeveloped before the full potential of TTPs willbe realized. This network must be developedwhilst ensuring that TTPs can independentlymaintain their assurances. The fact thatcompetition between TTPs suppliers may reducecosts at the expense of offering reduced levels of

service must be balanced against the fact thatthere should be open competition of TTPsuppliers to ensure free market principles. This ismost often addressed, as it is with other serviceindustries (e.g. banks), via the availability of supervisory or licensing authorities.





It is of paramount importance to preserveconfidence to all parties dealing with TTPs. Thetwo principles for such a network are adichotomy:

! Mutual Co-operation and Respect -- throughCo-operation guidelines

! Isolation and Self-security -- throughSeparating trusted networks

2.3.1 Co-operation guidelines

In order to support a network of TrustedServices, individual services have to make

mutual recognition agreements with each otherabout, for example, cross certification of eachother's certificates and mutual liability withrespect both to the services offered and theholding of, or access to, related keys. Thesemutual agreements are much easier and moreeffective if there are generally agreed codes of practice and management guidelines for theoperation of trusted services. Accreditation of trusted services promotes development andacceptance of the services. Agreements then haveto be made between service providers and usersabout their mutual responsibilities and liabilitiesconcerning the services offered and thecryptographic keys associated with them.

Standards and Specifications

! ISO/IEC CD TR 14516: Guidelines for theuse and management of Trusted Third Parties. (common text for proposed ITU-TRecommendation X.842)

2.3.2 Separating trusted networks





With networks being joined together in a web of trust, it is prudent for organizations to protecttheir networks from the external world withrespect to security threats such as hackers and, toan extent, viruses. This is particularly apparent ina web that joins enterprise networks withuncontrolled, open networks such as the Internet.

'Firewalls' are the term given to devices(hardware and/or software) whose purpose is toestablish such safe connections by standingbetween elements of a network system. Afirewall is a collection of components that

controls the traffic flow between networks,generally based on content, request or origin.Such a system may permit or deny network traffic according to an organization's definedsecurity policy on which traffic should bepermitted and which should be blocked.Firewalls can solve all security problems, forexample, 'inside' jobs or application level issues.Basic security issues include: can a malicious

client:

! Get access to sensitive data! Trick the server to perform illegal operations! Trick a programme to perform illegal

operations! Upload and execute an external program.

There are two different approaches to build a

firewall: advanced packet screen/filtering worksat the network level and application levelgateways, usually defined as proxy. The mostefficient firewalls are based on combinations of both.






! RFC 1928 (IETF): SOCKS Protocol Version5. Security of messages passed acrossfirewalls

! RFC 1929 (IETF): Username/Password Authentication for SOCKS V5. Security of messages passed across firewalls

! IEEE 802.10 Interoperable LAN Security(SILS). Security of local, wide andmetropolitan area networks.

See Firewalls and System Security inthe Information Security Standards section of the Diffuse Standards and

Specifications List for furtherinformation.

2.4 Basic Obligations

There are a number of legal issues that are of special concern in connection to TTPs:

! Archival and retrieval: The level of requirements for record retrieval. Thecontract with a TTP should be specific aboutissues relating to maintenance of keys usedfor encryption, authentication, and digitalsignatures, as these may need to bereproduced many years after the transactionsfor which they were used.

! Liability: Liability for the misfeasance,malfeasance, or non-feasance ('feasance'

being condition or obligation) of the TTP toinclude direct and consequential damagesmust also be fully understood and agreedupon. The TTP must have adequate financialreserves or insurance to meet any liability.

! Privacy: Institutions in many jurisdictions,particularly those relating to financial or





ethical professions, are obliged to protect theprivacy rights of individuals, especiallysafeguarding personal data. Theseobligations are sometimes at odds with therequirement of law enforcement to accessinformation. The contract with an externalTTP, or the operating procedures of aninternal TTP must address both theseconcerns.

See section 3.5 for a wider discussion on privacypractices and agreement.

Standards and Specifications See section 3.5 for specifications in theprivacy area.

2.5 Basic Services

The basic services of a TTP are: generation of cryptographic material, key escrow, keydistribution, key revocation, certification,directory, authentication etc. Often these areenveloped into what is termed a 'Public KeyInfrastructure'. They are discussed in detail in theKey Infrastructure section of the Guide to Information Security.

2.6 Supplementary Services

2.6.1 Overview

There are many additional services that can beoffered in a TTP network. These are termed'Supplementary', 'End' or 'Ancillary' services. Asthe Electronic Commerce age develops, it ishighly likely that the list of example services (seebelow) will grow significantly. Some of the moremajor/apparent activities are described within the





following subsections:

! Archive: The deposit of information! Timestamping: Providing evidentiary time

stamps to records or transactions! Non-repudiation: Ensuring evidence of

transmission or origination! Entity authentication: Ensuring the

correctness of the entities involved! Notary: The attestation that something has

been done! Audit: The recording of some action! Reliability assessment: An entity advising

others who receive digital signatures aboutthe reasonableness of reliance on thosedigital signatures

! Message corroboration service: A personwho creates a hash result to fix the messagecontent and then timestamps the messageand/or hash result. Message corroborationrelates only to message content and timingand does not include a digital signature, so it

provides no evidence of the origin of themessage

! Information brokering: An intermediary inthe relationship between the user of information and the provider

! Payment and billing: Taking payment fromusers of information and other electronicallydistributed goods on behalf of providers, forexample a copyright use and billing service

! Financial responsibility service: A personaiding a certification authority in satisfyingthe financial responsibility requirements.Such a person could be a surety issuing abond, a bank issuing a letter of credit or aliability insurance carrier.





! Registration services: Holding informationabout the attributes of a person or legalentity; this service can also be seen as asupport service to a service such as accesscontrol

! Directory services: Providing informationabout persons or legal entities so that theycan be contacted or their certificates can belocated

! Electronic messaging -- e.g. via ValueAdded Networks.

In general, for each service, codes of practice and

guidelines as well as technical specifications arerequired to enable providers to define the service,its quality, the agreements to be made byproviders of the service with other providers, andthe agreements to be made by users of the servicewith the providers.

2.6.2 Archive services

Record keeping is required for a certificationauthority, repository and users of trust services.The records may be kept off-line for backuppurposes, for occasional reference, for risk management, or for any other legal purpose. Anarchive service differs from a repository in thatthe archive needs not be readily accessible on-line, but should be durable in light of availabletechnology. Retention needs and duration will

vary depending on the requirements or standardsestablished by applicable law, records retentionand other management policies. Archived recordsbesides certificates may be needed in disputeresolution to support the certification authoritiesidentification of the subscriber, otherrepresentations in the certificate, or possibly the





basis for revoking the certificate.

Standards and Specifications There are no known specific standardsin this field.

For general information on archiving,see the Guide to Archiving.

2.6.3 Timestamping services

Often it is necessary to timestamp a transactionsince the message may be time critical (e.g. proof of transmission date) or may be useful if

problems are generated later in the businesscycle. For example, if the certificate of a publickey is cancelled on the grounds that thecorresponding secret key has been compromised,a previously calculated digital signature by thesaid secret key would retain its legal value, if anindependent timestamping service had takenplace before the cancellation of the certificate.The user simply collects any number of digital

signatures over a period of time (e.g. one day,one month, ...) and sends it off to a TTP fortimestamping. The TTP adds the timestamp and adigital signature and returns the message.

Standards and Specifications A series of Internet X.509specifications has been developed bythe IETF Public-Key Infrastructure(X.509) (pkix) working group

2.6.4 Non-repudiation services

The purpose of non-repudiation services is tocollect, maintain, make available and validateirrefutable evidence. They are based on





mechanisms providing evidence generated bynon-repudiation certificates using symmetric orasymmetric cryptographic techniques. A clearlydefined security policy for a particularapplication and its legal environment is a pre-requisite for a non-repudiation service. Non-repudiation certificates establish accountabilityof information about a particular event or actionto its originating entity. Non-repudiationmechanisms are specified to establish thefollowing:

! Non-repudiation of origin!

Non-repudiation of delivery! Non-repudiation of submission! Non-repudiation of transport.

The mechanisms typically consist of non-repudiation certificates, non-repudiation tokens,and protocols. Non-repudiation certificatesrequire a TTP as an evidence generatingauthority when symmetric cryptographic

algorithms are used. When asymmetriccryptographic algorithms are used, digitalsignatures of the data communicated are assuredby public key certificates issued by a certificationauthority. Non-repudiation tokens consist of oneor more non-repudiation certificates and,optionally, additional data. Non-repudiationtokens may be stored as evidence that may beused later on by disputing parties or by an

adjudicator to arbitrate disputes. Non-repudiationprotocols specify the exchange of non-repudiation tokens specific for each non-repudiation service.

Symmetric techniques rely on the existence of amutually trusted TTP. The ISO non-repudiation





standard describes two mechanisms, one of whichrequires that the TTP is on-line for the generationand verification of evidence. The othermechanism has distribution of keys before theevent for which evidence is required and so theTTP can be off-line.

Asymmetric techniques describe non-repudiationmechanisms using digital signatures. A TTP isrequired to support some of the mechanismsdescribed to perform evidence generation,evidence transmission, evidence recording andevidence verification. Non-repudiation of origin

and non-repudiation of delivery can be supportedwithout the direct involvement of a TTP. Theycan also be provided with the use of a TTP, asmust non-repudiation of submission and non-repudiation of transport. Mechanisms forsupporting services such as obtaining public-keycertificates and revocation information, as well astime stamping and evidence recording, arerequired.


! ISO/IEC 13888: Non-repudiation: (Part 1:General model; Part 2: Using symmetrictechniques; Part 3: Using asymmetrictechniques)

! ISO/IEC 10181:1996 Informationtechnology - Open Systems Interconnection -

Security frameworks for open systems. (Part4: Non-repudiation framework)

! IETF RFCs 1421-1424: Privacy Enhancement for Internet Electronic Mail

! The Secure HyperText Transfer Protocol ! SDN 701: Secure Data Network System:

Message Security Protocol (MSP)





! IDUP GSS-API: The Independent Data UnitProtection Generic Security Service Application Program Interface

! CORBA Security Services ! ISO 9735:1998 Electronic data interchange

for administration, commerce and transport (EDIFACT) -- Part 5: Security rules for batch EDI (authenticity, integrity and non-repudiation of origin)

2.6.5 Entity authentication

The purpose of entity authentication is tocorroborate that an entity is what it claims to be.

Entity authentication mechanisms are based onthe entity to be authenticated corroborating itsidentity by demonstrating its knowledge of asecret authentication key, which is used toencipher specific data. The enciphered data canbe deciphered and its contents validated byanyone sharing the entity's secret authenticationkey. The claimant and verifier need to share a

common secret authentication key, theestablishment of which may involve a TTP.Some of the mechanisms can be used to establishmutual authentication, where both entities areauthenticated; some can be used to authenticateone of the entities, unilateral authentication. Themechanisms specified can also be used in keydistribution.

Entity authentication mechanisms are generallybased upon public key algorithms including theuse of symmetric encipherment algorithms andcryptographic check functions and a digitalsignature for the verification of the identity of anentity. The algorithm used is any that satisfies therequirements of the specified authentication





mechanism.

The validity and authenticity of the public keyare therefore most important. How such a key issecurely obtained is outside the scope of this

process. The public key could be obtained byusing a certificate distributed by a TTP or bysome other means mutually agreed by the entityand the verifier. Authentication may be bothunilateral and mutual.

Entity authentication mechanisms are oftendesigned around 'zero knowledge' classes of mechanisms are:

! Identity based, where a trusted accreditationauthority provides secret accreditationinformation which is a function of theclaimant’s identity

! Certificate based, where a claimant has apublic, private key pair and the verifier atrusted copy of the claimant's public key --

this may be by using a certificate signed bya TTP).

The management of public key mechanisms isdiscussed in detail in the Key Infrastructure section of the Guide to Information Security.


! ISO/IEC 9798: Entity authentication (Part 1:General model; Part 2: Using symmetricencipherment algorithms; Part 3: Using apublic key algorithm; Part 4: Using acryptographic check function; Part 5: Usingzero knowledge techniques)

! ISO 9735: EDIFACT - Application level





syntax rules (Part 5: Security rules for batchEDI (authenticity, integrity and non-repudiation of origin); Part 6: Secureauthentication and acknowledgementmessage (message type - AUTACK))

! ISO/IEC 10181:1996: Informationtechnology -- Open Systems Interconnection-- Security frameworks for open systems.(Part 2: Authentication framework)

! FIPS PUB 196: Entity Authentication UsingPublic Key Cryptography

3. The Building Blocks of Trust

3.1 Overview

The building blocks of trust are technicalbuilding blocks which provide a common andinteroperable basis for the system of trust.

As already discussed, central to a system of trustis an acceptable level of security for a given task or activity. Therefore, many of the technicalbuilding blocks of trust are security related.These are examined in the Technical Elementssection of the Guide to Information Security.

Additional building blocks of trust include:

! APIs ! Smart Cards ! Labelling ! Privacy Practices.

3.2 APIs

APIs need to be available for a number of cryptographic service interfaces in support of trust services, including:





! Public key delivery and verificationinterface

! Certification Authority agent! Local registration authority! Publication of certificates and certificate

revocation lists.


! See also the Diffuse Standards and Specifications List section on ApplicationProgram Interfaces Standards and Guide to Application Program Interfaces.

! PKCS #11, defines a programming interfacecalled Cryptoki, for cryptographic devicessuch as smart cards and PCMCIA cards

! IETF PKIX working group APIspecifications

! GSS-API Generic Security Services Application Program Interface: Underlyingsecurity services for Internet datacommunications.

!

The Open Group Preliminary SpecificationP442 Generic Cryptographic Service API (GCS-API)

! CDSA Common Security Service Manager (CSSM) API, the CSSM Key Recovery API and CSSM Embedded Integrity Services Library API specifications

! IEEE P1003.1e POSIX Part 1: System API -Protection, Audit and Control Interfaces (C

language) ! The Microsoft Cryptographic API

3.3 Smart Cards

Standards are needed for trusted componentssuch as smart cards which are required to support





card related, secure commercial and financialtransactions and payments. This needs to coverthe use of all major currently available cardtechnologies (e.g. magnetic stripe cards,integrated circuit cards) and applications (e.g.debit-credit, electronic purse). In addition,standard protocols for communication between asmartcard, executing security functions, andapplications, including certificate management,are needed. Features which need to be addressedinclude:

! Application protocols, interface devices and

appropriate software requirements need tobe defined to ensure implementation of thefollowing functions and services in relationto customers, vendors and financialinstitutions

! Recognition and authentication of all parties(e.g. customer, vendor, etc.)

! Ordering (including but not limited to orderform, placement of order by the customer

and acceptance of the order by the vendor)! Agreement on the means of payment and

related authorization to pay by the customer! Payment authorization (requested by the

vendor to the financial institution)! Payment request and impact on settlement! The definition of a security architecture to

provide appropriate integrity, confidentialityand anonymity.

Smart cards are particularly well suited to hostsecurity keys. This allows portability and mobileusage and provides some advantages in terms of security -- for example, it may be more difficultto steal a card rather then break into a computer.For added security smart cards can also deploy





PIN techniques either through the reading deviceor, better, through an embedded key pad actuallyon the smart card itself.

Further information on smart card is provided is

provided in the Guide to Electronic Payment .


! CEPS -- Common Electronic PurseSpecifications. A comprehensive set of specifications for the implementation of aglobally interoperable electronic purseprogram, based on existing payment

infrastructures. The CEPS technicalspecifications need to be combined with thescheme implementer's own specifications tocreate the final CEP implementationspecifications.

! EEP - European Electronic Purse. A card-based electronic purse capable of handlingboth Euros and national currencies. Open

specifications are published by the EuropeanCommittee for Banking Standards (ECBS).! EMV. Integrated Circuit Card (ICC)

Specifications for Payments. Proprietaryspecification developed by Europay,Mastercard and Visa. It defines the terminaland integrated circuit card (ICC) proceduresnecessary to effect a payment systemtransaction in an international interchange

environment.! PKCS #11, defines a programming interface

called Cryptoki, for cryptographic devicessuch as smart cards and PCMCIA cards.

Relevant on-going activities





! The European Union has launched a majorinitiative eEurope Smart Card (eESC) towork towards an agreed technicalframework and codes of practice for theestablishment of common specifications forsmart cards.

! Industry fora, such as the Java Card Forum,are developing APIs for smart cards.

3.4 Labelling

The precise content of information which isexchanged between parties is often unknown inadvance. Thus, even if a recipient is assured of the source and the delivery through specific TTPmechanisms, the final content may be unwanted.Labelling is a means of describing what is in thecontent associated with the label without usershaving to open the container to examine thecontents. The key to a labelling system is thekind of data provided in the label and what thedata in the label actually says. Both are crucial

for identifying the content to the user and toenable the user to decide whether he wishes to goa step further: to open the container and accessthe content. In addition, rating and filtering, asspecific applications of labelling, are processeswhich would enhance the provisioning of trustservices.

See Guide to Labelling, Rating and Filtering for

further information.


! W3C PICS (Platform for Internet ContentSelection)





Relevant on-going activities

! The European Commission's Safer InternetAction Plan

! A website giving advice on how best to

communicate safety messages about theInternet to parents, teachers and children hasbeen set up as part of this initiative byChildnet International and Fleishman Hillard

3.5 Privacy Practices

Internet users are concerned about the privacy of information they supply to Web sites. This

includes personal information as well asinformation that Web sites may derive bytracking their online activities. Many onlineprivacy concerns arise because it is difficult forusers to obtain information about actual Web siteinformation practices. Web sites are beginning topost details of their privacy policies; when theyare posted users do not always find them

trustworthy or understandable. Thus, there isoften a one-way mirror effect: Web sites ask users to provide personal information, but usershave little knowledge about how theirinformation will be used. This lack of knowledgeleads to confusion and mistrust.

Technical mechanisms could enable users toexercise preferences over Web sites' privacy

practices, by enabling users to be informed aboutWeb site practices, delegate decisions to theircomputer agent when they wish, and tailorrelationships with specific sites. Thus, aframework for technical mechanisms whichensures that information relating to the user isreleased only under an acceptable agreement





(reached through "negotiations" between the useragent and the Website concerned) would enhancetrust: by giving the user choices and control overprivacy preferences.

See Guide to Internet Privacy for furtherinformation.

Standards and Specifications W3C Platform for Privacy Preferences(P3P1.0) Specification

4. Examples of Trust Services

The follow are examples of trust services that areavailable today. It should be noted that they havedivergent codes of practice and provide differentfeatures and service levels. The user populationsof these services also vary considerably. Somealso levy a fee. Many have a national flavour.

! AOL Certified Merchant Program.International initiative managed by AOL

Time Warner.! BBBonline. Privacy and reliability related

initiatives managed by organization of thesame name and have a significant user baseworldwide.

! BetterWeb. Global programme managed byPriceWaterhouseCoopers.

! casetrust. Joint project of Consumer

Association, CommerceNet chapter andRetail Promotion Centre of Singapore.! Cpa webtrust. US/Canadian initiative

managed by accountants and expanding inEurope.

! e-comtrust. European initiative supported byseveral national and international IT, direct





marketing and consumer organizations.! JADMA (Japan DMA). Japanese initiative

managed by direct marketing and retailorassociations.

! Labelsite. French initiative managed by twobusiness associations.

! MedCIRCLE. A collaboration of trustedEuropean health subject gateways, medicalassociations, as well as accreditation,certification and rating services, with thecommon goal to evaluate, describe, orannotate health information and supportedunder the EU IAP programme. It is a follow-

up to the previous IAP projectMedCERTAIN which has developed theHIDDEL metadata vocabulary to describeand evaluate health information on theInternet.

! Qweb. Italian initiative to certify the qualityof Web sites implemented by CISQFederation (a member of the InternationalCertification Network IQNet) with the

collaboration of Certicommerce (whichrepresents the Italian certification systemsponsored by the Chambers of Commerce).

! Safemall. Korean initiative.! Spanish Guarantee Seal. Spanish initiative

managed by an Electronic CommerceBusiness Association.

! TRUSTe. One of the longest-establishedprivacy initiatives originally initiated byCommerceNet and has a significant userbase worldwide.

! Trusted Shops. German initiative (subsidiaryof Gerling Insurance Group) with aEuropean outreach.

! TrustUK. UK initiative supported by





government and managed by an e-commercebusiness alliance and consumer body.

! Webtrader. A network of trust schemes forenterprises selling to consumers over theInternet, with pilot operations supported bythe European Commission DG Enterprise.

The European Commission has established aneConfidence Forum to investigate measures forincreasing consumer confidence in servicesoffered over the Internet. Among thedocumentation made available by the Forum is asurvey regarding codes of conduct and trust seals

published by the European Commission JointResearch Centre in November 2001.

In the standards arena, CEN/ISSS established aWorkshop on Legal Compliance and Trust for e-Business (WS/e-Trust) in November 2001. Thepurpose of this workshop is to develop a set of pan-European, uniform guidelines definingminimum requirements to be observed by those

making available web sites offering e-commerce,easily understandable by the parties andimmediately usable by e-commerce merchantsand web-designers. The ISO Committee onConsumer Policy (COPOLCO) is developing acase for developing international standards in thetrust area.

File last updated:

December 2002

The Diffuse Project is funded under the European

Commission's Information Society Technologies programme. Diffuse publications are maintained byTIEKE (the Finnish IT Development Centre), IC

Focus and The SGML Centre.


diffuse - guide to trust services and building blocks of trust - ttp

Documents