<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<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]-->
</head>
<body bgcolor="white" lang="DE" link="#0563C1" vlink="#954F72">
<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 lang="EN-US" style="color:#1F497D">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 lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">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 lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">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 lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">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 lang="EN-US" style="color:#1F497D"><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 width="46" height="46" id="Picture_x0020_3" src="cid:image001.png@01D2A044.68C77C90" alt="cid:image001.png@01D2A044.68C77C90"></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 lang="EN-US" style="font-size:8.5pt;font-family:"Arial",sans-serif;mso-fareast-language:DE">Alfred-Herrhausen-Allee 16-24, 65760 Eschborn, Germany<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:8.5pt;font-family:"Arial",sans-serif;mso-fareast-language:DE">Tel. +49 69 910-60543<br>
Mobile +49 1723700665<br>
Email <a 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 lang="EN-US" style="font-size:12.0pt;font-family:"Arial",sans-serif;color:#666666;mso-fareast-language:DE"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D;mso-fareast-language:DE"><o:p> </o:p></span></p>
<p class="MsoNormal"><a href="https://api-open.db.com/"><span style="font-family:"Times New Roman",serif;color:#1F497D;mso-fareast-language:DE;text-decoration:none"><img border="0" width="372" height="121" id="Picture_x0020_2" src="cid:image002.png@01D2A044.68C77C90" alt="cid:image002.png@01D2A044.68C77C90"></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 name="_____replyseparator"></a><b><span lang="EN-US" style="color:windowtext;mso-fareast-language:DE">From:</span></b><span lang="EN-US" style="color:windowtext;mso-fareast-language:DE"> Justin Richer [mailto:jricher@mit.edu]
<br>
<b>Sent:</b> Montag, 13. März 2017 19:03<br>
<b>To:</b> Dominik Schmich <dominik.schmich@db.com>; mitreid-connect <mitreid-connect@mit.edu><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 lang="EN-US" style="font-size:9.0pt;font-family:Consolas;color:#24292E;background:white">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 lang="EN-US" style="font-size:9.0pt;font-family:Consolas;color:#24292E;background:white">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 lang="EN-US" style="font-size:9.0pt;font-family:Consolas;color:#795DA3;background:white">DefaultApprovedSiteService.</span></span><span lang="EN-US" style="font-size:9.0pt;font-family:Consolas;color:#795DA3;background:white">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 lang="EN-US" style="font-size:9.0pt;font-family:Consolas;color:#795DA3;background:white">DefaultOAuth2ProviderTokenService.</span></span><span lang="EN-US" style="font-size:9.0pt;font-family:Consolas;color:#795DA3;background:white">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 lang="EN-US" style="font-size:9.0pt;font-family:Consolas;color:#24292E;background:white">token</span><span class="pl-k"><span lang="EN-US" style="font-size:9.0pt;font-family:Consolas;color:#A71D5D;background:white">.</span></span><span lang="EN-US" style="font-size:9.0pt;font-family:Consolas;color:#24292E;background:white">setRefreshToken()</span><span lang="EN-US">”.
Which is correct. What I’m missing is the “</span><span lang="EN-US" style="font-size:9.0pt;font-family:Consolas;color:#24292E;background:white">token</span><span class="pl-k"><span lang="EN-US" style="font-size:9.0pt;font-family:Consolas;color:#A71D5D;background:white">.</span></span><span lang="EN-US" style="font-size:9.0pt;font-family:Consolas;color:#24292E;background:white">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 lang="EN-US" style="font-size:9.0pt;font-family:Consolas;color:#795DA3;background:white">DefaultApprovedSiteService.</span></span><span lang="EN-US" style="font-size:9.0pt;font-family:Consolas;color:#795DA3;background:white">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 lang="EN-US" style="font-size:9.0pt;font-family:Consolas;color:#183691;background:white">taskScheduler</span><span lang="EN-US">”
calling “</span><span lang="EN-US" style="font-size:9.0pt;font-family:Consolas;color:#183691;background:white">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 lang="EN-US" 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 lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#CCCCCC;mso-fareast-language:DE">____________________________________________________</span><span lang="EN-US" style="font-size:12.0pt;font-family:"Arial",sans-serif;color:#666666;mso-fareast-language:DE"><br>
<br>
</span><span style="mso-fareast-language:DE"><img border="0" width="46" height="46" id="Picture_x0020_1" src="cid:image001.png@01D2A044.68C77C90" alt="cid:image001.png@01D2A044.68C77C90"></span><span lang="EN-US" style="font-size:12.0pt;font-family:"Arial",sans-serif;color:#666666;mso-fareast-language:DE"><br>
<br>
</span><span lang="EN-US" style="font-size:10.5pt;font-family:"Arial",sans-serif;mso-fareast-language:DE">Dominik Schmich</span><span lang="EN-US" style="font-size:12.0pt;font-family:"Arial",sans-serif;color:#666666;mso-fareast-language:DE"><br>
</span><span lang="EN-US" 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><o:p></o:p></p>
<p class="MsoNormal" style="text-autospace:none"><span lang="EN-US" style="font-size:8.5pt;font-family:"Arial",sans-serif;mso-fareast-language:DE">Alfred-Herrhausen-Allee 16-24, 65760 Eschborn, Germany</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:8.5pt;font-family:"Arial",sans-serif;mso-fareast-language:DE">Tel. +49 69 910-60543<br>
Mobile +49 1723700665<br>
Email <a 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 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 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 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 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 http://ec.europa.eu/consumers/odr/ 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 https://www.deutsche-bank.de/Pflichtangaben. 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 http://ec.europa.eu/consumers/odr/. Consumers may use the OS platform to resolve disputes arising from online contracts with providers established in the
EU.<br>
<br>
Please refer to https://www.db.com/disclosures 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>
</body>
</html>