<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 14 (filtered medium)">
<style><!--
/* Font Definitions */
@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:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
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="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">As discussed during the working group call on Thursday, I received feedback on the current Connect design from a key Microsoft product architect based upon his product’s use cases. The high-order bit in his feedback was that he needs RPs
to be able to access claims without making a second call to Check ID or UserInfo endpoints. Per the discussion on the call, the requirement to be able to access claims without additional round trips seems entirely reasonable and is motivated by real user-interface
latency concerns.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">To accomplish this, all claims would be carried in JWT tokens, which would then be directly used by the RPs. This conflicts with the current design decision that the access token is opaque and that UserInfo claims can only be retrieved
by making a second call to the UserInfo endpoint. I propose that we change that decision before declaring implementer’s drafts.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Specifically, I would require that, in the normal case, the access token is a JWT containing the UserInfo claims (just like the ID Token is a JWT containing the logged-in session claims). If we decide that it’s important to allow some
implementations to use a different token format, that should be the exception, not the default. In that exceptional case, those IdPs must declare in their discovery information that UserInfo claims must be retrieved from the UserInfo endpoint, and cannot
be directly accessed within a JWT access token.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I’d promised on the call to write up this proposed change. This is that write-up. We’ll discuss this on the Monday call.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"> Best wishes,<o:p></o:p></p>
<p class="MsoNormal"> -- Mike<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">P.S. Coincidentally, I also independently received essentially the same feedback from a different product architect yesterday, based upon his review of the specs.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>