Re: the intersection between Swagger-style APIs and SSI/decentralized identity

It is true that the DID/VC channel is less susceptible to certain
vulnerabilities, and I think the out-of-band locus is an interesting
insight. However, I think we shouldn't feel overly comfortable yet about
any channel. We did an analysis of potential vulnerabilities in credential
workflows, and we found plenty to ponder. Not all of them are equally
likely, or equally damaging if exploited, but they do exist.

Work on this topic has happened at the last two IIW conferences, as well as
at the RWOT in Prague in August. The most formal published artifacts on the
topic are this paper about VC abuse
<https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/final-documents/alice-attempts-abuse-verifiable-credential.md>,
and this Aries RFC about the VC threat model
<https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0207-credential-fraud-threat-model/README.md>
.

On Fri, Jan 3, 2020 at 9:26 AM <steve.e.magennis@gmail.com> wrote:

> …Forgive the pontification and slight nudge to the flow of the thread, but
> this is a great topic!
>
>
>
> I think the DID/VC trust chain may be a lot less vulnerable.  Within the
> DID/VC trust chain, the potential Holder/Subject can rely on the integrity
> of the credential payload and transmission. The only real vulnerability
> would be if the potential Holder/Subject gets spoofed into registering with
> a party other than the one expected. This could be a problem if we’re
> talking about one-time transactions, or an orchestrated long-con. In cases
> though where there is some durability to a relationship, it would become
> obvious pretty quickly if either party registered with the wrong digital
> entity.
>
>
>
> On the other hand, there are *out-of-band*, *but deeply connected*
> *issues* that should be explored to ensure the end-to-end value-prop and
> viability of the design. I’m actually really encouraged because while
> DID/VC’s don’t solve all of the end-to-end trust issues, they solve some
> really big ones and allocate much of the remaining risk to areas that are
> fairly easily managed at scale or at least can be managed acceptably using
> social constructs (i.e. reputation).
>
>
>
> Consider, there are few cases that come to mind in which a potential
> Holder/Subject would accept an unsolicited or un-requested credential
> (receiving a spam credential is one that comes to mind).
>
> The implication of this are twofold:
>
>    1. An potential Holder/Subject would need to know and/or trust the
>    reputation of the Issuer in real life before accepting the credential.
>    Unless digital reputation systems become available and, well, reputable, *this
>    trust predicate can only happen out of band*. E.g.:
>       1. 'I've worked with this organization for years and find them to
>       be honest,'
>       2. 'I've known this person since childhood and they have a
>       reputation of integrity,'
>       3. 'Everybody I know uses the BigBank credit card,'
>       4. 'The system was designed to receive sensor data from device
>       foo.'
>       5. Even a potential Holder/Subject who is maybe less than honest
>       would still need to anticipate the reputation of issuer. E.g.: 'I expect
>       the on-line credential mill to issue me a legit-looking credential, not
>       something that will get me fired.'
>    2. A potential Verifier receiving a credential would similarly need to
>    know and/or trust the reputation of the Issuer in real life and accordingly
>    weigh the value of the credential they received based on that. Since DID/VC
>    ensures the chain of integrity from Issuer to Verifier, the *vulnerability
>    largely remains out-of-band*.
>
> This is not to say the vulnerability isn’t real for real-world
> interactions, but it points, I believe, less towards the DID/VC ecosystem
> and more towards how as humans, we take on the grey and very squishy task
> of weighing risk and evaluating integrity.
>
>
>
> -S
>
>
>
> -----Original Message-----
>
> From: David Chadwick <D.W.Chadwick@kent.ac.uk>
>
> Sent: Friday, January 3, 2020 6:12 AM
>
> To: public-credentials@w3.org
>
> Subject: Re: the intersection between Swagger-style APIs and
> SSI/decentralized identity
>
>
>
> Absolutely correct. In fact the way the holder/subject registers with the
> Issuer is of critical importance, and is potentially the most important
> (and potentially vulnerable) link in the trust chain.
>
>
>
> On 03/01/2020 13:29, John, Anil wrote:
>
> > I is also important to note that "Before an Issuer decides to issue a
> credential to a Holder, the manner in which it may decide to first act as a
> Verifier in order to verify some credentials that the Holder presents to
> it" may not necessarily be using a DID/VC flow -- i.e. the Issuer may have
> existing validation and verification  processes it may leverage to ensure
> that the Holder/Subject (am assuming that in this case they are the same)
> is indeed the proper beneficiary of the benefits/entitlements that the
> Issuer is authoritative for.
>
> >
>
> > Best Regards,
>
> >
>
> > Anil
>
> >
>
> > -----Original Message-----
>
> > From: David Chadwick <D.W.Chadwick@kent.ac.uk>
>
> > Sent: Friday, January 3, 2020 5:33 AM
>
> > To: public-credentials@w3.org
>
> > Subject: Re: the intersection between Swagger-style APIs and
>
> > SSI/decentralized identity
>
> >
>
> > It is important to note that the terms Issuer, Holder and Verifier are
> ROLES, not entities. An entity can play any of the three roles at any time.
>
> >
>
> > So it is quite proper to say
>
> >
>
> > "Before an Issuer decides to issue a credential to a Holder, it may
> decide to first act as a Verifier in order to verify some credentials that
> the Holder presents to it. It may also act as a Holder to present some of
> the credential that it holds."
>
> >
>
> > Kind regards
>
> > David
>
> >
>
> > On 02/01/2020 18:22, Deventer, M.O. (Oskar) van wrote:
>
> >> Hi Steven,
>
> >>
>
> >>>> As you see, I am using the terms issue, hold and verify only as nouns.
>
> >>> Did you mean 'verbs' rather than 'nouns'?
>
> >> Oops, of course. I am urging all to be careful with terminology, and
> then I make such a sloppy error ;-)   I meant to say the following:
>
> >>
>
> >> Here is an example of a sentence in this style:
>
> >> "Before a Party decides to issue a credential to another Party, or to
> present a credential that it holds, it may decide to verify some
> credentials of that other Party first."
>
> >> As you see, I am using the terms issue, hold and verify only as verbs.
>
> >> (Hence avoiding the nouns Issuers, Holder and Verifier.)
>
> >>
>
> >> Oskar
>
> >>
>
> >> -----Original Message-----
>
> >> From: Steven Rowat <steven_rowat@sunshine.net>
>
> >> Sent: 02 January 2020 17:47
>
> >> To: Deventer, M.O. (Oskar) van <oskar.vandeventer@tno.nl>
>
> >> Cc: W3C-CCG <public-credentials@w3.org>
>
> >> Subject: Re: the intersection between Swagger-style APIs and
>
> >> SSI/decentralized identity
>
> >>
>
> >> On 2020-01-02 12:31 am, Deventer, M.O. (Oskar) van wrote:
>
> >>> Hi Daniel,
>
> >>>
>
> >>> Thank you.
>
> >>>
>
> >>> Please note that we need to be more careful with our terminology. A
>
> >>> "Holder" does not verify an "Issuer" or "Verifier". I suggest that,
>
> >>> where usefull, we use the generic term "Party" that can switch
>
> >>> between these roles.
>
> >>>
>
> >>> Here is an example of a sentence in this style:
>
> >>> "Before a Party decides to issue a credential to another Party, or
>
> >>> to present a credential that it holds, it may decide to verify some
>
> >>> credentials of that other Party first."
>
> >>>
>
> >>> As you see, I am using the terms issue, hold and verify only as nouns.
>
> >> Did you mean 'verbs' rather than 'nouns'?
>
> >>
>
> >> Steven Rowat
>
> >>
>
> >>> Oskar
>
> >>>
>
> >>>
>
> >>> -------- Original message --------
>
> >>> From: Daniel Hardman <daniel.hardman@evernym.com>
>
> >>> Date: 31/12/2019 20:42 (GMT+01:00)
>
> >>> To: "Deventer, M.O. (Oskar) van" <oskar.vandeventer@tno.nl>
>
> >>> Cc: W3C-CCG <public-credentials@w3.org>
>
> >>> Subject: Re: the intersection between Swagger-style APIs and
>
> >>> SSI/decentralized identity
>
> >>>
>
> >>> Oskar: thank you for that diagram. Very insightful. I agree that the
>
> >>> party that's acting as an issuer or verifier needs to be able to
>
> >>> organically switch roles. In the middle of issuing, the potential
>
> >>> holder needs to be able to challenge the potential issuer to prove
>
> >>> its bona fides; in the middle of proving, the holder needs to be
>
> >>> able to challenge the verifier to prove its bona fides. Your diagram
>
> >>> is spot on. This is an excellent example of why APIs that
>
> >>> contemplate a single workflow where initiation only happens on one
>
> >>> side, and all flows are hosted on one side, are too simplistic.
>
> >>>
>
> >>> (This composability phenomenon is why the Aries community has begun
>
> >>> talking about subprotocol and coprotocols
>
> >>> <
> https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0003-protocols#composable
> >.
>
> >>> I think the ideas there are very early and would profit from
>
> >>> additional use cases like Oskar's.)
>
> >>>
>
> >>> On Tue, Dec 31, 2019 at 11:24 AM Deventer, M.O. (Oskar) van
>
> >>> <oskar.vandeventer@tno.nl <mailto:oskar.vandeventer@tno.nl>> wrote:
>
> >>>
>
> >>>       Hi Daniel,____
>
> >>>
>
> >>>       __ __
>
> >>>
>
> >>>       Your analysis makes a lot of sense to me, and deserves discussion
>
> >>>       at more length. ____
>
> >>>
>
> >>>       __ __
>
> >>>
>
> >>>       At TNO, we have noted an asymmetry in most of the SSI use cases
>
> >>>       presented in papers and at conferences, where the Issuer and
>
> >>>       Verifier roles are typically big organisations with servers,
>
> >>>       whereas the Holder role is typically an individual (citizens,
>
> >>>       consumer, patient, employee, student). This asymmetry is one of
>
> >>>       the major reasons of much online fraud today. The individual
>
> >>>       simply does not have the means to say “hey website, proof to me
>
> >>>       that you indeed do have a Dutch bank license” (individual in the
>
> >>>       Verifier role), or “that one is a good seller” (individual in the
>
> >>>       Issuer role, web-of-trust case). So it will be good to work on
>
> >>>       technical solutions, where symmetry and PKI-lessness is achieved
>
> >>>       at least at the protocol level. But it may be equally useful to
>
> >>>       work out more use cases where an individual is in the Verifier or
>
> >>>       Issuer role in interactions with a big organisations or another
>
> >>>       individual.____
>
> >>>
>
> >>>       __ __
>
> >>>
>
> >>>       The figure below illustrates a use case that shows symmetry
>
> >>>       between Consumer “C” and a Travel site “T”. Both parties
>
> >>>       intermittently act as Issuer, Holder and Verifier in a single
>
> >>>       transaction exchange. We should have more of such use cases, in
>
> >>>       order to create the so-needed awareness and sense of urgency with
>
> >>>       W3C-CCG and elsewhere.____
>
> >>>
>
> >>>       __ __
>
> >>>
>
> >>>       ____
>
> >>>
>
> >>>       One of the targets of the European H2020 NGI eSSIF-Lab project
> (of
>
> >>>       which I am the scientific coordinator) is the
> creation/integration
>
> >>>       of open-source wallet software that supports this symmetry and
>
> >>>       that has the required Issuer and Verifier functionalities. We are
>
> >>>       planning to offer a bounty of up to 50 kEUR to (European) parties
>
> >>>       that will build such functionality. Symmetry and PKI-less
>
> >>>       operation of the transport protocols (plural, including
> Bluetooth,
>
> >>>       …) may be an important element in this.____
>
> >>>
>
> >>>       __ __
>
> >>>
>
> >>>       Oskar____
>
> >>>
>
> >>>       __ __
>
> >>>
>
> >>>       __ __
>
> >>>
>
> >>>       From: Daniel Hardman <daniel.hardman@evernym.com
>
> >>>       <mailto:daniel.hardman@evernym.com
> ?Subject=Re%3A%20the%20intersection%20between%20Swagger-style%20APIs%20and%20SSI%2Fdecentralized%20identity&In-Reply-To=%3CCAFBYrUorm5UF8CjRqkFMJ4W3HuBAH-f5V95M6%3D8xbzyDPg-YNg%
> 40mail.gmail.com
> %3E&References=%3CCAFBYrUorm5UF8CjRqkFMJ4W3HuBAH-f5V95M6%3D8xbzyDPg-YNg%
> 40mail.gmail.com%3E>>
>
> >>>       Date: Mon, 30 Dec 2019 12:54:38 -0700
>
> >>>       Message-ID:
>
> >>>
>
> >>> <CAFBYrUorm5UF8CjRqkFMJ4W3HuBAH-f5V95M6=8xbzyDPg-YNg@mail.gmail.com
>
> >>> <mailto:8xbzyDPg-YNg@mail.gmail.com>>
>
> >>>
>
> >>>       Cc: W3C Credentials CG <public-credentials@w3.org
>
> >>>       <mailto:public-credentials@w3.org
> ?Subject=Re%3A%20the%20intersection%20between%20Swagger-style%20APIs%20and%20SSI%2Fdecentralized%20identity&In-Reply-To=%3CCAFBYrUorm5UF8CjRqkFMJ4W3HuBAH-f5V95M6%3D8xbzyDPg-YNg%
> 40mail.gmail.com
> %3E&References=%3CCAFBYrUorm5UF8CjRqkFMJ4W3HuBAH-f5V95M6%3D8xbzyDPg-YNg%
> 40mail.gmail.com%3E>>,
>
> >>>       Markus Sabadello <markus@danubetech.com
>
> >>>       <mailto:markus@danubetech.com
> ?Subject=Re%3A%20the%20intersection%20between%20Swagger-style%20APIs%20and%20SSI%2Fdecentralized%20identity&In-Reply-To=%3CCAFBYrUorm5UF8CjRqkFMJ4W3HuBAH-f5V95M6%3D8xbzyDPg-YNg%
> 40mail.gmail.com
> %3E&References=%3CCAFBYrUorm5UF8CjRqkFMJ4W3HuBAH-f5V95M6%3D8xbzyDPg-YNg%
> 40mail.gmail.com%3E>>,
>
> >>>       Justin P Richer <jricher@mit.edu
>
> >>>
>
> >>> <mailto:jricher@mit.edu?Subject=Re%3A%20the%20intersection%20between
>
> >>> %
>
> >>> 2
>
> >>> 0Swagger-style%20APIs%20and%20SSI%2Fdecentralized%20identity&In-Repl
>
> >>> y
>
> >>> -
>
> >>> To=%3CCAFBYrUorm5UF8CjRqkFMJ4W3HuBAH-f5V95M6%3D8xbzyDPg-YNg%40mail.g
>
> >>> m
>
> >>> a
>
> >>> il.com%3E&References=%3CCAFBYrUorm5UF8CjRqkFMJ4W3HuBAH-f5V95M6%3D8xb
>
> >>> z
>
> >>> y
>
> >>> DPg-YNg%40mail.gmail.com%3E>>____
>
> >>>
>
> >>>       __ __
>
> >>>
>
> >>>       Markus has recently proposed a work item for the CCG to develop
>
> >>>       Swagger-style APIs for issuers and verifiers. Justin has recently
>
> >>>       proposed a charter for a TxAuth group to start working on
>
> >>>       HTTP-based APIs to accomplish delegation. Digital Bazaar has
>
> >>>       advocated their RESTful Credential Handler API (CHAPI) in CCG and
>
> >>>       other circles as well. No doubt many others on this thread are
>
> >>>       aware of efforts to standardize APIs with similar style and
>
> >>>       similar intersection to the SSI/decentralized identity
>
> >>> space.____
>
> >>>
>
> >>>       __ __
>
> >>>
>
> >>>       I would like to raise a red flag about such efforts, and trigger
> a
>
> >>>       thoughtful follow-up conversation. I love Swagger-style APIs and
>
> >>>       have advocated them extensively at past junctures of my career,
>
> >>>       but I am concerned that they are exactly the wrong thing to
>
> >>>       standardize right now. I'll explain my concerns below, in red,
> and
>
> >>>       then offer an alternative path that has most of the same
> benefits,
>
> >>>       in blue.____
>
> >>>
>
> >>>       __ __
>
> >>>
>
> >>>       1. RESTful APIs are web-only.____
>
> >>>
>
> >>>       __ __
>
> >>>
>
> >>>       How do two farmers with cheap android devices in the highlands of
>
> >>>       Bolivia (or a Canadian Mounty and a speeder on a lonely highway
> in
>
> >>>       Yukon Territory, or friends in Frankfurt whose cell service has a
>
> >>>       brownlout, or two anti-government protesters) use RESTful APIs to
>
> >>>       transact business? If the answer is, "they subscribe to a service
>
> >>>       in the cloud so they can talk device-to-device," I hope we are
>
> >>>       embarrassed. We need something that also works over BlueTooth and
>
> >>>       email and other transports where a web server isn't a
>
> >>> component.____
>
> >>>
>
> >>>       __ __
>
> >>>
>
> >>>       By standardizing a solution that doesn't think about these
>
> >>>       scenarios, we are further marginalizing them, and we are
>
> >>>       enthroning a
>
> >>>       /you-must-be-connected-and-you-can-be-surveilled/ model that
>
> >>>       guarantees /it-isnt-a-standard/ FUD for any other efforts to fix
>
> >>>       the problem.____
>
> >>>
>
> >>>       __ __
>
> >>>
>
> >>>       2. RESTful APIs perpetuate the PKI model that we claim to be
>
> >>>       replacing with DIDs.____
>
> >>>
>
> >>>       __ __
>
> >>>
>
> >>>       Servers are authenticated in these APIs with a cert. Clients are
>
> >>>       authenticated with a session that follows from an OAuth token or
>
> >>>       an API key or basic auth material. It is possible to imagine "DID
>
> >>>       Auth" being used for a client of a RESTful API, and there have
>
> >>>       been several efforts to describe and standardize such a thing. So
>
> >>>       far, none has meaningful traction, so all APIs in the SSI space
>
> >>>       that use APIs are also allowing non-DID authentication for
>
> >>>       clients. But even if we solve the problem for the client side,
>
> >>>       nobody is proposing to solve the problem for the server side.
>
> >>>       Institutions in these APIs don't use DIDs for anything
> meaningful.
>
> >>>       Thus none of the decentralized properties of DIDs are brought to
>
> >>>       bear for the server side of the interaction, and any
> decentralized
>
> >>>       qualities of DIDs are relegated to minor, optional status for
>
> >>>       clients.____
>
> >>>
>
> >>>
>
> >>>       3. RESTful APIs foster a power imbalance____
>
> >>>
>
> >>>       __ __
>
> >>>
>
> >>>       What if there's a standard way for institutions to be a verifier
>
> >>>       or issuer, but no way for ordinary people to be a verifier or
>
> >>>       issuer? Or a standard way for institutions to delegate, but no
> way
>
> >>>       for ordinary people to do it? That's effectively what APIs like
>
> >>>       the ones I mentioned above guarantee. There are multiple reasons
>
> >>>       why, including:____
>
> >>>
>
> >>>       __·__Institutions have web servers; farmers in Bolivia don't.
>
> >>>       (Saying that they *could* is not helpful; we're just creating
> more
>
> >>>       adoption burden for SSI by making the tech harder and more
>
> >>>       expensive for them.)____
>
> >>>
>
> >>>       __·__Servers can't make the first move in RESTful APIs;
> everything
>
> >>>       begins when a client initiates the interaction. This makes it
>
> >>>       natural for an institution (or a regulatory regime) to impose
>
> >>>       terms of service or reputation criteria on a client, and
> unnatural
>
> >>>       for a client to do the opposite. It's also convenient for hackers
>
> >>>       and surveillers, since they know they can catch all interactions
>
> >>>       at inception by simply listening on the server.____
>
> >>>
>
> >>>       __·__Because these APIs are online-only, and because the server
>
> >>>       always waits for the client to make the first move, they can only
>
> >>>       be operated by those who have a 24x7x365 cloud presence.
>
> >>>       Institutions and ordinary people don't have equal access to
>
> >>>       24x7x365 cloud capabilities.____
>
> >>>
>
> >>>       __·__Because these APIs are secured on the server side by a cert,
>
> >>>       they can only be operated by those who have access to expensive,
>
> >>>       premium, centralized reputation. Again, institutions and people
>
> >>>       don't have equal access to this.____
>
> >>>
>
> >>>       This is not an exhaustive list of my concerns, but I think it's
>
> >>>       enough to trigger a conversation.
>
> >>>
>
> >>>       Proposed Alternative____
>
> >>>
>
> >>>       __ __
>
> >>>
>
> >>>       We create web APIs, but we think about them differently. We
>
> >>>       conceive of all of them as exchanges of messages that could also
>
> >>>       be accomplished over BlueTooth, email, etc. HTTP(S) is just
>
> >>>       another transport, where messages happen to be passed by HTTP
> POST
>
> >>>       (or GET, as appropriate). Security properties associated with the
>
> >>>       exchange are based on the control of DIDs and embodied in the
>
> >>>       messages themselves (e.g., through encryption/signing), not in a
>
> >>>       transport layer. All semantics for the interaction are conveyed
> by
>
> >>>       the message content. The traditional URL namespacing of Swagger
>
> >>>       can still exist, but it becomes less interesting, since the
>
> >>>       message content must be enough to convey semantics on its own (so
>
> >>>       the messages are enough in other transports). Either party can
>
> >>>       initiate an interaction. Institutions and people are actually
>
> >>>       peers.____
>
> >>>
>
> >>>       __ __
>
> >>>
>
> >>>       This is the world of didcomm and application-level protocols
> built
>
> >>>       atop it; it's described in Aries RFC 0003
>
> >>>       <
> https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0003-protocols/README.md
> >.
>
> >>>       But before folks get their hackles up about not wanting to work
>
> >>>       with Aries or DIF, note that I didn't propose that Aries
> protocols
>
> >>>       have to be the basis for this approach. Instead, I proposed some
>
> >>>       characteristics we need to avoid. Can we explore that assertion
> on
>
> >>>       its merits, without getting immediately entangled in
>
> >>> politics?____
>
> >>>
>
> >>>       __ __
>
> >>>
>
> >>>       There are already maybe 8-10 software stacks, some independent
>
> >>>       from top to bottom, that implement an "API" for issuing
>
> >>>       credentials and an "API" for verifying presentations based on the
>
> >>>       model I just articulated. These implementations are demonstrably
>
> >>>       interoperable with one another. By proposing a new work item for
> a
>
> >>>       Swagger API for issuance and verification, we are walking away
>
> >>>       from interoperability with these implementations, and we are
>
> >>>       incurring all of the architectural disadvantages I highlighted in
>
> >>>       red above.____
>
> >>>
>
> >>>       __ __
>
> >>>
>
> >>>       What if we did this instead?____
>
> >>>
>
> >>>       __·__Agree that for issuance and verification, the goal about
>
> >>>       payloads and sequencing for HTTP calls should be alignment
> between
>
> >>>       those defined in the Aries protocol and those used by people who
>
> >>>       aren't Aries-centric. This could involve give and take in either
>
> >>>       direction; I'm not proposing that it has to be done by simply
>
> >>>       adopting the Aries work.____
>
> >>>
>
> >>>       __·__Agree not to depend on HTTP-specific constructs (e.g., HTTP
>
> >>>       headers, HTTP status codes) to signal important semantics--so the
>
> >>>       payloads could be exchanged over BlueTooth or email just as
>
> >>>       easily.____
>
> >>>
>
> >>>       __·__Agree that, while URL namespacing gives us a nice hook into
>
> >>>       Swagger-oriented tools, all semantics required for the
> interaction
>
> >>>       are detectable from the payloads themselves.____
>
> >>>
>
> >>>       Then we'd have an HTTP solution that is Swagger-compatible but
> not
>
> >>>       limited to HTTP. The "API" we created would be interoperable on a
>
> >>>       much broader canvas than simple web.____
>
> >>>
>
> >>>       __ __
>
> >>>
>
> >>>       If we further agreed to this:____
>
> >>>
>
> >>>       __·__Authentication of both parties in the interaction will be
>
> >>>       done on the basis of DID control, not on the basis of
>
> >>> certs.____
>
> >>>
>
> >>>       Then we'd also eliminate the dependence on the web's flawed PKI
>
> >>>       model, and the power imbalance of today's web. But I know this is
>
> >>>       more controversial.____
>
> >>>
>
> >>>       _._,_._,_____
>
> >>>
>
> >>>       __ __
>
> >>>
>
> >>>       __ __
>
> >>>
>
> >>>       This message may contain information that is not intended for
> you.
>
> >>>       If you are not the addressee or if this message was sent to you
> by
>
> >>>       mistake, you are requested to inform the sender and delete the
>
> >>>       message. TNO accepts no liability for the content of this e-mail,
>
> >>>       for the manner in which you use it and for damage of any kind
>
> >>>       resulting from the risks inherent to the electronic transmission
>
> >>>       of messages.
>
> >>>
>
>
>