<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br></div><div id="AppleMailSignature">Mike</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Cc: openid connect list </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">[personal hat]</div><div id="AppleMailSignature">I believe that your position severely limits the value of having a SET spec. </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">If logout has different parsing rules than the other specs, interop is compromised due to different handling for different security components. </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">As I said before, within the context of OpenId, I feel backchannel logout is too narrowly defined and many other logout and session events will be needed that are user triggered depending on scenario. </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Marius's point is important. </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">For example we want to let the IDP know a subject has logged out of a specific RP. This is different from a logout command which signals single-logout / SLO at the OP to all RPs. In this case the SET is issued by the RP and not the OP/IDP. </div><div id="AppleMailSignature"><br>Phil</div><div><br>On Jun 19, 2017, at 2:27 PM, Mike Jones <<a href="mailto:Michael.Jones@microsoft.com">Michael.Jones@microsoft.com</a>> wrote:<br><br></div><blockquote type="cite"><div>
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 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:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.m4441714448721077057m9094089239668570312msolistparagraph, li.m4441714448721077057m9094089239668570312msolistparagraph, div.m4441714448721077057m9094089239668570312msolistparagraph
{mso-style-name:m_4441714448721077057m9094089239668570312msolistparagraph;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
span.EmailStyle22
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#002060;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:183985348;
mso-list-template-ids:-174955488;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1
{mso-list-id:507794838;
mso-list-template-ids:1476716138;}
@list l1:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level2
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2
{mso-list-id:600798457;
mso-list-template-ids:-1577572970;}
@list l2:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level2
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l3
{mso-list-id:687950587;
mso-list-template-ids:1636752328;}
@list l3:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l3:level2
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l3:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l3:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l3:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l3:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l3:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l3:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l3:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l4
{mso-list-id:807669218;
mso-list-template-ids:-1191968090;}
@list l4:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l4:level2
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l4:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l4:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l4:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l4:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l4:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l4:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l4:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l5
{mso-list-id:939407245;
mso-list-template-ids:-1534314316;}
@list l5:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l5:level2
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l5:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l5:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l5:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l5:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l5:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l5:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l5:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l6
{mso-list-id:1548564422;
mso-list-template-ids:-1066471674;}
@list l6:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l6:level2
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l6:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l6:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l6:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l6:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l6:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l6:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l6:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l7
{mso-list-id:1898741233;
mso-list-template-ids:-1146176764;}
@list l7:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l7:level2
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l7:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l7:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l7:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l7:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l7:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l7:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l7:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></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 class="MsoNormal"><span style="color:#002060">Marius, there’s nothing stopping you (or the RISC working group or other profiles) from defining events that can be sent from RPs to IdPs now, without any changes to the SET spec. Specify the claims you want
to use, and you’re golden.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#002060"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#002060">But it would be counterproductive to require all other SETs to meet the requirements of your specific profile. There are simpler use cases that can use claims in simpler ways. Trying to make the simple use
cases be complex will have the side effect of limiting the adoption of the spec, which wouldn’t be good for anyone.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#002060"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#002060">If successful, SETs will have many different profiles. That’s a sign of success – not a sign of weakness.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#002060"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#002060"> -- Mike<o:p></o:p></span></p>
<p class="MsoNormal"><a name="_MailEndCompose"><span style="color:#002060"><o:p> </o:p></span></a></p>
<span style="mso-bookmark:_MailEndCompose"></span>
<p class="MsoNormal"><b>From:</b> Marius Scurtescu [<a href="mailto:mscurtescu@google.com">mailto:mscurtescu@google.com</a>]
<br>
<b>Sent:</b> Monday, June 19, 2017 11:58 AM<br>
<b>To:</b> Mike Jones <<a href="mailto:Michael.Jones@microsoft.com">Michael.Jones@microsoft.com</a>><br>
<b>Cc:</b> Yaron Sheffer <<a href="mailto:yaronf.ietf@gmail.com">yaronf.ietf@gmail.com</a>>; Justin Richer <<a href="mailto:jricher@mit.edu">jricher@mit.edu</a>>; Richard Backman, Annabelle <<a href="mailto:richanna@amazon.com">richanna@amazon.com</a>>; Henk Birkholz <<a href="mailto:henk.birkholz@sit.fraunhofer.de">henk.birkholz@sit.fraunhofer.de</a>>; ID Events Mailing List <<a href="mailto:id-event@ietf.org">id-event@ietf.org</a>>; Phil Hunt <<a href="mailto:phil.hunt@oracle.com">phil.hunt@oracle.com</a>><br>
<b>Subject:</b> Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<div>
<p class="MsoNormal">On Sat, Jun 17, 2017 at 2:06 PM, Mike Jones <<a href="mailto:Michael.Jones@microsoft.com" target="_blank">Michael.Jones@microsoft.com</a>> wrote:<o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:#002060">I’m sorry to be slow replying to some messages in this thread. I have a lot of other things on my plate, but I will take the time now to reply, because
I wholeheartedly disagree with some of the statements below and believe it would be severely harmful to the specification and its adoption to act upon them. Specifically:</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:#002060"> </span><o:p></o:p></p>
<ul type="disc">
<li class="MsoNormal" style="color:#002060;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l7 level1 lfo1">
I disagree that specific rules should be made for the “sub” claim. Claims usage needs to be up to the application. I know that many others agree with me, because the OpenID Connect working group designed the logout token in
<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__openid.net_specs_openid-2Dconnect-2Dbackchannel-2D1-5F0-2D04.html-23LogoutToken&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=v4DwjKKsJwoRsAumAL_W7MPPBf0cjsWUW5s3v4G5rhw&s=7YlB_wNqqc7lzygZd9r7hqifDZUcfRnqW1B2G_5kPMY&e=" target="_blank">
http://openid.net/specs/openid-connect-backchannel-1_0-04.html#LogoutToken</a> (which is also used as an example in
<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dsecevent-2Dtoken-2D01-23section-2D2&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=v4DwjKKsJwoRsAumAL_W7MPPBf0cjsWUW5s3v4G5rhw&s=jAo4XYpHvjqtcw_X9zoqtNYhcKfLva43hLyF2ft25Lc&e=" target="_blank">
https://tools.ietf.org/html/draft-ietf-secevent-token-01#section-2</a>) to use the “sub” claim in the normal way. Prohibiting this usage would be a completely unnecessary breaking change – as it’s impossible to confuse a logout token with an ID Token, for
reasons already cites in this thread.<o:p></o:p></li></ul>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal">Solving the confusion is one problem. The other problem I keep mentioning is SETs issued by an RP to be sent to an IdP. How are we solving that problem Mike? In this case the top level iss is different from the iss of the sub, a top level
sub is not possible.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">And I don't want to downplay the confusion problem either. I think it is a real concern and I think a solid solution is important.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The OpenID Working Group designed logout tokens without secevent in mind. I agree we should not recklessly break compatibility, but to me it seems necessary in this case.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<ul type="disc">
<li class="MsoNormal" style="color:#002060;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l6 level1 lfo2">
<o:p> </o:p></li></ul>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:#002060"> </span><o:p></o:p></p>
<ul type="disc">
<li class="MsoNormal" style="color:#002060;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l4 level1 lfo3">
(I agree with the “iss” rules already in place at <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dsecevent-2Dtoken-2D01-23section-2D2.1&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=v4DwjKKsJwoRsAumAL_W7MPPBf0cjsWUW5s3v4G5rhw&s=busSJi2UnR0TRU8fJ_vAofGykXA6SwiIwqyKMp7lIt8&e=" target="_blank">
https://tools.ietf.org/html/draft-ietf-secevent-token-01#section-2.1</a>. No further “iss” rules are needed.)<o:p></o:p></li></ul>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Further iss ruies are absolutely needed for the RP to IdP case described above.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<ul type="disc">
<li class="MsoNormal" style="color:#002060;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l2 level1 lfo4">
<o:p> </o:p></li></ul>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:#002060"> </span><o:p></o:p></p>
<ul type="disc">
<li class="MsoNormal" style="color:#002060;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l1 level1 lfo5">
It’s fine for the “typ” header parameter to be used for some profiles to differentiate between kinds of JWTs. Its use should not be mandated in the SET spec. I would oppose duplicating the “typ” functionality by defining another claim with a duplicative meaning.<o:p></o:p></li></ul>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal">If typ can be use and no other claim is needed, then let's talk about that. I do think SET should mandate it. I don't understand why not. Can you please propose with examples how can typ be used?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<ul type="disc">
<li class="MsoNormal" style="color:#002060;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l3 level1 lfo6">
<o:p> </o:p></li></ul>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:#002060"> </span><o:p></o:p></p>
<ul type="disc">
<li class="MsoNormal" style="color:#002060;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l0 level1 lfo7">
I’ll also respond to Annabelle’s assertion that “<span style="color:black">No other profile of JWT can ever use the "nonce” claim.</span>” This reflects a misunderstanding. It’s the *<b>value</b>* of the nonce that self-secures the JWT – not that any “nonce”
claim is present. Any and all JWTs can simultaneously use “nonce” without any risk of conflict, since the nonce value is a cryptographically secure random number.<o:p></o:p></li></ul>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">For SETs I cannot see how the nonce value is useful. That value is not passed back and it cannot be verified. Only the presence of the claim could have some use, hinting at the usage of the JWT, a very weak solution to the confusion problem.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<ul type="disc">
<li class="MsoNormal" style="color:#002060;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l5 level1 lfo8">
<o:p> </o:p></li></ul>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:#002060"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:#002060">Will some of you be at the Cloud Identity Summit next week? I’d be glad to have in-person discussions about these topics there.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:#002060"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:#002060"> -- Mike</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:#002060"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:#002060">P.S. Food for thought: Prohibiting the use of “sub” (or any other claim) or forcing it to be located in a non-standard location makes about as much
sense as arbitrarily saying that, for a particular profile, the Latin word for subject “subiectum” must be used as the claim name instead of “sub”. Yes, it will completely differentiate this profile from others not spelling the claim name this way, but it
would certainly be an impediment to the use of standard JWT libraries and to interoperability.</span><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">If we define that sub must be at the event level then it is at a standard location, I don't see what the issue is. The impediment you mention is the actual solution. I don't think that a JWT library that was written for Id Tokens should
be used to parse SETs. The library has to be SET aware, in which case the event level iss+sub is not an issue at all.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><a name="m_4441714448721077057__MailEndCompose"><span style="color:#002060"> </span></a><o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b>From:</b> Yaron Sheffer [mailto:<a href="mailto:yaronf.ietf@gmail.com" target="_blank">yaronf.ietf@gmail.com</a>]
<br>
<b>Sent:</b> Saturday, June 17, 2017 1:45 PM<br>
<b>To:</b> Justin Richer <<a href="mailto:jricher@mit.edu" target="_blank">jricher@mit.edu</a>>; Marius Scurtescu <<a href="mailto:mscurtescu@google.com" target="_blank">mscurtescu@google.com</a>><br>
<b>Cc:</b> Richard Backman, Annabelle <<a href="mailto:richanna@amazon.com" target="_blank">richanna@amazon.com</a>>; Mike Jones <<a href="mailto:Michael.Jones@microsoft.com" target="_blank">Michael.Jones@microsoft.com</a>>; Henk Birkholz <<a href="mailto:henk.birkholz@sit.fraunhofer.de" target="_blank">henk.birkholz@sit.fraunhofer.de</a>>;
ID Events Mailing List <<a href="mailto:id-event@ietf.org" target="_blank">id-event@ietf.org</a>>; Phil Hunt <<a href="mailto:phil.hunt@oracle.com" target="_blank">phil.hunt@oracle.com</a>><o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><br>
<b>Subject:</b> Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer<o:p></o:p></p>
</div>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p>So to summarize what I'm seeing on this thread:<o:p></o:p></p>
<p>Everybody agrees with Marius's short-term solution, specific rules for "sub" and "iss" that can be defined in the SET spec.<o:p></o:p></p>
<p>Almost everybody agrees on a long-term "usage" claim ("type" is taken) that should be defined elsewhere, e.g. in the JWT BCP.<o:p></o:p></p>
<p>Did I miss anything?<o:p></o:p></p>
<p>By the way, if we do add a "usage" claim, we need to also use it in the SET document before it is published.<o:p></o:p></p>
<p>Thanks,<o:p></o:p></p>
<p> Yaron<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On 15/06/17 22:08, Justin Richer wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">+1 to this as well.
<o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> — Justin<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On Jun 15, 2017, at 1:09 PM, Marius Scurtescu <<a href="mailto:mscurtescu@google.com" target="_blank">mscurtescu@google.com</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">+1 to what Annabelle said.
<o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Also, Mike you are missing the other requirement, for RPs to send events to an IdP. The iss+sub pair at the top level is broken in this case.<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><br clear="all">
<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Marius<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) <<a href="mailto:phil.hunt@oracle.com" target="_blank">phil.hunt@oracle.com</a>> wrote:<o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">+1<o:p></o:p></p>
</div>
<div id="m_4441714448721077057m_9094089239668570312AppleMailSignature">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div id="m_4441714448721077057m_9094089239668570312AppleMailSignature">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Phil<o:p></o:p></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"><br>
On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle <<a href="mailto:richanna@amazon.com" target="_blank">richanna@amazon.com</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Mike,<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Your explanation for why this is a non-problem is dependent upon side effects of elements of OpenID Connect that were not designed to solve this issue. As a result, I see several
issues with it:<o:p></o:p></p>
<p class="m4441714448721077057m9094089239668570312msolistparagraph">1.<span style="font-size:7.0pt;font-family:"Times New Roman",serif">
</span>The caller of the Token Endpoint is the only party that can be certain that a nonce-less ID Token is really an ID Token. Any party that the caller passes the ID Token off to has no way to verify its provenance.<o:p></o:p></p>
<p class="m4441714448721077057m9094089239668570312msolistparagraph">2.<span style="font-size:7.0pt;font-family:"Times New Roman",serif">
</span>Any future ID Token distribution method needs to solve this problem again.<o:p></o:p></p>
<p class="m4441714448721077057m9094089239668570312msolistparagraph">3.<span style="font-size:7.0pt;font-family:"Times New Roman",serif">
</span>No other profile of JWT can ever use the "nonce” claim.<o:p></o:p></p>
<p class="m4441714448721077057m9094089239668570312msolistparagraph">4.<span style="font-size:7.0pt;font-family:"Times New Roman",serif">
</span>This is only a solution for ID Tokens. Every other JWT profile that cares about disambiguation has to invent its own solution to the problem.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">We know from experience that naming collisions and replay attacks are both things that happen. What’s being proposed is a simple, defensive measure against these risks. You brought
up JWT libraries: a general solution actually makes it easier to use common libraries for JWT parsing. A “usage-aware” JWT library could handle disambiguation for any JWT profile, whereas with the status quo each profile would require unique logic.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">-- <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Annabelle Richard Backman<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Identity Services<o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b>From:
</b>Id-event <<a href="mailto:id-event-bounces@ietf.org" target="_blank">id-event-bounces@ietf.org</a>> on behalf of Mike Jones <<a href="mailto:Michael.Jones@microsoft.com" target="_blank">Michael.Jones@microsoft.com</a>><br>
<b>Date: </b>Wednesday, June 14, 2017 at 1:16 PM<br>
<b>To: </b>Marius Scurtescu <<a href="mailto:mscurtescu@google.com" target="_blank">mscurtescu@google.com</a>><br>
<b>Cc: </b>"Richard Backman, Annabelle" <<a href="mailto:richanna@amazon.com" target="_blank">richanna@amazon.com</a>>, ID Events Mailing List <<a href="mailto:id-event@ietf.org" target="_blank">id-event@ietf.org</a>>, Henk Birkholz <<a href="mailto:henk.birkholz@sit.fraunhofer.de" target="_blank">henk.birkholz@sit.fraunhofer.de</a>><br>
<b>Subject: </b>Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:#002060">You’ve heard of “premature optimization”. I’d characterize the proposals in this thread as “premature pessimation” – making things that can and should
be simple complex, without data showing there’s any need to do so.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:#002060"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:#002060">Mandatory solutions are being proposed in this thread to problems that there’s no evidence that we actually even have. It’s already been established
that it’s impossible for a SET to be confused for an ID Token – see <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00428.html&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Uslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=eKLTQPmYrV3ThfDbn90SCs55UROTPin_lgc6Rdr5Xow&e=" target="_blank">
https://www.ietf.org/mail-archive/web/id-event/current/msg00428.html</a>. If people have data showing that this is possible with specific kinds of Access Tokens or other real JWT deployments, please provide specifics, so that we can use that data to inform
appropriate engineering choices on our part.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:#002060"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:#002060">The proposed “solutions”, such as prohibiting the use of “sub” in the normal way, or requiring a type claim, would make previously simple things unnecessarily
complex. Yes, then the result is then different than a normal JWT but a consequence of this is that custom parsing code would have to be used, rather than a standard JWT parser. The more unwieldy we make it to use SETs, the more likely developers are to
just create their own data structures. Keeping it simple is the key to adoption. Standards are only useful if they are actually used.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:#002060"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:#002060"> -- Mike</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:#002060"> </span><o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b>From:</b> Id-event [<a href="mailto:id-event-bounces@ietf.org" target="_blank">mailto:id-event-bounces@ietf.org</a>]
<b>On Behalf Of </b>Richard Backman, Annabelle<br>
<b>Sent:</b> Tuesday, June 13, 2017 5:33 PM<br>
<b>To:</b> Marius Scurtescu <<a href="mailto:mscurtescu@google.com" target="_blank">mscurtescu@google.com</a>>; Henk Birkholz <<a href="mailto:henk.birkholz@sit.fraunhofer.de" target="_blank">henk.birkholz@sit.fraunhofer.de</a>><br>
<b>Cc:</b> ID Events Mailing List <<a href="mailto:id-event@ietf.org" target="_blank">id-event@ietf.org</a>><br>
<b>Subject:</b> Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Echoing Marius’s question: can you explain what you mean by “intend”?<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">To your first question, I think a better analogy would be the X.509 Key Usage extension: a multi-valued property that declares the intended purpose of the JWT, and that a recipient
may refer to when determining whether to accept a JWT being presented to it in some context.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">-- <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Annabelle Richard Backman<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Identity Services<o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b>From:
</b>Id-event <<a href="mailto:id-event-bounces@ietf.org" target="_blank">id-event-bounces@ietf.org</a>> on behalf of Marius Scurtescu <<a href="mailto:mscurtescu@google.com" target="_blank">mscurtescu@google.com</a>><br>
<b>Date: </b>Tuesday, June 13, 2017 at 11:05 AM<br>
<b>To: </b>Henk Birkholz <<a href="mailto:henk.birkholz@sit.fraunhofer.de" target="_blank">henk.birkholz@sit.fraunhofer.de</a>><br>
<b>Cc: </b>ID Events Mailing List <<a href="mailto:id-event@ietf.org" target="_blank">id-event@ietf.org</a>><br>
<b>Subject: </b>Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz <<a href="mailto:henk.birkholz@sit.fraunhofer.de" target="_blank">henk.birkholz@sit.fraunhofer.de</a>> wrote:<o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">And a 2nd question.<br>
<br>
What semantics would "usage" provide that that are not covered via "intend", "audience", and "scope"?<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">"aud" (audience) specifies the target client, but not the intended usage (access token to authorize resource access or SET to communicate a security event?)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">"scope" is not used by SET.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I don't know what do you mean by "intend" (or intent)?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><br>
<br>
Henk<br>
<br>
On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote:<o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Thanks for putting this together!<br>
<br>
I think the assumptions inherent in 3.9 are flawed:<br>
<br>
·We can’t guarantee that every type of JWT will have a mutually exclusive set of valid claims and/or header parameters, and enforcing this requires a “fail on an unrecognized claim” approach to ensure that JWTs from some future spec can’t be mistaken for JWTs
from a current spec.<br>
<br>
·It is unrealistic to expect implementers to adhere to the “different keys for different kinds of JWTs” rule. Whether mandated by the spec or not, implementers will ignore this because managing one key is easier than managing N different keys.<br>
<br>
·Ditto for “aud” and “iss” claims.<br>
<br>
+1 for a “type” or “usage” claim/header parameter.<br>
<br>
-- <br>
<br>
Annabelle Richard Backman<br>
<br>
Identity Services<br>
<br>
*From: *Id-event <<a href="mailto:id-event-bounces@ietf.org" target="_blank">id-event-bounces@ietf.org</a>> on behalf of Dick Hardt <<a href="mailto:dick.hardt@gmail.com" target="_blank">dick.hardt@gmail.com</a>><br>
*Date: *Monday, June 12, 2017 at 3:18 PM<br>
*To: *Marius Scurtescu <<a href="mailto:mscurtescu@google.com" target="_blank">mscurtescu@google.com</a>><br>
*Cc: *Adam Dawes <<a href="mailto:adawes@google.com" target="_blank">adawes@google.com</a>>, "matake, nov" <<a href="mailto:nov@matake.jp" target="_blank">nov@matake.jp</a>>, ID Events Mailing List <<a href="mailto:id-event@ietf.org" target="_blank">id-event@ietf.org</a>>,
"Phil Hunt (IDM)" <<a href="mailto:phil.hunt@oracle.com" target="_blank">phil.hunt@oracle.com</a>><br>
*Subject: *Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer<br>
<br>
Agreed. Note that there is still lots of discussion on what should be in 3.9.<br>
<br>
On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu <<a href="mailto:mscurtescu@google.com" target="_blank">mscurtescu@google.com</a> <mailto:<a href="mailto:mscurtescu@google.com" target="_blank">mscurtescu@google.com</a>>> wrote:<br>
<br>
Thanks for the pointer Dick, very good timing :-)<br>
<br>
The issue is described by "2.7. Cross-JWT Confusion" and the<br>
mitigation is in "3.9. Use Mutually Exclusive Validation Rules for<br>
Different Kinds of JWTs", specifically "Use different sets of<br>
required claims...", "Use different keys for different kinds of<br>
JWTs." and "Use different issuers for different kinds of JWTs.".<br>
<br>
I still think that a "type" claim would bring a lot of clarity and<br>
safety.<br>
<br>
<br>
Marius<br>
<br>
On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt <<a href="mailto:dick.hardt@gmail.com" target="_blank">dick.hardt@gmail.com</a><br>
<mailto:<a href="mailto:dick.hardt@gmail.com" target="_blank">dick.hardt@gmail.com</a>>> wrote:<br>
<br>
Yaron, Mike and I just published an BCP ID for JWT<br>
<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__self-2Dissued.info_-3Fp-3D1690&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Uslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=a7XvZ5jTbtA2vjfaHIMbvEOpSBBlBpdsDkITZMcUIUQ&e=" target="_blank">
http://self-issued.info/?p=1690</a><br>
<br>
On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes <<a href="mailto:adawes@google.com" target="_blank">adawes@google.com</a><br>
<mailto:<a href="mailto:adawes@google.com" target="_blank">adawes@google.com</a>>> wrote:<br>
<br>
I was initially a fan of keeping SETS to be very similar to<br>
id tokens but I now think this is a better plan.<br>
<br>
On Thu, Jun 8, 2017 at 6:56 PM matake, nov <<a href="mailto:nov@matake.jp" target="_blank">nov@matake.jp</a><br>
<mailto:<a href="mailto:nov@matake.jp" target="_blank">nov@matake.jp</a>>> wrote:<br>
<br>
+1 especially for "type"<br>
<br>
2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM)<br>
<<a href="mailto:phil.hunt@oracle.com" target="_blank">phil.hunt@oracle.com</a> <mailto:<a href="mailto:phil.hunt@oracle.com" target="_blank">phil.hunt@oracle.com</a>>>:<br>
<br>
+1<br>
<br>
Phil<br>
<br>
<br>
> On Jun 8, 2017, at 6:28 PM, Marius Scurtescu<br>
<<a href="mailto:mscurtescu@google.com" target="_blank">mscurtescu@google.com</a><o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <mailto:<a href="mailto:mscurtescu@google.com" target="_blank">mscurtescu@google.com</a>>> wrote:<br>
><br>
> There were a couple of proposals on how to<br>
distinguish SETs from Id Tokens and Access Tokens in<br>
such a way that naive implementations will not<br>
confuse one for the other and open up security<br>
vulnerabilities.<br>
><br>
> There is also another important requirement: the<br>
SET issuer in some cases must be different from the<br>
"sub" issuer. This is the case of an RP sending SETs<br>
to an IdP.<br>
><br>
> With these requirements in mind I propose the<br>
following:<br>
> - both "sub" and "iss" to be defined at the event<br>
level<br>
> - "iss" at event level and at top SET level can<br>
be different<br>
> - "iss" and "sub" at event level can be different<br>
across events in the same SET<br>
> - "sub" should NOT be present at the top SET<br>
level (this solves the disambiguation), please note<br>
"should" and not "must"<br>
><br>
> This solution also allows different profiles that<br>
define event types to define additional claims<br>
related to sub (like email or phone_number) and<br>
since all these claims will be at the event level<br>
there will be no collisions or ambiguity.<br>
><br>
> Another proposal (which I supported) was to<br>
define a composite "aud" claim. This is not solving<br>
the requirement for a distinct SET issuer. Also,<br>
having the same claim name having different syntax<br>
in different token types could lead to confusion.<br>
><br>
> And yet another proposal was to introduce a new<br>
claim for JWTs that defines a "type". This is not<br>
practical in the short term, and it also is not<br>
solving the distinct issuer requirement, but I think<br>
this is something the JWT group should seriously<br>
consider.<br>
><br>
> Thoughts?<br>
><br>
> Marius<br>
<br>
> _______________________________________________<br>
> Id-event mailing list<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"> >
<a href="mailto:Id-event@ietf.org" target="_blank">Id-event@ietf.org</a> <mailto:<a href="mailto:Id-event@ietf.org" target="_blank">Id-event@ietf.org</a>><br>
><br>
<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=JmuutBx4DAPp74AULcx2I_jvgXzua6miRiHqWgfxqmg&s=5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhxWI&e=" target="_blank">
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=JmuutBx4DAPp74AULcx2I_jvgXzua6miRiHqWgfxqmg&s=5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhxWI&e=</a><br>
<br>
_______________________________________________<br>
Id-event mailing list<br>
<a href="mailto:Id-event@ietf.org" target="_blank">Id-event@ietf.org</a> <mailto:<a href="mailto:Id-event@ietf.org" target="_blank">Id-event@ietf.org</a>><br>
<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Uslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=P7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSWWs&e=" target="_blank">
https://www.ietf.org/mailman/listinfo/id-event</a><br>
<br>
_______________________________________________<br>
Id-event mailing list<br>
<a href="mailto:Id-event@ietf.org" target="_blank">Id-event@ietf.org</a> <mailto:<a href="mailto:Id-event@ietf.org" target="_blank">Id-event@ietf.org</a>><br>
<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Uslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=P7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSWWs&e=" target="_blank">
https://www.ietf.org/mailman/listinfo/id-event</a><br>
<br>
-- <br>
Adam Dawes | Sr. Product Manager |<a href="mailto:adawes@google.com" target="_blank">adawes@google.com</a><br>
<mailto:<a href="mailto:adawes@google.com" target="_blank">adawes@google.com</a>> |<a href="tel:%2B1%20650-214-2410" target="_blank">+1 650-214-2410</a><br>
<<a href="tel:%28650%29%20214-2410" target="_blank">tel:(650)%20214-2410</a>><br>
<br>
_______________________________________________<br>
Id-event mailing list<br>
<a href="mailto:Id-event@ietf.org" target="_blank">Id-event@ietf.org</a> <mailto:<a href="mailto:Id-event@ietf.org" target="_blank">Id-event@ietf.org</a>><br>
<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Uslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=P7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSWWs&e=" target="_blank">
https://www.ietf.org/mailman/listinfo/id-event</a><br>
<br>
-- <br>
Subscribe to the HARDTWARE <<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__hardtware.com_&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Uslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=i75Uw8aehYvlpIZNL7NxqGxhh1TOrQOUX2XMYBerV80&e=" target="_blank">http://hardtware.com/</a>>
mail list to<br>
learn about projects I am working on!<br>
<br>
<br>
<br>
-- <br>
<br>
Subscribe to the HARDTWARE <<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__hardtware.com_&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Uslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=i75Uw8aehYvlpIZNL7NxqGxhh1TOrQOUX2XMYBerV80&e=" target="_blank">http://hardtware.com/</a>>
mail list to learn about projects I am working on!<br>
<br>
<br>
<br>
_______________________________________________<br>
Id-event mailing list<br>
<a href="mailto:Id-event@ietf.org" target="_blank">Id-event@ietf.org</a><br>
<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Uslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=P7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSWWs&e=" target="_blank">https://www.ietf.org/mailman/listinfo/id-event</a><o:p></o:p></p>
</blockquote>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><br>
_______________________________________________<br>
Id-event mailing list<br>
<a href="mailto:Id-event@ietf.org" target="_blank">Id-event@ietf.org</a><br>
<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Uslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=P7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSWWs&e=" target="_blank">https://www.ietf.org/mailman/listinfo/id-event</a><o:p></o:p></p>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">_______________________________________________<br>
Id-event mailing list<br>
<a href="mailto:Id-event@ietf.org" target="_blank">Id-event@ietf.org</a><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Uslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=P7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSWWs&e=" target="_blank">https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Uslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=P7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSWWs&e=</a>
<o:p></o:p></p>
</div>
</blockquote>
</div>
</blockquote>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">_______________________________________________<br>
Id-event mailing list<br>
<a href="mailto:Id-event@ietf.org" target="_blank">Id-event@ietf.org</a><br>
<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=v4DwjKKsJwoRsAumAL_W7MPPBf0cjsWUW5s3v4G5rhw&s=liaCb6cm5JZnJOCt7UDHOqHgigErF0T-BysT-EdAHSk&e=" target="_blank">https://www.ietf.org/mailman/listinfo/id-event</a><o:p></o:p></p>
</div>
</blockquote>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"><br>
<br>
<o:p></o:p></p>
<pre>_______________________________________________<o:p></o:p></pre>
<pre>Id-event mailing list<o:p></o:p></pre>
<pre><a href="mailto:Id-event@ietf.org" target="_blank">Id-event@ietf.org</a><o:p></o:p></pre>
<pre><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=v4DwjKKsJwoRsAumAL_W7MPPBf0cjsWUW5s3v4G5rhw&s=liaCb6cm5JZnJOCt7UDHOqHgigErF0T-BysT-EdAHSk&e=" target="_blank">https://www.ietf.org/mailman/listinfo/id-event</a><o:p></o:p></pre>
</blockquote>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div></blockquote></body></html>