<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">You don’t have to do these checks, really, but they can be useful. And in fact if you already know which introspection endpoint to call (because you’ve been configured with that and it’s non-dynamic or you can figure it out from some other context like the specific resource set configuration in UMA) then you don’t need to parse the JWT at all and can just treat it as an opaque blob at the RS. That part of the beauty of having both solutions available in parallel. Most commonly, an RS will either parse the token directly or call the introspection endpoint, depending on the qualities of the RS. Different RS’s will have different things they care about and we want to give them choice. Interestingly, several folks have come along and said “why do we need JWT I have introspection!” as well as “why do we need introspection I have JWT!”, all depending on the nature of the RS they were working on. </div><div class=""><br class=""></div>But you can optimize a little in an informed way if you use both: you do it so you know whether or not to follow the link to the introspection endpoint in the first place. You’ve probably cached the key and a signature check is a reasonably cheap local operation. If it can save you a network roundtrip, you might as well. The argument can be made for checking expiration first, too.<div class=""><br class=""></div><div class="">All of this puts extra requirements on the AS more than the rest of the system, and that’s the right place to have that particular burden.<br class=""><div class=""><br class=""></div><div class=""> — Justin</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Oct 15, 2015, at 4:18 PM, Vivek Biswas <<a href="mailto:vivek_biswas@yahoo.com" class="">vivek_biswas@yahoo.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div class=""><div style="background-color: rgb(255, 255, 255); font-family: verdana, helvetica, sans-serif; font-size: 16px;" class=""><div id="yui_3_16_0_1_1444862318470_23355" class=""><span id="yui_3_16_0_1_1444862318470_23364" class="">Hi Justin,</span></div><div id="yui_3_16_0_1_1444862318470_23355" class=""><span class=""><br class=""></span></div><div id="yui_3_16_0_1_1444862318470_23355" class=""> Treating your sequence of action(ignoring adding my 2 steps) as the Use case of delegating the validation of token to the introspection endpoint.</div><div id="yui_3_16_0_1_1444862318470_23355" class=""><br class=""></div><div id="yui_3_16_0_1_1444862318470_23355" class=""> In that particular use-case, why are we validating the JWT token signature i.e., </div><div id="yui_3_16_0_1_1444862318470_23355" dir="ltr" class="">Step no. 3: "<span style="font-family: Calibri, sans-serif; font-size: 14px;" id="yui_3_16_0_1_1444862318470_23698" class="">RS pulls the public key of AS and checks signature".</span></div><div id="yui_3_16_0_1_1444862318470_23355" dir="ltr" class=""><span style="font-family: Calibri, sans-serif; font-size: 14px;" class=""><br class=""></span></div><div id="yui_3_16_0_1_1444862318470_23355" dir="ltr" class="">The introspection endpoint already has the public key and it can very well perform validation of the signature and other JWT related validation enforcement.</div><div id="yui_3_16_0_1_1444862318470_23355" dir="ltr" class=""><br class=""></div><div class="" dir="ltr" id="yiv8983390045yui_3_16_0_1_1444841252567_18299"><span class="" id="yiv8983390045yui_3_16_0_1_1444841252567_17702">Cheers</span></div><div class="" dir="ltr" id="yiv8983390045yui_3_16_0_1_1444841252567_18300"><span class="" id="yiv8983390045yui_3_16_0_1_1444841252567_17702">Vivek Biswas, CISSP<br clear="none" class="" id="yui_3_16_0_1_1444862318470_24073"></span></div><div id="yui_3_16_0_1_1444862318470_23355" dir="ltr" class=""></div><div class="" id="yiv8983390045yui_3_16_0_1_1444841252567_17910"><span class="" id="yiv8983390045yui_3_16_0_1_1444841252567_17702"></span></div><div class=""></div><div class="" dir="ltr" id="yiv8983390045yui_3_16_0_1_1444841252567_18330" style="text-align: start; font-family: verdana, helvetica, sans-serif; font-size: 16px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 1; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="" id="yiv8983390045yui_3_16_0_1_1444841252567_17702"><a rel="nofollow" shape="rect" class="" target="_blank" href="http://www.linkedin.com/in/vivekbiswas" id="yui_3_16_0_1_1444862318470_23679" style="margin: 0px; padding: 0px; text-decoration: underline !important; color: blue; outline: none; cursor: text !important; background: transparent;">www.linkedin.com/in/vivekbiswas</a><br clear="none" class="" id="yui_3_16_0_1_1444862318470_24080"></span></div><div id="yui_3_16_0_1_1444862318470_23355" dir="ltr" class=""><br class=""></div><div id="yui_3_16_0_1_1444862318470_23355" dir="ltr" class=""><br class=""></div><div id="yui_3_16_0_1_1444862318470_23355" dir="ltr" class=""><br class=""></div><div id="yui_3_16_0_1_1444862318470_23355" dir="ltr" class=""><br class=""></div><br class=""> <div style="font-family: verdana, helvetica, sans-serif; font-size: 16px;" id="yui_3_16_0_1_1444862318470_23348" class=""> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;" id="yui_3_16_0_1_1444862318470_23347" class=""> <div dir="ltr" id="yui_3_16_0_1_1444862318470_23363" class=""> <hr size="1" id="yui_3_16_0_1_1444862318470_23580" class=""> <font size="2" face="Arial" id="yui_3_16_0_1_1444862318470_23362" class=""> <b id="yui_3_16_0_1_1444862318470_23479" class=""><span style="font-weight:bold;" id="yui_3_16_0_1_1444862318470_23478" class="">From:</span></b> Justin Richer <<a href="mailto:jricher@mit.edu" class="">jricher@mit.edu</a>><br class=""> <b class=""><span style="font-weight: bold;" class="">To:</span></b> Vivek Biswas <<a href="mailto:vivek_biswas@yahoo.com" class="">vivek_biswas@yahoo.com</a>> <br class=""><b class=""><span style="font-weight: bold;" class="">Cc:</span></b> "<a href="mailto:openid-specs-heart@lists.openid.net" class="">openid-specs-heart@lists.openid.net</a>" <<a href="mailto:openid-specs-heart@lists.openid.net" class="">openid-specs-heart@lists.openid.net</a>> <br class=""> <b class=""><span style="font-weight: bold;" class="">Sent:</span></b> Thursday, October 15, 2015 1:04 PM<br class=""> <b class=""><span style="font-weight: bold;" class="">Subject:</span></b> Re: [Openid-specs-heart] Draft HEART Meeting Notes 2015-10-13<br class=""> </font> </div> <div class="y_msg_container" id="yui_3_16_0_1_1444862318470_23346"><br class=""><div id="yiv8983390045" class=""><div id="yui_3_16_0_1_1444862318470_23345" class="">Well you can do those last two steps if you want, and you’ll definitely want to if all you’re doing is checking the JWT itself, but they’re not really necessary if you’re calling the introspection endpoint as well. The results of the introspection call will tell you if the token is still valid and what kinds of claims are attached to the token. You can always do these in addition to the other processing, of course, but they’re belt-and-suspenders redundant.<div class="yiv8983390045"><br clear="none" class="yiv8983390045"></div><div class="yiv8983390045" id="yui_3_16_0_1_1444862318470_23344">Where the real value of using these two together comes is in cross-domain interoperability of systems. The JWT itself carries enough to bootstrap the process, and possibly enough to cause the RS to say “hey that works for me” and move on with life. The introspection call adds liveness and extensible information to this model in a service approach. Can you use them separately, even if they’re both there? Of course! Will it be different if you use them together? Probably. </div><div class="yiv8983390045" id="yui_3_16_0_1_1444862318470_24082"><br clear="none" class="yiv8983390045"></div><div class="yiv8983390045"> — Justin</div><div class="qtdSeparateBR"><br class=""><br class=""></div><div class="yiv8983390045yqt7670552859" id="yiv8983390045yqt59609"><div class="yiv8983390045" id="yui_3_16_0_1_1444862318470_23359"><br clear="none" class="yiv8983390045"><div id="yui_3_16_0_1_1444862318470_23638" class=""><blockquote class="yiv8983390045" type="cite" id="yui_3_16_0_1_1444862318470_23637"><div class="yiv8983390045">On Oct 15, 2015, at 12:44 PM, Vivek Biswas <<a rel="nofollow" shape="rect" class="yiv8983390045" ymailto="mailto:vivek_biswas@yahoo.com" target="_blank" href="mailto:vivek_biswas@yahoo.com">vivek_biswas@yahoo.com</a>> wrote:</div><br clear="none" class="yiv8983390045Apple-interchange-newline"><div class="yiv8983390045">
</div></blockquote></div></div></div></div><div class="yiv8983390045yqt7670552859" id="yiv8983390045yqt43799"><div id="yui_3_16_0_1_1444862318470_23583" class=""><div class="yiv8983390045" id="yui_3_16_0_1_1444862318470_23582"><div class="yiv8983390045" style="background-color:rgb(255, 255, 255);font-family:verdana, helvetica, sans-serif;font-size:16px;" id="yui_3_16_0_1_1444862318470_23581"><div class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_17677"><span class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_17702">Hi Justin,<br clear="none" class="yiv8983390045"></span></div><div class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_17704"><span class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_17702"><br clear="none" class="yiv8983390045"></span></div><div class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_17734"><span class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_17702">That's a real nice sequence of actions list.</span></div><div class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_18003"><br clear="none" class="yiv8983390045"><span class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_17702"></span></div><div class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_18002"><span class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_17702">I would like to add few more points to it.</span></div><div class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_18001"><br clear="none" class="yiv8983390045" id="yui_3_16_0_1_1444862318470_23681"><span class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_17702"></span></div><div class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_18000"><span class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_17702">5. Validate if JWT token expiration to see if the token is still valid.</span></div><div class="yiv8983390045" dir="ltr" id="yiv8983390045yui_3_16_0_1_1444841252567_17911"><span class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_17702">6. Validate mandatory claims to be fulfilled. [ I come from OASIS SAML and XACML background for healthcare. In that we have used a OASIS XACML <b class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_18032">XSPA(</b></span><font class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_18184" size="2">Cross-Enterprise Security and Privacy Authorization)</font></div><div class="yiv8983390045" dir="ltr" id="yiv8983390045yui_3_16_0_1_1444841252567_17911"><span class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_17702"> profile to enforce mandatory and optional set of claims for a policy]</span></div><div class="yiv8983390045" dir="ltr" id="yiv8983390045yui_3_16_0_1_1444841252567_18270"><br clear="none" class="yiv8983390045"><span class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_17702"></span></div><div class="yiv8983390045" dir="ltr" id="yiv8983390045yui_3_16_0_1_1444841252567_18299"><span class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_17702">Cheers</span></div><div class="yiv8983390045" dir="ltr" id="yiv8983390045yui_3_16_0_1_1444841252567_18300"><span class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_17702">Vivek Biswas, CISSP<br clear="none" class="yiv8983390045"></span></div><div class="yiv8983390045" dir="ltr" id="yiv8983390045yui_3_16_0_1_1444841252567_18330"><span class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_17702"><a rel="nofollow" shape="rect" class="yiv8983390045" target="_blank" href="http://www.linkedin.com/in/vivekbiswas" id="yui_3_16_0_1_1444862318470_23679">www.linkedin.com/in/vivekbiswas</a><br clear="none" class="yiv8983390045"></span></div><div class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_17910"><span class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_17702"></span></div><br clear="none" class="yiv8983390045"> <div class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_17699" style="font-family:verdana, helvetica, sans-serif;font-size:16px;"> <div class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_17698" style="font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px;"> <div class="yiv8983390045" dir="ltr" id="yiv8983390045yui_3_16_0_1_1444841252567_17701"> <hr class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_17700" size="1"> <font class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_17735" face="Arial" size="2"> <b class="yiv8983390045"><span class="yiv8983390045" style="font-weight:bold;">From:</span></b> Justin Richer <<a rel="nofollow" shape="rect" class="yiv8983390045" ymailto="mailto:jricher@MIT.EDU" target="_blank" href="mailto:jricher@MIT.EDU" id="yui_3_16_0_1_1444862318470_24065">jricher@MIT.EDU</a>><br clear="none" class="yiv8983390045"> <b class="yiv8983390045"><span class="yiv8983390045" style="font-weight:bold;">To:</span></b> <a rel="nofollow" shape="rect" class="yiv8983390045" ymailto="mailto:openid-specs-heart@lists.openid.net" target="_blank" href="mailto:openid-specs-heart@lists.openid.net" id="yui_3_16_0_1_1444862318470_24064">openid-specs-heart@lists.openid.net</a> <br clear="none" class="yiv8983390045"> <b class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_18334"><span class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_18333" style="font-weight:bold;">Sent:</span></b> Thursday, October 15, 2015 9:24 AM<br clear="none" class="yiv8983390045"> <b class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_18332"><span class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_18331" style="font-weight:bold;">Subject:</span></b> [Openid-specs-heart] Fwd: Draft HEART Meeting Notes 2015-10-13<br clear="none" class="yiv8983390045"> </font> </div> <div class="yiv8983390045y_msg_container" id="yiv8983390045yui_3_16_0_1_1444841252567_17697"><br clear="none" class="yiv8983390045"><div class="yiv8983390045" id="yiv8983390045"><div class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_17696">Forwarding the off-list conversation that somehow got the “-bounces” address CC’d instead of the real list.<div class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_17867"><br clear="none" class="yiv8983390045"></div><div class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_17695"> — Justin<br clear="none" class="yiv8983390045"><div class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_17694"><br clear="none" class="yiv8983390045"><blockquote class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_17693" type="cite"><div class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_17737">Begin forwarded message:</div><br clear="none" class="yiv8983390045Apple-interchange-newline"><div class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_17739" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;"><span class="yiv8983390045" style="font-family:-webkit-system-font, Helvetica Neue, Helvetica, sans-serif;"><b class="yiv8983390045">From: </b></span><span class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_17738" style="font-family:-webkit-system-font, Helvetica Neue, Helvetica, sans-serif;">Dale Moberg <<a rel="nofollow" shape="rect" class="yiv8983390045" ymailto="mailto:dale.moberg@orionhealth.com" target="_blank" href="mailto:dale.moberg@orionhealth.com">dale.moberg@orionhealth.com</a>><br clear="none" class="yiv8983390045"></span></div><div class="yiv8983390045" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;" id="yui_3_16_0_1_1444862318470_23631"><span class="yiv8983390045" style="font-family:-webkit-system-font, Helvetica Neue, Helvetica, sans-serif;"><b class="yiv8983390045">Subject: </b></span><span class="yiv8983390045" style="font-family:-webkit-system-font, Helvetica Neue, Helvetica, sans-serif;" id="yui_3_16_0_1_1444862318470_23630"><b class="yiv8983390045" id="yui_3_16_0_1_1444862318470_23629">Re: [Openid-specs-heart] Draft HEART Meeting Notes 2015-10-13</b><br clear="none" class="yiv8983390045"></span></div><div class="yiv8983390045" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;"><span class="yiv8983390045" style="font-family:-webkit-system-font, Helvetica Neue, Helvetica, sans-serif;"><b class="yiv8983390045">Date: </b></span><span class="yiv8983390045" style="font-family:-webkit-system-font, Helvetica Neue, Helvetica, sans-serif;">October 15, 2015 at 12:22:53 PM EDT<br clear="none" class="yiv8983390045"></span></div><div class="yiv8983390045" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;"><span class="yiv8983390045" style="font-family:-webkit-system-font, Helvetica Neue, Helvetica, sans-serif;"><b class="yiv8983390045">To: </b></span><span class="yiv8983390045" style="font-family:-webkit-system-font, Helvetica Neue, Helvetica, sans-serif;">Justin Richer <<a rel="nofollow" shape="rect" class="yiv8983390045" ymailto="mailto:jricher@mit.edu" target="_blank" href="mailto:jricher@mit.edu">jricher@mit.edu</a>>, Openid-specs-heart <<a rel="nofollow" shape="rect" class="yiv8983390045" ymailto="mailto:openid-specs-heart-bounces@lists.openid.net" target="_blank" href="mailto:openid-specs-heart-bounces@lists.openid.net">openid-specs-heart-bounces@lists.openid.net</a>><br clear="none" class="yiv8983390045"></span></div><br clear="none" class="yiv8983390045"><div class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_17748">
<div class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_17747" style="word-wrap:break-word;font-size:14px;font-family:Calibri, sans-serif;">
<div class="yiv8983390045">:-) I thought you might have a favorable disposition toward an introspection service!</div>
<div class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_17746"><br clear="none" class="yiv8983390045">
</div>
<span class="yiv8983390045" id="yiv8983390045OLK_SRC_BODY_SECTION">
</span><div class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_17772" style="font-family:Calibri;font-size:11pt;text-align:left;border-width:1pt medium medium;border-style:solid none none;padding:3pt 0in 0in;border-top-color:rgb(181, 196, 223);">
<span class="yiv8983390045" style="font-weight:bold;">From: </span>Justin Richer <<a rel="nofollow" shape="rect" class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_17778" ymailto="mailto:jricher@mit.edu" target="_blank" href="mailto:jricher@mit.edu">jricher@mit.edu</a>><br clear="none" class="yiv8983390045">
<span class="yiv8983390045" style="font-weight:bold;">Date: </span>Thursday, October 15, 2015 at 9:21 AM<br clear="none" class="yiv8983390045">
<span class="yiv8983390045" style="font-weight:bold;">To: </span>Dale Moberg <<a rel="nofollow" shape="rect" class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_17780" ymailto="mailto:dale.moberg@orionhealth.com" target="_blank" href="mailto:dale.moberg@orionhealth.com">dale.moberg@orionhealth.com</a>><br clear="none" class="yiv8983390045">
<span class="yiv8983390045" style="font-weight:bold;">Cc: </span>Openid-specs-heart <<a rel="nofollow" shape="rect" class="yiv8983390045" ymailto="mailto:openid-specs-heart-bounces@lists.openid.net" target="_blank" href="mailto:openid-specs-heart-bounces@lists.openid.net">openid-specs-heart-bounces@lists.openid.net</a>><br clear="none" class="yiv8983390045">
<span class="yiv8983390045" style="font-weight:bold;">Subject: </span>Re: [Openid-specs-heart] Draft HEART Meeting Notes 2015-10-13<br clear="none" class="yiv8983390045">
</div>
<div class="yiv8983390045"><br clear="none" class="yiv8983390045">
</div>
<div class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_17790">
<div class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_17789" style="word-wrap:break-word;">
We’re not favoring JWT over introspection: in fact we’re mandating both simultaneously because the real world needs a balance between approaches. Coupled with the discovery system (also required), you can also use them together very nicely:
<div class="yiv8983390045" id="yui_3_16_0_1_1444862318470_23689"><br clear="none" class="yiv8983390045">
</div>
<div class="yiv8983390045" id="yui_3_16_0_1_1444862318470_23615"> 1: RS gets a token, parses it as a JWT</div>
<div class="yiv8983390045" id="yui_3_16_0_1_1444862318470_23616"> 2: RS reads the issuer, discovers configuration</div>
<div class="yiv8983390045" id="yui_3_16_0_1_1444862318470_23617"> 3: RS pulls the public key of AS and checks signature</div>
<div class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_17788"> 4: RS introspects token at the AS (as just discovered)</div>
<div class="yiv8983390045"><br clear="none" class="yiv8983390045">
</div>
<div class="yiv8983390045">By having both JWT and Introspection lets the RS figure out which model it wants to use, and it can always count on both being available.</div>
<div class="yiv8983390045"><br clear="none" class="yiv8983390045">
</div>
<div class="yiv8983390045">Believe me, I’m actually a rather big fan of the service-based model: <a rel="nofollow" shape="rect" class="yiv8983390045" target="_blank" href="https://tools.ietf.org/html/draft-ietf-oauth-introspection">https://tools.ietf.org/html/draft-ietf-oauth-introspection</a> ;)</div>
<div class="yiv8983390045"><br clear="none" class="yiv8983390045">
</div>
<div class="yiv8983390045"> — Justin</div>
<div class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_17809"><br clear="none" class="yiv8983390045">
<div class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_17808">
<blockquote class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_17807" type="cite">
<div class="yiv8983390045">On Oct 15, 2015, at 11:38 AM, Dale Moberg <<a rel="nofollow" shape="rect" class="yiv8983390045" ymailto="mailto:dale.moberg@orionhealth.com" target="_blank" href="mailto:dale.moberg@orionhealth.com">dale.moberg@orionhealth.com</a>> wrote:</div>
<br clear="none" class="yiv8983390045Apple-interchange-newline">
<div class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_17806">
<div class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_17805" style="word-wrap:break-word;font-size:14px;font-family:Calibri, sans-serif;">
<div class="yiv8983390045">Because I just located the drafts (thanks Justin!) I had missed a lot of what this group has as background context. I will soon find time to look at the drafts more carefully. Are there specific openid connect readings that we are profiling or
adapting in this group? (I am familiar with the core openid connect spec on the oauth2-protected, identity-information service for the (API) client. </div>
<div class="yiv8983390045"><br clear="none" class="yiv8983390045">
</div>
<div class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_17873">I am a bit concerned about using JWT instead of an unpredictable opaque token (with expiration) for access. I suspect this embellishment may be because of the deliberate omission (in core OAuth2) of the communication details between the resource
service/server and the authz & token issuing endpoint server. I have always thought that from a security architecture viewpoint that introspection style services would provide good ways to offload most security checking work at the API endpoints to a scalable
layer of introspection servers. Certainly cloud scalability models seem to favor a service approach, rather than an approach using structured token unpacking, with cryptographic operations and checks. </div>
<div class="yiv8983390045"><br clear="none" class="yiv8983390045">
</div>
<div class="yiv8983390045">Perhaps you would be willing to explain to participants (or me) the case for using JWT in the way that is currently favored in our group? I can then provide my R&D group with the underlying thinking.</div>
<div class="yiv8983390045"><br clear="none" class="yiv8983390045">
</div>
<div class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_17804">I will also continue to think about how to bridge trust between multiple API user security domains with a central shared API server, in its own security domain. That may be an issue to be addressed elsewhere, however.</div>
<div class="yiv8983390045"><br clear="none" class="yiv8983390045">
</div>
<div class="yiv8983390045">Thanks for your response!</div>
<div class="yiv8983390045"><br clear="none" class="yiv8983390045">
</div>
<div class="yiv8983390045">Dale Moberg</div>
<div class="yiv8983390045"><br clear="none" class="yiv8983390045">
</div>
<div class="yiv8983390045"><br clear="none" class="yiv8983390045">
</div>
<div class="yiv8983390045"><br clear="none" class="yiv8983390045">
</div>
<span class="yiv8983390045" id="yiv8983390045OLK_SRC_BODY_SECTION">
</span><div class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_17882" style="font-family:Calibri;font-size:11pt;text-align:left;border-width:1pt medium medium;border-style:solid none none;padding:3pt 0in 0in;border-top-color:rgb(181, 196, 223);">
<span class="yiv8983390045" style="font-weight:bold;">From: </span>Justin Richer <<a rel="nofollow" shape="rect" class="yiv8983390045" ymailto="mailto:jricher@mit.edu" target="_blank" href="mailto:jricher@mit.edu">jricher@mit.edu</a>><br clear="none" class="yiv8983390045">
<span class="yiv8983390045" style="font-weight:bold;">Date: </span>Wednesday, October 14, 2015 at 5:24 PM<br clear="none" class="yiv8983390045">
<span class="yiv8983390045" style="font-weight:bold;">To: </span>Dale Moberg <<a rel="nofollow" shape="rect" class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_17881" ymailto="mailto:dale.moberg@orionhealth.com" target="_blank" href="mailto:dale.moberg@orionhealth.com">dale.moberg@orionhealth.com</a>><br clear="none" class="yiv8983390045">
<span class="yiv8983390045" style="font-weight:bold;">Cc: </span>Sarah Squire <<a rel="nofollow" shape="rect" class="yiv8983390045" ymailto="mailto:sarah@engageidentity.com" target="_blank" href="mailto:sarah@engageidentity.com">sarah@engageidentity.com</a>>, "<a rel="nofollow" shape="rect" class="yiv8983390045" ymailto="mailto:openid-specs-heart@lists.openid.net" target="_blank" href="mailto:openid-specs-heart@lists.openid.net">openid-specs-heart@lists.openid.net</a>" <<a rel="nofollow" shape="rect" class="yiv8983390045" ymailto="mailto:openid-specs-heart@lists.openid.net" target="_blank" href="mailto:openid-specs-heart@lists.openid.net">openid-specs-heart@lists.openid.net</a>><br clear="none" class="yiv8983390045">
<span class="yiv8983390045" style="font-weight:bold;">Subject: </span>Re: [Openid-specs-heart] Draft HEART Meeting Notes 2015-10-13<br clear="none" class="yiv8983390045">
</div>
<div class="yiv8983390045"><br clear="none" class="yiv8983390045">
</div>
<div class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_17908">
<div class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_17907" style="word-wrap:break-word;">
The JWT specified by the HEART OAuth spec is the result of the OAuth process, not the input into it. We’re specifying a JWT as the format of the access token in order to allow interoperability between RS and AS from different vendors and domains. We’re also
mandating support for token introspection for the same reason.
<div class="yiv8983390045"><br clear="none" class="yiv8983390045">
</div>
<div class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_17906">OpenID Connect further specifies JWT as the format for the ID token, which we’re inheriting directly.<br clear="none" class="yiv8983390045">
<div class="yiv8983390045"><br clear="none" class="yiv8983390045">
</div>
<div class="yiv8983390045">We’re not using JWT assertions (RFC7521/7523) directly to get tokens, but we are using JWT assertions in client authentication, as defined in OpenID Connect Core as “private_key_jwt”. This is something we’re not inventing, but mandating (and
describing rationale for) its use. </div>
<div class="yiv8983390045"><br clear="none" class="yiv8983390045">
</div>
<div class="yiv8983390045">There is no fork or clash with other standards.</div>
<div class="yiv8983390045"><br clear="none" class="yiv8983390045">
</div>
<div class="yiv8983390045">We are not inventing any new grant types, but we are specifying that certain kinds of client applications need to use certain grant types.</div>
<div class="yiv8983390045"><br clear="none" class="yiv8983390045">
</div>
<div class="yiv8983390045">Hope this helps,</div>
<div class="yiv8983390045"> — Justin</div>
<div class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_17905"><br clear="none" class="yiv8983390045">
<div class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_17904">
<blockquote class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_17903" type="cite">
<div class="yiv8983390045">On Oct 14, 2015, at 2:53 PM, Dale Moberg <<a rel="nofollow" shape="rect" class="yiv8983390045" ymailto="mailto:dale.moberg@orionhealth.com" target="_blank" href="mailto:dale.moberg@orionhealth.com">dale.moberg@orionhealth.com</a>> wrote:</div>
<br clear="none" class="yiv8983390045Apple-interchange-newline">
<div class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_17902">
<div class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_17901" style="word-wrap:break-word;font-size:14px;font-family:Calibri, sans-serif;">
<div class="yiv8983390045" style="font-family:Calibri, sans-serif;font-size:14px;">Hi HEART people,</div>
<div class="yiv8983390045" style="font-family:Calibri, sans-serif;font-size:14px;"><br clear="none" class="yiv8983390045">
</div>
<div class="yiv8983390045" id="yiv8983390045yui_3_16_0_1_1444841252567_17900" style="font-family:Calibri, sans-serif;font-size:14px;">I am coming out of my mainly listen-mode participation to ask some questions. By way of introduction, I have been involved with the design and specification of inter-organizational security
solutions in the IETF (EDIINT- AS2 for logistics and supply chains), Rosettanet (choreographed XML exchanges for business processes for high-tech), OASIS/UNCEFACT ebXML(same as rosettanet, but for any organizations), W3C (wsdl, ws-policy, ws-splat for rpc/doc/SOA/whatever),
OMG and ISO(Unifi harmonization), UncefactMM/UBL(semantic compositionality models) GS1(EPCIS, IOT) and similar effots. But only recently addressing the healthcare domain with a focus of improving interoperability at both technical (security/protocol/API) and
semantic to promote use of clinical data in Machine Learning models of “actionable information” Enough with the buzz words.</div>
<div class="yiv8983390045" style="font-family:Calibri, sans-serif;font-size:14px;"><br clear="none" class="yiv8983390045">
</div>
<div class="yiv8983390045" style="font-family:Calibri, sans-serif;font-size:14px;"><br clear="none" class="yiv8983390045">
</div>
<div class="yiv8983390045" style="font-family:Calibri, sans-serif;font-size:14px;"><font class="yiv8983390045" face="Calibri,sans-serif">"</font><span class="yiv8983390045" style="font-family:Arial;font-size:15px;line-height:20px;white-space:pre-wrap;">We are not developing a standard.
We are developing </span><font class="yiv8983390045" face="Arial"><span class="yiv8983390045" style="font-size:15px;line-height:20px;white-space:pre-wrap;">a profile of a standard.”</span></font></div>
<div class="yiv8983390045"><font class="yiv8983390045" style="font-family:Calibri, sans-serif;font-size:14px;" face="Arial"><span class="yiv8983390045" style="font-size:15px;line-height:20px;white-space:pre-wrap;">"</span></font><span class="yiv8983390045" style="font-family:Arial;font-size:15px;line-height:20px;white-space:pre-wrap;">HEART
is primarily about user-mediated exchange, </span><span class="yiv8983390045" style="font-family:Arial;font-size:15px;line-height:20px;white-space:pre-wrap;">but we can’t ignore clinical data exchange.</span><font class="yiv8983390045" face="Arial"><span class="yiv8983390045" style="font-size:15px;line-height:20px;white-space:pre-wrap;">”</span></font></div>
<div class="yiv8983390045" style="font-family:Calibri, sans-serif;font-size:14px;"><span class="yiv8983390045" style="font-family:Arial;font-size:15px;line-height:20px;white-space:pre-wrap;"><br clear="none" class="yiv8983390045">
</span></div>
<div class="yiv8983390045"><span class="yiv8983390045" style="font-family:Arial;font-size:15px;line-height:20px;white-space:pre-wrap;">However, it does not seem we are profiling a standard (a relatively straightforward matter of subsetting a specific standard to trim out optionality,
and mandate the functionality organizational groups need, while remainling interoperable and open to multiple implementations), but instead saying how you want to use:</span></div>
<div class="yiv8983390045"><font class="yiv8983390045" face="Arial"><span class="yiv8983390045" style="font-size:15px;line-height:20px;white-space:pre-wrap;">UMA + FHIR + OAuth2 + JWT + ??? —together within
</span></font><span class="yiv8983390045" style="font-size:15px;line-height:20px;white-space:pre-wrap;font-family:Arial;">the registration, delegation, data contribution, and related data sharing scenarios. In other words, you want to build a way to apply several
existing standards and have them work together interoperably (like an IETF applicability statement).</span></div>
<div class="yiv8983390045"><font class="yiv8983390045" face="Arial"><span class="yiv8983390045" style="font-size:15px;line-height:20px;white-space:pre-wrap;"><br clear="none" class="yiv8983390045">
</span></font></div>
<div class="yiv8983390045"><font class="yiv8983390045" face="Arial"><span class="yiv8983390045" style="font-size:15px;line-height:20px;white-space:pre-wrap;">My first question concerns the IETF OAuth group’s RFC 7521 that “…</span></font>provides a framework for the use of assertions with OAuth
2.0 in the form of a new client authentication mechanism and a new authorization grant type.”
<font class="yiv8983390045" face="Arial"><span class="yiv8983390045" style="font-size:16px;"> Is it agreed to include RFC 7521 within our profile? RFC 7523 "</span></font><span class="yiv8983390045" style="font-family:Courier;font-size:small;">JSON Web Token (JWT) Profile
</span><font class="yiv8983390045" face="Courier" size="2">for OAuth 2.0 Client Authentication and Authorization Grants”
</font><font class="yiv8983390045" face="Arial">already specifies a way to use JWT; in my opinion, it would clash with IETF work to fork an alternative approach to using JWT. If you plan to do this, I would be interested in your reasons for doing so.</font></div>
<div class="yiv8983390045"><font class="yiv8983390045" face="Arial"><br clear="none" class="yiv8983390045">
</font></div>
<div class="yiv8983390045"><font class="yiv8983390045" face="Arial">The 7521/7523 profiling approach rapidly cuts down on our scope so that we do not have to worry how to specify using a signed JWT token to get an OAuth2 access token (via the newly defined grant type). If one of the
four previously defined OAuth 2 (RFC 6749) grant types are to be used, we would have to explain what the JWT is doing in the process. All the other grant types involve client ids, secrets, usernames and password credentials in various combinations. Would they
be combined with a JWT? How? Why? This seems to be a lot of effort, and personally I need a little motivation for undertaking trying to work through that amount of complexity.</font></div>
<div class="yiv8983390045"><font class="yiv8983390045" face="Arial"><br clear="none" class="yiv8983390045">
</font></div>
<div class="yiv8983390045">Now you could use those previous kinds of credentials and grant types in contacting a JWT issuing service (call it an “authentication authority”). Is that a step that needs explicit profiling in this group?</div>
<div class="yiv8983390045"><br clear="none" class="yiv8983390045">
</div>
<div class="yiv8983390045">As far as Eve’s design patterns (organizational, role, individual entity), another way of slicing the designs up is by introducing an idea of “organizational or aggregated organizational security domain”</div>
<div class="yiv8983390045">I work for a company that creates “HIEs— health information exchanges” Some of these HIEs span lab organizations, pharmacies, urgent cares, clinics, optometrists, hospitals etc etc.” Some emerging ones span different types of organizations involved
in different aspects of healthcare — notably provider organizations and payer organizations. Each organization has its own security domain, but the HIE normally has a separate security domain. The main security problem is then defining the “trust bridge” allowing
these distinct security domains to share their data, subject to HIPAA and CFR 42 kinds of privacy constraints.</div>
<div class="yiv8983390045"><br clear="none" class="yiv8983390045">
</div>
<div class="yiv8983390045">To me, both the roles and individuals will be in an organizational context. The organizational context is typically identified by DNS domain names, and has a security domain within which credentials are submitted and checked. Typically the individuals
will have an identifier associated with the organization (e.g,, email address) and role(s). When an individual from security domain A wishes to use resources within security domain B, it gets an organizational token (JWT) issued by domain A and then submits
it to domain B, which can authorize access for the individual. This is a hard security problem to get resolved interoperably. Is this “pattern” one that we should profile? If it is I am all in. But if we are only interested in an individual’s capability to
set policy within a specific security domain, the security problem will lack interoperability in emerging data exchanges accessed via APIs (including FHIR dstuX when it emerges).</div>
<div class="yiv8983390045"><br clear="none" class="yiv8983390045">
</div>
<div class="yiv8983390045">Sorry for the detail but I have been as succinct as is consistent with explaining my questions.</div>
<div class="yiv8983390045"><br clear="none" class="yiv8983390045">
</div>
<div class="yiv8983390045">I will attach a diagram I have used to ask this question to Eve Maler (hi Eve!). Hoping to move us forward in getting clear about our profiling activity. I realize this is not a pure waterfall design pattern (use cases driving everying below),
but that is not agile, and we should all be able to be agile as needed.</div>
<div class="yiv8983390045"><br clear="none" class="yiv8983390045">
</div>
<div class="yiv8983390045">Dale Moberg</div>
<div class="yiv8983390045"><br clear="none" class="yiv8983390045">
</div>
<div class="yiv8983390045"><font class="yiv8983390045" face="Arial"><br clear="none" class="yiv8983390045">
</font></div>
<div class="yiv8983390045"><font class="yiv8983390045" face="Arial"><br clear="none" class="yiv8983390045">
</font></div>
<div class="yiv8983390045"><br clear="none" class="yiv8983390045">
</div>
<div class="yiv8983390045"><font class="yiv8983390045" face="Arial"><span class="yiv8983390045" style="font-size:15px;line-height:20px;white-space:pre-wrap;"><br clear="none" class="yiv8983390045">
</span></font></div>
<div class="yiv8983390045"><font class="yiv8983390045" face="Arial"><span class="yiv8983390045" style="font-size:15px;line-height:20px;white-space:pre-wrap;"><br clear="none" class="yiv8983390045">
</span></font></div>
<div class="yiv8983390045"><font class="yiv8983390045" face="Arial"><span class="yiv8983390045" style="font-size:15px;line-height:20px;white-space:pre-wrap;"><br clear="none" class="yiv8983390045">
</span></font></div>
<div class="yiv8983390045"><font class="yiv8983390045" face="Arial"><span class="yiv8983390045" style="font-size:15px;line-height:20px;white-space:pre-wrap;"><br clear="none" class="yiv8983390045">
</span></font></div>
</div>
<span class="yiv8983390045"><DT-FHIRCaseFiveBasics.docx></span>_______________________________________________<br clear="none" class="yiv8983390045">
Openid-specs-heart mailing list<br clear="none" class="yiv8983390045">
<a rel="nofollow" shape="rect" class="yiv8983390045" ymailto="mailto:Openid-specs-heart@lists.openid.net" target="_blank" href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.openid.net</a><br clear="none" class="yiv8983390045">
<a rel="nofollow" shape="rect" class="yiv8983390045" target="_blank" href="http://lists.openid.net/mailman/listinfo/openid-specs-heart">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><br clear="none" class="yiv8983390045">
</div>
</blockquote>
</div>
<br clear="none" class="yiv8983390045">
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br clear="none" class="yiv8983390045">
</div>
</div>
</div>
</div>
</div></blockquote></div><br clear="none" class="yiv8983390045"></div></div></div><br clear="none" class="yiv8983390045">_______________________________________________<br clear="none" class="yiv8983390045">Openid-specs-heart mailing list<br clear="none" class="yiv8983390045"><a rel="nofollow" shape="rect" class="yiv8983390045" ymailto="mailto:Openid-specs-heart@lists.openid.net" target="_blank" href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.openid.net</a><br clear="none" class="yiv8983390045"><a rel="nofollow" shape="rect" class="yiv8983390045" target="_blank" href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" id="yui_3_16_0_1_1444862318470_24129">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><br clear="none" class="yiv8983390045"><br clear="none" class="yiv8983390045"><br clear="none" class="yiv8983390045"></div> </div> </div> </div></div><br clear="none" class="yiv8983390045"></div></div></div><br class=""><br class=""></div> </div> </div> </div></div></div></blockquote></div><br class=""></div></div></body></html>