<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<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">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<!--[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]-->
<style><!--
/* 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><!--[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><o:p></o:p></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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-US"><o:p> </o:p></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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-US"><o:p> </o:p></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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-US"><o:p> </o:p></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?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-US"><o:p> </o:p></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:part1.B87CFD88.88B0C577@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<o:p></o:p></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<o:p></o:p></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><span
style="font-size:12.0pt;font-family:"Arial",sans-serif;color:#666666;mso-fareast-language:DE"
lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><span
style="color:#1F497D;mso-fareast-language:DE" lang="EN-US"><o:p> </o:p></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:part3.E5C22363.DAE7AD11@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><span
style="color:#1F497D;mso-fareast-language:DE"><o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></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 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 class="moz-txt-link-rfc2396E" href="mailto:dominik.schmich@db.com"><dominik.schmich@db.com></a>; mitreid-connect
<a 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]<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></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.
<o:p></o:p></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.
<o:p></o:p></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.<o:p></o:p></p>
<p> -- Justin<o:p></o:p></p>
<div>
<p class="MsoNormal">On 3/10/2017 3:01 AM, Dominik Schmich
wrote:<o:p></o:p></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><o:p></o:p></p>
<p class="MsoNormal">Hi everyone,<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US">I have a little
question regarding the Approved Site revocation behavior.</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US">Here is what I did see
on the Database Tables:</span><o:p></o:p></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><o:p></o:p></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><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US"> </span><o:p></o:p></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><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US"> </span><o:p></o:p></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><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US"> </span><o:p></o:p></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><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US">Do we maybe add the
Approved Site to Refresh Tokens aswell?</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US"> </span><o:p></o:p></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:part1.B87CFD88.88B0C577@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><o:p></o:p></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><o:p></o:p></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><o:p></o:p></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><span
style="font-size:12.0pt;font-family:"Times New
Roman",serif;mso-fareast-language:DE"><o:p></o:p></span></p>
</blockquote>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Times New
Roman",serif;mso-fareast-language:DE"><o:p> </o:p></span></p>
</div>
<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>