<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=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]-->
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal">Spec call notes 20-Mar-17<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">John Bradley<o:p></o:p></p>
<p class="MsoNormal">Phil Hunt<o:p></o:p></p>
<p class="MsoNormal">Mike Jones<o:p></o:p></p>
<p class="MsoNormal">Edmund Jay<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Nat Sakimura and Brian Campbell sent their regrets<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The call had been deleted from the calendar again, which may have resulted in the low attendance<o:p></o:p></p>
<p class="MsoNormal"> Nat restored it to the shared OpenID calendar right before the call<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"> Open Issues<o:p></o:p></p>
<p class="MsoNormal"> Potential confusion between ID Tokens and other JWTs<o:p></o:p></p>
<p class="MsoNormal"> Next Call<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"> Issue #1010: Create a Threat Document about the Misuse of OAuth<o:p></o:p></p>
<p class="MsoNormal"> Nat created a tracking issue to remind us to create this threat document<o:p></o:p></p>
<p class="MsoNormal"> Phil talked about the need for dual audiences in some native app scenarios<o:p></o:p></p>
<p class="MsoNormal"> In some terrible examples, apps were just passing an e-mail address to a server, which performed no validation<o:p></o:p></p>
<p class="MsoNormal"> Mike suggested that we have an ad-hoc discussion about this next week in Chicago<o:p></o:p></p>
<p class="MsoNormal"> We could try to bang out bullet points for a blog post on this topic<o:p></o:p></p>
<p class="MsoNormal"> John said that a symptom of the problem is some developers don't want to have an OAuth AS for their back-end<o:p></o:p></p>
<p class="MsoNormal"> John called the problem "Fake Federation"<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Potential confusion between ID Tokens and other JWTs<o:p></o:p></p>
<p class="MsoNormal"> Phil wanted to raise this issue with the Connect working group<o:p></o:p></p>
<p class="MsoNormal"> John said that for any generic token format, you'll have to decide how to tell one thing from another<o:p></o:p></p>
<p class="MsoNormal"> Phil said that there is no type<o:p></o:p></p>
<p class="MsoNormal"> Phil said that a SET is distinguished by having an "events" claim<o:p></o:p></p>
<p class="MsoNormal"> But this can be ignored<o:p></o:p></p>
<p class="MsoNormal"> There are things that can be done using the audience<o:p></o:p></p>
<p class="MsoNormal"> Phil asked what it means for an event to be expired<o:p></o:p></p>
<p class="MsoNormal"> Phil said that historical statements don't actually expire<o:p></o:p></p>
<p class="MsoNormal"> John said that you want the JWT to expire so you don't have to have an infinite cache<o:p></o:p></p>
<p class="MsoNormal"> Phil said that "exp" is to be avoided in SETs to avoid confusion between SETs and access tokens<o:p></o:p></p>
<p class="MsoNormal"> John said that this is problematic because then you don't know when you can evict the JWT from a cache<o:p></o:p></p>
<p class="MsoNormal"> John said that if you remove token lifetime, you will eventually regret it<o:p></o:p></p>
<p class="MsoNormal"> It's really about cache control - how long you look for duplicate "jti" values<o:p></o:p></p>
<p class="MsoNormal"> Mike pointed out that, as was said on the just-finished RISC call, SET design should primarily happen in the IETF SecEvent WG<o:p></o:p></p>
<p class="MsoNormal"> That way, all the SecEvent WG members can participate in the discussions<o:p></o:p></p>
<p class="MsoNormal"> Mike said that confusion between ID Tokens and SETs isn't possible in practice<o:p></o:p></p>
<p class="MsoNormal"> A SET doesn't have a nonce, which ID Tokens for all but response_type=code must<o:p></o:p></p>
<p class="MsoNormal"> For response_type=code, a SET wouldn't be returned as an id_token value by the Token Endpoint<o:p></o:p></p>
<p class="MsoNormal"> Mike said that distinguishing between SETs and access tokens should be discussed at IETF<o:p></o:p></p>
<p class="MsoNormal"> A problem is that OAuth says nothing about access token contents<o:p></o:p></p>
<p class="MsoNormal"> Therefore, to even have that discussion, we'd have to start making assumptions about the contents of JWT access tokens<o:p></o:p></p>
<p class="MsoNormal"> John said that using different audiences for different protocols is a security best practice that probably applies here<o:p></o:p></p>
<p class="MsoNormal"> John said that clients don't currently publish identifiers for themselves, other than the client ID<o:p></o:p></p>
<p class="MsoNormal"> He said that that's probably a mistake<o:p></o:p></p>
<p class="MsoNormal"> Some use cases want an identifier that's dereferenceable<o:p></o:p></p>
<p class="MsoNormal"> John then realized that the sector identifier URI is actually such as thing<o:p></o:p></p>
<p class="MsoNormal"> Mike asked whether Roland's federation spec has a dereferenceable client identifier<o:p></o:p></p>
<p class="MsoNormal"> John thinks that it may have dereferenceable client URLs<o:p></o:p></p>
<p class="MsoNormal"> John said that having an identifier that's verifiable and not just self-asserted has proven valuable for the Connect issuer<o:p></o:p></p>
<p class="MsoNormal"> We may want to do that for other participants<o:p></o:p></p>
<p class="MsoNormal"> We can talk about this (and many other things!) in Chicago next week<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 was scheduled for Thursday, March 30th at 7am Pacific Time<o:p></o:p></p>
<p class="MsoNormal"> We decided to cancel that one because of IETF meeting<o:p></o:p></p>
<p class="MsoNormal"> The next call will be in two weeks at 4pm Pacific Time on Monday, April 3rd<o:p></o:p></p>
</div>
</body>
</html>