<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>You don't need that information to build out a UI though -- just
revoke all tokens associated with a given user and client
combination, and also the approved site (which is a stored grant).
Everything should cascade fine if you do:</p>
<p> - All approved sites</p>
<p> - All refresh tokens</p>
<p> - All remaining access tokens (this includes ID tokens in
versions earlier than 1.3)</p>
<p>All the API calls and service layer hooks are already there for
this action. The UI can easily hide the fact that it's doing these
multiple operations and give the user a button.<br>
</p>
<p> -- Justin<br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 3/23/2017 1:11 PM, Dominik Schmich
wrote:<br>
</div>
<blockquote
cite="mid:BC07D7EA39C6184BA034EA776CB2C46D0141B0C0@UCDEDC1PWXMR007.de.db.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="generator" content="HTML Tidy for Windows (vers 25
March 2009), see www.w3.org">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style type="text/css">
<!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Arial Unicode MS";
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"\@Arial Unicode MS";
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
color:black;
mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman",serif;
color:black;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
color:black;
mso-fareast-language:EN-US;}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.pl-en
{mso-style-name:pl-en;}
span.pl-k
{mso-style-name:pl-k;}
span.EmailStyle22
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:208688555;
mso-list-type:hybrid;
mso-list-template-ids:1047038734 810311466 67567619 67567621 67567617 67567619 67567621 67567617 67567619 67567621;}
@list l0:level1
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:-;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-font-family:Calibri;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
-->
</style>
<title></title>
Good, glad we agree, just wanted to make sure ;)<br>
<br>
The problem are the grants. As far as understood it so far, the
grants are the approved sites, correct?<br>
<br>
Now if you use a refresh token to get a new access token, this new
access token is not linked to the approved site, it is only linked
to the refresh token. This means I can't figure out which access
token is linked to which approved site aka approved Grant and
remove it.<br>
<br>
-- Dominik<br>
<br>
-----Original Message-----<br>
<b>From: </b>Justin Richer [<a moz-do-not-send="true"
href="mailto:jricher@mit.edu">jricher@mit.edu</a>]<br>
<b>Sent: </b>Monday, March 20, 2017 01:26 PM W. Europe Standard
Time<br>
<b>To: </b>Dominik Schmich; mitreid-connect<br>
<b>Subject: </b>Re: [mitreid-connect] Revoke Consent keeps Refresh
Tokens [I]<br>
<br>
<p>Right, that's exactly what I'm saying -- present the user with
the right model through the UI, allowing them to clear tokens
and grants in one go instead of (or in addition to) separating
them.</p>
<p> -- Justin<br>
</p>
<br>
<div class="moz-cite-prefix">On 3/18/2017 2:56 PM, Dominik Schmich
wrote:<br>
</div>
<blockquote
cite="mid:BC07D7EA39C6184BA034EA776CB2C46D01417D98@UCDEDC1PWXMR007.de.db.com"
type="cite">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p><span style="font-size:10.0pt;font-family:"Arial
Unicode MS",sans-serif">Classification:
<b>For internal use only</b></span></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-US">The
thing with the UI is, we don’t use it for the end users,
which provide the consent. We think it is too much
information for them and they would be confused. We
created an own page, similar to the “grant access page”,
just showing the already granted applications and their
scopes. This is the level we think the end user can
handle.</span></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-US"> </span></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-US">On
the other side, for developers using mitre, the current
webpages are good to see a more detailed view on what’s
going on, how many tokens are active, etc.</span></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-US"> </span></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-US">Coming
back to the original behavioral thoughts. I would as
EndUser expect, if I revoke the access for an application,
it is immediately revoked for all its instances. Therefore
I would be confused, if there would still an application
being able to access my data/functionality through those
“disconnected refresh tokens”. On top of this, if the
OAuth2 Server Provider decides to not let the Refresh
Tokens time out, those would never be deleted and the
applications has access without the user being able to
stop it.</span></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-US"> </span></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-US">If
it fits into the thoughts behind the Approved Sites or not
I can’t tell. But what I think we need is the connection
between the EndUser and the Application which is the
consent. As long as the consent is valid, any token can
still be used. As soon as the consent is removed, all the
tokens need to be removed as well. This more or less
results into the connection of any token to the consent,
right?</span></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-US"> </span></p>
<div>
<p class="MsoNormal" style="text-autospace:none"><span
style="font-size:10.0pt;font-family:"Arial",sans-serif;mso-fareast-language:DE">Beste
Grüße / Kind regards,<br>
Dominik Schmich<br>
<br>
</span><span
style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#CCCCCC;mso-fareast-language:DE">____________________________________________________</span><span
style="font-size:12.0pt;font-family:"Arial",sans-serif;color:#666666;mso-fareast-language:DE"><br>
<br>
</span><span style="color:#1F497D;mso-fareast-language:DE"><img
id="Picture_x0020_3"
src="cid:part2.8114A397.3D4E375A@mit.edu"
alt="imap://jricher@imap.exchange.mit.edu:993/fetch%3EUID%3E/Projects/MITREid%3E1960?header=quotebody&part=1.2&filename=image001.png"
height="46" width="46"></span><span
style="font-size:12.0pt;font-family:"Arial",sans-serif;color:#666666;mso-fareast-language:DE"><br>
<br>
</span><span
style="font-size:10.5pt;font-family:"Arial",sans-serif;mso-fareast-language:DE">Dominik
Schmich</span><span
style="font-size:12.0pt;font-family:"Arial",sans-serif;color:#666666;mso-fareast-language:DE"><br>
</span><span
style="font-size:8.5pt;font-family:"Arial",sans-serif;mso-fareast-language:DE">Assistant
Vice President | Solution Architect<br>
<br>
Deutsche Bank AG<br>
COO PW&CC Technology, Strategy & Architecture</span></p>
<p class="MsoNormal" style="text-autospace:none"><span
style="font-size:8.5pt;font-family:"Arial",sans-serif;mso-fareast-language:DE"
lang="EN-US">Alfred-Herrhausen-Allee 16-24, 65760
Eschborn, Germany</span></p>
<p class="MsoNormal"><span
style="font-size:8.5pt;font-family:"Arial",sans-serif;mso-fareast-language:DE"
lang="EN-US">Tel. +49 69 910-60543<br>
Mobile +49 1723700665<br>
Email <a moz-do-not-send="true"
href="mailto:dominik.schmich@db.com"><span
style="font-family:"Times New
Roman",serif;color:#0018A8;text-decoration:none">dominik.schmich@db.com</span></a></span></p>
<p class="MsoNormal"><span
style="color:#1F497D;mso-fareast-language:DE"
lang="EN-US"> </span></p>
<p class="MsoNormal"><a moz-do-not-send="true"
href="https://api-open.db.com/"><span
style="font-family:"Times New
Roman",serif;color:#1F497D;mso-fareast-language:DE;text-decoration:none"><img
id="Picture_x0020_2"
src="cid:part4.D96C23B1.AC53EE04@mit.edu"
alt="imap://jricher@imap.exchange.mit.edu:993/fetch%3EUID%3E/Projects/MITREid%3E1960?header=quotebody&part=1.3&filename=image002.png"
height="121" border="0" width="372"></span></a></p>
</div>
<p class="MsoNormal"><span style="color:#1F497D"> </span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><a moz-do-not-send="true"
name="_____replyseparator"></a><b><span
style="color:windowtext;mso-fareast-language:DE"
lang="EN-US">From:</span></b>
<span style="color:windowtext;mso-fareast-language:DE"
lang="EN-US">Justin Richer [<a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="mailto:jricher@mit.edu">mailto:jricher@mit.edu</a>]<br>
<b>Sent:</b> Montag, 13. März 2017 19:03<br>
<b>To:</b> Dominik Schmich <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:dominik.schmich@db.com">
<dominik.schmich@db.com></a>; mitreid-connect
<a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:mitreid-connect@mit.edu">
<mitreid-connect@mit.edu></a><br>
<b>Subject:</b> Re: [mitreid-connect] Revoke Consent
keeps Refresh Tokens [I]</span></p>
</div>
</div>
<p class="MsoNormal"> </p>
<p>I think this is a mismatch between the mental model you
have when looking at the software, and the mental model that
drove the (current) data structure. When we built this
originally, the "approved site" item was attached to tokens
as they were created, whether they were approved by a user
or whitelisted. This morphed into something that was more
like a "remembered grant", where the user's explicit
authorization decision was remembered and that was attached
to the token.</p>
<p>I'm not saying that your interpretation is incorrect, mind
you -- and in fact I think that it's a potentially clearer
model. However, I think that we should perhaps address this
in the UI instead of the data model. So instead of having
separate pages for tokens and grants, as we have today,
perhaps a single page for revoking a client's access in both
ways. This would more cleanly take care of the
non-remembered but permanent refresh tokens and put them at
the same level as the remembered grants.</p>
<p>Personally, I think this would be a cleaner way of handling
the disconnect than propagating the ApprovedSite link
through to the refresh token (and downstream), but I'm open
to other suggestions.</p>
<p> -- Justin</p>
<div>
<p class="MsoNormal">On 3/10/2017 3:01 AM, Dominik Schmich
wrote:</p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p><span style="font-size:10.0pt;font-family:"Arial
Unicode MS",sans-serif">Classification:
<b>For internal use only</b></span></p>
<p class="MsoNormal">Hi everyone,</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"><span lang="EN-US">I have a little
question regarding the Approved Site revocation
behavior.</span></p>
<p class="MsoNormal"><span lang="EN-US"> </span></p>
<p class="MsoNormal"><span lang="EN-US">Here is what I did
see on the Database Tables:</span></p>
<p class="MsoListParagraph"
style="text-indent:-18.0pt;mso-list:l0 level1 lfo2"><!--[if !supportLists]--><span
style="mso-list:Ignore">-<span style="font:7.0pt
"Times New Roman""> </span></span><!--[endif]-->
<span lang="EN-US">Access Tokens are tied to Approved
Sites via the database field ”</span><span
style="font-size:9.0pt;font-family:Consolas;color:#24292E;background:white"
lang="EN-US">approved_site_id</span><span lang="EN-US">”.</span></p>
<p class="MsoListParagraph"
style="text-indent:-18.0pt;mso-list:l0 level1 lfo2"><!--[if !supportLists]--><span
style="mso-list:Ignore">-<span style="font:7.0pt
"Times New Roman""> </span></span><!--[endif]-->
<span lang="EN-US">Refresh Tokens are tied to Access
Tokens via the database field “</span><span
style="font-size:9.0pt;font-family:Consolas;color:#24292E;background:white"
lang="EN-US">refresh_token_id</span><span lang="EN-US">”.</span></p>
<p class="MsoNormal"><span lang="EN-US"> </span></p>
<p class="MsoNormal"><span lang="EN-US">Now if you remove an
Approved Site the method “</span><span class="pl-en"><span
style="font-size:9.0pt;font-family:Consolas;color:#795DA3;background:white"
lang="EN-US">DefaultApprovedSiteService.</span></span><span
style="font-size:9.0pt;font-family:Consolas;color:#795DA3;background:white"
lang="EN-US">remove()</span><span lang="EN-US">” is
used. This will get all access tokens, remove all
associated refresh tokens and then delete the access
token. In the end it removes the Approved Site. This is
exactly the behavior I did expect.</span></p>
<p class="MsoNormal"><span lang="EN-US"> </span></p>
<p class="MsoNormal"><span lang="EN-US">This behavior
changes once the Refresh Token was used the first time.
With the usage, the “</span><span class="pl-en"><span
style="font-size:9.0pt;font-family:Consolas;color:#795DA3;background:white"
lang="EN-US">DefaultOAuth2ProviderTokenService.</span></span><span
style="font-size:9.0pt;font-family:Consolas;color:#795DA3;background:white"
lang="EN-US">refreshAccessToken()</span><span
lang="EN-US">” is used. This creates a new AccessToken
and re-links the new Access Token with the old Refresh
Token via “</span><span
style="font-size:9.0pt;font-family:Consolas;color:#24292E;background:white"
lang="EN-US">token</span><span class="pl-k"><span
style="font-size:9.0pt;font-family:Consolas;color:#A71D5D;background:white"
lang="EN-US">.</span></span><span
style="font-size:9.0pt;font-family:Consolas;color:#24292E;background:white"
lang="EN-US">setRefreshToken()</span><span lang="EN-US">”.
Which is correct. What I’m missing is the “</span><span
style="font-size:9.0pt;font-family:Consolas;color:#24292E;background:white"
lang="EN-US">token</span><span class="pl-k"><span
style="font-size:9.0pt;font-family:Consolas;color:#A71D5D;background:white"
lang="EN-US">.</span></span><span
style="font-size:9.0pt;font-family:Consolas;color:#24292E;background:white"
lang="EN-US">setApprovedSite()</span><span lang="EN-US">”
to the new Access Token, which should only be done, if
the site is still approved. Due to this not linking, the
Refresh & Access Tokens stay in the system until the
expire and do not get deleted by “</span><span
class="pl-en"><span
style="font-size:9.0pt;font-family:Consolas;color:#795DA3;background:white"
lang="EN-US">DefaultApprovedSiteService.</span></span><span
style="font-size:9.0pt;font-family:Consolas;color:#795DA3;background:white"
lang="EN-US">remove()</span><span lang="EN-US">”. Is
this a bug?</span></p>
<p class="MsoNormal"><span lang="EN-US"> </span></p>
<p class="MsoNormal"><span lang="EN-US">What I additionally
thought of but didn’t verify is the following scenario:
What if there are Refresh & Access Tokens created
and after a while the Access Token times out and gets
deleted by the “</span><span
style="font-size:9.0pt;font-family:Consolas;color:#183691;background:white"
lang="EN-US">taskScheduler</span><span lang="EN-US">”
calling “</span><span
style="font-size:9.0pt;font-family:Consolas;color:#183691;background:white"
lang="EN-US">defaultOAuth2ProviderTokenService.clearExpiredTokens()</span><span
lang="EN-US">”. Then we have a similar szenario like
above: a Refesh Token not linked to an Approved Site via
an Access Token. Is this a bug aswell?</span></p>
<p class="MsoNormal"><span lang="EN-US"> </span></p>
<p class="MsoNormal"><span lang="EN-US">Do we maybe add the
Approved Site to Refresh Tokens aswell?</span></p>
<p class="MsoNormal"><span lang="EN-US"> </span></p>
<p class="MsoNormal" style="text-autospace:none"><span
style="font-size:10.0pt;font-family:"Arial",sans-serif;mso-fareast-language:DE"
lang="EN-US">Beste Grüße / Kind regards,<br>
Dominik Schmich<br>
<br>
</span><span
style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#CCCCCC;mso-fareast-language:DE"
lang="EN-US">____________________________________________________</span><span
style="font-size:12.0pt;font-family:"Arial",sans-serif;color:#666666;mso-fareast-language:DE"
lang="EN-US"><br>
<br>
</span><span style="mso-fareast-language:DE"><img
id="Picture_x0020_1"
src="cid:part2.8114A397.3D4E375A@mit.edu"
alt="imap://jricher@imap.exchange.mit.edu:993/fetch%3EUID%3E/Projects/MITREid%3E1960?header=quotebody&part=1.2&filename=image001.png"
height="46" border="0" width="46"></span><span
style="font-size:12.0pt;font-family:"Arial",sans-serif;color:#666666;mso-fareast-language:DE"
lang="EN-US"><br>
<br>
</span><span
style="font-size:10.5pt;font-family:"Arial",sans-serif;mso-fareast-language:DE"
lang="EN-US">Dominik Schmich</span><span
style="font-size:12.0pt;font-family:"Arial",sans-serif;color:#666666;mso-fareast-language:DE"
lang="EN-US"><br>
</span><span
style="font-size:8.5pt;font-family:"Arial",sans-serif;mso-fareast-language:DE"
lang="EN-US">Assistant Vice President | Solution
Architect<br>
<br>
Deutsche Bank AG<br>
COO PW&CC Technology, Strategy & Architecture</span></p>
<p class="MsoNormal" style="text-autospace:none"><span
style="font-size:8.5pt;font-family:"Arial",sans-serif;mso-fareast-language:DE"
lang="EN-US">Alfred-Herrhausen-Allee 16-24, 65760
Eschborn, Germany</span></p>
<p class="MsoNormal"><span
style="font-size:8.5pt;font-family:"Arial",sans-serif;mso-fareast-language:DE"
lang="EN-US">Tel. +49 69 910-60543<br>
Mobile +49 1723700665<br>
Email <a moz-do-not-send="true"
href="mailto:dominik.schmich@db.com">dominik.schmich@db.com</a></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Times New
Roman",serif;mso-fareast-language:DE"><br>
</span><span
style="font-size:12.0pt;font-family:"Arial",sans-serif;mso-fareast-language:DE"><br>
---<br>
Die Europäische Kommission hat unter <a
moz-do-not-send="true"
href="http://ec.europa.eu/consumers/odr/">
http://ec.europa.eu/consumers/odr/</a> eine
Europäische Online-Streitbeilegungsplattform
(OS-Plattform) errichtet. Die OS-Plattform kann ein
Verbraucher für die außergerichtliche Beilegung einer
Streitigkeit aus Online-Verträgen mit einem in der EU
niedergelassenen Unternehmen nutzen.<br>
<br>
Informationen (einschließlich Pflichtangaben) zu
einzelnen, innerhalb der EU tätigen Gesellschaften und
Zweigniederlassungen des Konzerns Deutsche Bank finden
Sie unter
<a moz-do-not-send="true"
href="https://www.deutsche-bank.de/Pflichtangaben">https://www.deutsche-bank.de/Pflichtangaben</a>.
Diese E-Mail enthält vertrauliche und/ oder rechtlich
geschützte Informationen. Wenn Sie nicht der richtige
Adressat sind oder diese E-Mail irrtümlich erhalten
haben, informieren Sie bitte sofort den Absender und
vernichten Sie diese E-Mail. Das unerlaubte Kopieren
sowie die unbefugte Weitergabe dieser E-Mail ist nicht
gestattet.<br>
<br>
The European Commission has established a European
online dispute resolution platform (OS platform) under
<a moz-do-not-send="true"
href="http://ec.europa.eu/consumers/odr/">http://ec.europa.eu/consumers/odr/</a>.
The OS platform can be used by a consumer for the
extra-judicial settlement of a dispute of online
contracts with a provider established in the EU
companies.<br>
<br>
Please refer to <a moz-do-not-send="true"
href="https://www.db.com/disclosures">https://www.db.com/disclosures</a>
for information (including mandatory corporate
particulars) on selected Deutsche Bank branches and
group companies registered or incorporated in the
European Union. This e-mail may contain confidential
and/or privileged information. If you are not the
intended recipient (or have received this e-mail in
error) please notify the sender immediately and delete
this e-mail. Any unauthorized copying, disclosure or
distribution of the material in this e-mail is strictly
forbidden.</span></p>
</blockquote>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Times New
Roman",serif;mso-fareast-language:DE"> </span></p>
</div>
<br>
<font face="Arial" color="black" size="3"><br>
---<br>
Die Europäische Kommission hat unter <a
moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://ec.europa.eu/consumers/odr/">
http://ec.europa.eu/consumers/odr/</a> eine Europäische
Online-Streitbeilegungsplattform (OS-Plattform) errichtet.
Verbraucher können die OS-Plattform für die außergerichtliche
Beilegung von Streitigkeiten aus Online-Verträgen mit in der
EU niedergelassenen Unternehmen nutzen.<br>
<br>
Informationen (einschließlich Pflichtangaben) zu einzelnen,
innerhalb der EU tätigen Gesellschaften und
Zweigniederlassungen des Konzerns Deutsche Bank finden Sie
unter
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://www.deutsche-bank.de/Pflichtangaben">
https://www.deutsche-bank.de/Pflichtangaben</a>. Diese
E-Mail enthält vertrauliche und/ oder rechtlich geschützte
Informationen. Wenn Sie nicht der richtige Adressat sind oder
diese E-Mail irrtümlich erhalten haben, informieren Sie bitte
sofort den Absender und vernichten Sie diese E-Mail. Das
unerlaubte Kopieren sowie die unbefugte Weitergabe dieser
E-Mail ist nicht gestattet.<br>
<br>
The European Commission has established a European online
dispute resolution platform (OS platform) under
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://ec.europa.eu/consumers/odr/">http://ec.europa.eu/consumers/odr/</a>.
Consumers may use the OS platform to resolve disputes arising
from online contracts with providers established in the EU.<br>
<br>
Please refer to <a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="https://www.db.com/disclosures">
https://www.db.com/disclosures</a> for information
(including mandatory corporate particulars) on selected
Deutsche Bank branches and group companies registered or
incorporated in the European Union. This e-mail may contain
confidential and/or privileged information. If you are not the
intended recipient (or have received this e-mail in error)
please notify the sender immediately and delete this e-mail.
Any unauthorized copying, disclosure or distribution of the
material in this e-mail is strictly forbidden.<br>
</font></blockquote>
<br>
<br>
<font face="Arial" color="Black" size="3"><br>
---<br>
Die Europäische Kommission hat unter
<a class="moz-txt-link-freetext" href="http://ec.europa.eu/consumers/odr/">http://ec.europa.eu/consumers/odr/</a> eine Europäische
Online-Streitbeilegungsplattform (OS-Plattform) errichtet.
Verbraucher können die OS-Plattform für die außergerichtliche
Beilegung von Streitigkeiten aus Online-Verträgen mit in der EU
niedergelassenen Unternehmen nutzen.<br>
<br>
Informationen (einschließlich Pflichtangaben) zu einzelnen,
innerhalb der EU tätigen Gesellschaften und Zweigniederlassungen
des Konzerns Deutsche Bank finden Sie unter
<a class="moz-txt-link-freetext" href="https://www.deutsche-bank.de/Pflichtangaben">https://www.deutsche-bank.de/Pflichtangaben</a>. Diese E-Mail
enthält vertrauliche und/ oder rechtlich geschützte
Informationen. Wenn Sie nicht der richtige Adressat sind oder
diese E-Mail irrtümlich erhalten haben, informieren Sie bitte
sofort den Absender und vernichten Sie diese E-Mail. Das
unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail
ist nicht gestattet.<br>
<br>
The European Commission has established a European online
dispute resolution platform (OS platform) under
<a class="moz-txt-link-freetext" href="http://ec.europa.eu/consumers/odr/">http://ec.europa.eu/consumers/odr/</a>. Consumers may use the OS
platform to resolve disputes arising from online contracts with
providers established in the EU.<br>
<br>
Please refer to <a class="moz-txt-link-freetext" href="https://www.db.com/disclosures">https://www.db.com/disclosures</a> for information
(including mandatory corporate particulars) on selected Deutsche
Bank branches and group companies registered or incorporated in
the European Union. This e-mail may contain confidential and/or
privileged information. If you are not the intended recipient
(or have received this e-mail in error) please notify the sender
immediately and delete this e-mail. Any unauthorized copying,
disclosure or distribution of the material in this e-mail is
strictly forbidden.<br>
</font>
</blockquote>
<br>
</body>
</html>