<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Meant to reply to list...<br><br>Phil</div><div><br>On Mar 6, 2017, at 4:33 PM, Phil Hunt (IDM) <<a href="mailto:phil.hunt@oracle.com">phil.hunt@oracle.com</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div>FWIW. People having very different views on the matter of re-using sub in SETs. Because OIDC uses sub and iss together it creates conflict when RPs issue events (the issuer of the event is not associated with sub). </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Justin also explained (i hope i have this right) on id events list why having iss moving around is complex. He feels embedding sub and iss in the event keeps the event data separate from the set token envelope information. </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);">From my perspective this conflict around iss is difficult to explain well in the set token spec and thus has its own complexity. </span><br><br>That said, to many in oidc making breaking change is always complex! But i would argue backchannel is not final and should not be approved until secevent is done. </div><div id="AppleMailSignature"><br>Phil</div><div><br>On Mar 6, 2017, at 4:08 PM, Mike Jones via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>> wrote:<br><br></div><blockquote type="cite"><div>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<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;}
/* 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:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.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;}
--></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">Spec call notes 6-Mar-17<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Mike Jones<o:p></o:p></p>
<p class="MsoNormal">Brian Campbell<o:p></o:p></p>
<p class="MsoNormal">Edmund Jay<o:p></o:p></p>
<p class="MsoNormal">Rich Levinson<o:p></o:p></p>
<p class="MsoNormal">Nat Sakimura<o:p></o:p></p>
<p class="MsoNormal">John Bradley<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Agenda<o:p></o:p></p>
<p class="MsoNormal"> Discussions about Session State<o:p></o:p></p>
<p class="MsoNormal"> IETF Security Events (secevent) Discussions<o:p></o:p></p>
<p class="MsoNormal"> Threat Document about the Misuse of OAuth<o:p></o:p></p>
<p class="MsoNormal"> Open Issues<o:p></o:p></p>
<p class="MsoNormal"> Next Call<o:p></o:p></p>
<p class="MsoNormal"> RISC Logout Discussions<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Discussions about Session State<o:p></o:p></p>
<p class="MsoNormal"> Rich referred us to Section 3 of Session Management, which defines session_state<o:p></o:p></p>
<p class="MsoNormal"> <a href="http://openid.net/specs/openid-connect-session-1_0.html#CreatingUpdatingSessions">http://openid.net/specs/openid-connect-session-1_0.html#CreatingUpdatingSessions</a><o:p></o:p></p>
<p class="MsoNormal"> One aspect of Rich's question is whether different RP instances share a session_state value<o:p></o:p></p>
<p class="MsoNormal"> We talked about the distinction between local RP session state management (which has no protocol messages)<o:p></o:p></p>
<p class="MsoNormal"> and global session state management, which involves messages between OPs and RPs<o:p></o:p></p>
<p class="MsoNormal"> Rich was confused by the first sentence of Section 3, which talks about how sessions start<o:p></o:p></p>
<p class="MsoNormal"> The session actually starts with actions by the RP, the OP, and then the RP<o:p></o:p></p>
<p class="MsoNormal"> A fresh login can occur either because the user was logged out at the OP or because the RP uses prompt=login<o:p></o:p></p>
<p class="MsoNormal"> Edmund pointed out that the max_age parameter can also be used to trigger a fresh-enough login<o:p></o:p></p>
<p class="MsoNormal"> Rich will write up any places he finds the spec to be ambiguous for the list<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">IETF Security Events (secevent) Discussions<o:p></o:p></p>
<p class="MsoNormal"> There are currently discussions on the <a href="mailto:id-event@ietf.org">id-event@ietf.org</a> mailing list that are pertinent to Back-Channel Logout<o:p></o:p></p>
<p class="MsoNormal"> Subscribe at <a href="https://www.ietf.org/mailman/listinfo/id-event">https://www.ietf.org/mailman/listinfo/id-event</a><o:p></o:p></p>
<p class="MsoNormal"> Some of these are about the format of the Security Event Token (SET)<o:p></o:p></p>
<p class="MsoNormal"> Outcomes of some of these discussions could cause breaking changes relative to Back-Channel Logout<o:p></o:p></p>
<p class="MsoNormal"> For instance, one person is advocating requiring duplicating information in the JWT into the event object<o:p></o:p></p>
<p class="MsoNormal"> This would be a breaking change<o:p></o:p></p>
<p class="MsoNormal"> Some of these outcomes could also unnecessarily make SETs more complicated than they need to be<o:p></o:p></p>
<p class="MsoNormal"> Because we have a dependency on the SET spec, Connect WG members are encouraged to also participate in the SET discussions<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Threat Document about the Misuse of OAuth<o:p></o:p></p>
<p class="MsoNormal"> The article that prompted this discussion is <a href="https://www.blackhat.com/docs/eu-16/materials/eu-16-Yang-Signing-Into-Billion-Mobile-Apps-Effortlessly-With-OAuth20.pdf">https://www.blackhat.com/docs/eu-16/materials/eu-16-Yang-Signing-Into-Billion-Mobile-Apps-Effortlessly-With-OAuth20.pdf</a><o:p></o:p></p>
<p class="MsoNormal"> William doesn't have the bandwidth to lead this. He's willing to review a document if one is written.<o:p></o:p></p>
<p class="MsoNormal"> Nat asked if there are notes about our thoughts on this<o:p></o:p></p>
<p class="MsoNormal"> Mike responded that this came up on about 4 Connect calls - he thinks in December and January<o:p></o:p></p>
<p class="MsoNormal"> The call notes contain a summary of our discussions<o:p></o:p></p>
<p class="MsoNormal"> Nat agreed to look at the call notes to see if there's enough there for someone to start writing this up<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Open Issues<o:p></o:p></p>
<p class="MsoNormal"> There are no new open issues<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Next Call<o:p></o:p></p>
<p class="MsoNormal"> The next call is Thursday, March 16th at 7am Pacific Time<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">RISC Logout Discussions<o:p></o:p></p>
<p class="MsoNormal"> John reports that Adam Dawes was describing an account reset action as part of Google's RISC use cases<o:p></o:p></p>
<p class="MsoNormal"> Possibly because an account was compromised<o:p></o:p></p>
<p class="MsoNormal"> There's a need to get attackers completely out of the account in this case<o:p></o:p></p>
<p class="MsoNormal"> For instance, invalidating all access, refresh, and ID tokens<o:p></o:p></p>
<p class="MsoNormal"> Mike observes that account reset is likely to do some of the same actions as logout but also more<o:p></o:p></p>
<p class="MsoNormal"> For instance, account reset needs to always invalidate logins at native apps that were logged in<o:p></o:p></p>
<p class="MsoNormal"> John believes that this may be a boundary case that Connect wants to also track<o:p></o:p></p>
<p class="MsoNormal"> We should think about whether this is an extension of logout or something distinct<o:p></o:p></p>
</div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>Openid-specs-ab mailing list</span><br><span><a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a></span><br><span><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a></span><br></div></blockquote></div></blockquote></body></html>