<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=utf-8"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 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:12.0pt;
font-family:"Times New Roman","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.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@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><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>John <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I follow you now and I think Mr. Lush’s suggestion would be fruitful and help clarify some of the things I am struggling with at this current point in time.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>“The point is to draw a line and declare the side of the line you are going to solve.” I think that you’ve diagnosed my confusion precisely. I’d like to clearly understand what Consumer Directed means in the context of HEART specifically with regards to the use of confidentiality codes. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Just to be explicit - as I may be off the rails in my understanding already – where we make reference to confidentiality codes I am assuming we are referring to </span><a href="http://hl7-fhir.github.io/v3/ConfidentialityClassification/vs.html">http://hl7-fhir.github.io/v3/ConfidentialityClassification/vs.html</a> <o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Is that a bad inference? My read of the description of these codes seems to indicate that they were devised in relation to the exchange between Covered Entities, right? <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I am assuming that on the RS side these codes would be applied based on policy interpretation of the Covered Entity and what we’ve been talking about is that for consumer directed exchange it is the consumer who would define a rule that said in effect When sharing my PHI with recipient X – the disclosing system can share anything that has a classification code assigned by the CE in (U, L, M, N) but not in (R, V). When sharing with my PCP or consumer app you can share anything that has a classification in (U, L, M, N, R, V).<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I feel like that is a sophomoric understanding but I hope putting it out their as what I am able to understand at this point might be helpful to improving everyone’s understanding.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>An example of where I get confused is when there is a reference to Alice not wanting to share her HIV related PHI. I don’t follow how this approach would get to that level of granularity as the classification system doesn’t differentiate between V’s that are classified that way because it is related to HIV versus other V’s that are classified that way because it relates to domestic violence, for example.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I am not the sharpest knife in the drawer but I really share this in the hopes that it will be helpful in getting clarity around the discussion for others in the same boat as me. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Thank you for your patients.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Aaron<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Aaron Seib, CEO<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>@CaptBlueButton <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> (o) 301-540-2311<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>(m) 301-326-6843<o:p></o:p></span></p><p class=MsoNormal><a href="nate-trust.org"><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;text-decoration:none'><img border=0 width=205 height=48 id="Picture_x0020_1" src="cid:image001.jpg@01D1E7F0.7C588B80"></span></a><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p></o:p></span></p></div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> nlush@lgisoftware.com [mailto:nlush@lgisoftware.com] <br><b>Sent:</b> Wednesday, July 27, 2016 7:41 AM<br><b>To:</b> John Moehrke<br><b>Cc:</b> Aaron Seib; HEART List<br><b>Subject:</b> Re: [Openid-specs-heart] Resources vs Resource sets<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><pre>Yes John<br>Perhaps heart could specify the objectives - I could write the first pass if you like<br>Then FHIR group can explain the best way to achieve- hopefully using standards already specified.<br><br>On 2016-07-26 20:39, John Moehrke wrote:<o:p></o:p></pre><pre>> Aaron <o:p></o:p></pre><pre>> <o:p></o:p></pre><pre>> My point with "magic" is to clearly say there is a big problem to<o:p></o:p></pre><pre>> solve, but to say this problem is not what HEART should focus on.<o:p></o:p></pre><pre>> Trying to solve both is what is causing lots of churn, and keeping<o:p></o:p></pre><pre>> progress from happening. <o:p></o:p></pre><pre>> <o:p></o:p></pre><pre>> DS4P is one solution to magic. So is total control by the patient...<o:p></o:p></pre><pre>> That is when the patient totally controls the RS they can put tags on<o:p></o:p></pre><pre>> themselves. A UI by the RS might be offered too, for example my doctor<o:p></o:p></pre><pre>> gives me this kind of control through their patient portal... Many<o:p></o:p></pre><pre>> other solutions are possible. ... <o:p></o:p></pre><pre>> <o:p></o:p></pre><pre>> The point is to draw a line and declare the side of the line you are<o:p></o:p></pre><pre>> going to solve. The other side is a dependency... <o:p></o:p></pre><pre>> <o:p></o:p></pre><pre>> John <o:p></o:p></pre><pre>> <o:p></o:p></pre><pre>> On Jul 26, 2016 4:28 PM, "Aaron Seib" <<a href="mailto:aaron.seib@nate-trust.org">aaron.seib@nate-trust.org</a>><o:p></o:p></pre><pre>> wrote:<o:p></o:p></pre><pre>> <o:p></o:p></pre><pre>>> I am getting foggy on my understanding of where things are heading.<o:p></o:p></pre><pre>>> I follow the notion that magic will happen on the resource server<o:p></o:p></pre><pre>>> side that will tag data using the confidentiality codes. What I<o:p></o:p></pre><pre>>> don’t follow is who does the coding for that informs this magic on<o:p></o:p></pre><pre>>> how it should work?<o:p></o:p></pre><pre>>><o:p> </o:p></pre><pre>>> It may be a sin amongst this crowd but I am thinking of how DS4P is<o:p></o:p></pre><pre>>> designed. There is a code set that gets populated by some<o:p></o:p></pre><pre>>> “authority”” and the software says – oh this code is found<o:p></o:p></pre><pre>>> in my table of HIV related codes and I tag it as HIV.<o:p></o:p></pre><pre>>><o:p> </o:p></pre><pre>>> For me the entire DS4p scheme falls down because no one has the<o:p></o:p></pre><pre>>> authority to say if you populate your Code sets with these values<o:p></o:p></pre><pre>>> then you follow the clients preference you are in a safe harbor and<o:p></o:p></pre><pre>>> no one can ding you for sharing when you shouldn’t.<o:p></o:p></pre><pre>>><o:p> </o:p></pre><pre>>> John – where you say this should include the patient UX am I to<o:p></o:p></pre><pre>>> understand that for a given code set the every patient will have the<o:p></o:p></pre><pre>>> opportunity to configure what is in that code set of things that get<o:p></o:p></pre><pre>>> tagged with a confidentiality code?<o:p></o:p></pre><pre>>><o:p> </o:p></pre><pre>>> I think that is an improvement over DS4P but it still hinges on the<o:p></o:p></pre><pre>>> question – am I as the RS disclosing a patient’s data doing so<o:p></o:p></pre><pre>>> in a safe harbor if I allow the patient to customize what they<o:p></o:p></pre><pre>>> consider sensitive or not?<o:p></o:p></pre><pre>>><o:p> </o:p></pre><pre>>> Or is that the bit of Harry Potter magic that takes place? Or<o:p></o:p></pre><pre>>> should we be explicit and say that it is another assumption about<o:p></o:p></pre><pre>>> the CEs in the role of discloser being compliant if they allow the<o:p></o:p></pre><pre>>> patient to configure the LOV to aligg with their own sensitivities?<o:p></o:p></pre><pre>>><o:p> </o:p></pre><pre>>> Aaron Seib, CEO<o:p></o:p></pre><pre>>><o:p> </o:p></pre><pre>>> @CaptBlueButton<o:p></o:p></pre><pre>>><o:p> </o:p></pre><pre>>> (o) 301-540-2311 [1]<o:p></o:p></pre><pre>>><o:p> </o:p></pre><pre>>> (m) 301-326-6843 [2]<o:p></o:p></pre><pre>>><o:p> </o:p></pre><pre>>> [3]<o:p></o:p></pre><pre>>><o:p> </o:p></pre><pre>>> FROM: Openid-specs-heart<o:p></o:p></pre><pre>>> [<a href="mailto:openid-specs-heart-bounces@lists.openid.net">mailto:openid-specs-heart-bounces@lists.openid.net</a>] ON BEHALF OF<o:p></o:p></pre><pre>>> John Moehrke<o:p></o:p></pre><pre>>> SENT: Tuesday, July 26, 2016 4:36 PM<o:p></o:p></pre><pre>>> TO: Eve Maler<o:p></o:p></pre><pre>>> CC: HEART List<o:p></o:p></pre><pre>>> SUBJECT: Re: [Openid-specs-heart] Resources vs Resource sets<o:p></o:p></pre><pre>>><o:p> </o:p></pre><pre>>> So. I think best step forward is to say that some magic will happen<o:p></o:p></pre><pre>>> on the resource server side that will tag data using the<o:p></o:p></pre><pre>>> _confidentiality codes. This should include patient UX that aids<o:p></o:p></pre><pre>>> with this setting. Yes it is known today this is poorly done.<o:p></o:p></pre><pre>>> Default is N when it is not set.<o:p></o:p></pre><pre>>><o:p> </o:p></pre><pre>>> But setting the tags on the RS is not in HEART scope. It is a<o:p></o:p></pre><pre>>> precondition.<o:p></o:p></pre><pre>>><o:p> </o:p></pre><pre>>> UMA will control authorization to the various _confidentiality<o:p></o:p></pre><pre>>> levels.<o:p></o:p></pre><pre>>><o:p> </o:p></pre><pre>>> UMA can also control resource types.<o:p></o:p></pre><pre>>><o:p> </o:p></pre><pre>>> UMA can also control specific instances of a resource.<o:p></o:p></pre><pre>>><o:p> </o:p></pre><pre>>> Nice clean separation.<o:p></o:p></pre><pre>>><o:p> </o:p></pre><pre>>> John<o:p></o:p></pre><pre>>><o:p> </o:p></pre><pre>>> On Jul 26, 2016 2:56 PM, "Eve Maler" <<a href="mailto:eve.maler@forgerock.com">eve.maler@forgerock.com</a>><o:p></o:p></pre><pre>>> wrote:<o:p></o:p></pre><pre>>><o:p> </o:p></pre><pre>>> No, sorry, I meant UMA resource set types -- semantic types, not<o:p></o:p></pre><pre>>> security labels. Yikes.<o:p></o:p></pre><pre>>><o:p> </o:p></pre><pre>>><o:p> </o:p></pre><pre>> <a href="https://docs.kantarainitiative.org/uma/rec-oauth-resource-reg-v1_0_1.html#resource-set-desc">https://docs.kantarainitiative.org/uma/rec-oauth-resource-reg-v1_0_1.html#resource-set-desc</a><o:p></o:p></pre><pre>>> [4]<o:p></o:p></pre><pre>>><o:p> </o:p></pre><pre>>> In other words, we should be defining a profile that literally<o:p></o:p></pre><pre>>> standardizes UMA resource set types, because that's the only thing<o:p></o:p></pre><pre>>> in UMA that makes sense to standardize.<o:p></o:p></pre><pre>>><o:p> </o:p></pre><pre>>> I promise never to leave off a qualifying name again, cross my<o:p></o:p></pre><pre>>> heart. (Uh, no pun intended.)<o:p></o:p></pre><pre>>><o:p> </o:p></pre><pre>>> Eve Maler<o:p></o:p></pre><pre>>> ForgeRock Office of the CTO | VP Innovation & Emerging Technology<o:p></o:p></pre><pre>>> Cell +1 425.345.6756 [5] | Skype: xmlgrrl | Twitter: @xmlgrrl<o:p></o:p></pre><pre>>> FORGEROCK SUMMITS AND UNSUMMITS are coming to [6] SYDNEY, LONDON,<o:p></o:p></pre><pre>>> AND PARIS!<o:p></o:p></pre><pre>>><o:p> </o:p></pre><pre>>> On Tue, Jul 26, 2016 at 12:26 PM, John Moehrke<o:p></o:p></pre><pre>>> <<a href="mailto:johnmoehrke@gmail.com">johnmoehrke@gmail.com</a>> wrote:<o:p></o:p></pre><pre>>><o:p> </o:p></pre><pre>>> You are reinventing the securityLabels solution that already exists<o:p></o:p></pre><pre>>> and that I have recommended. It is frustrating that this committee<o:p></o:p></pre><pre>>> can't focus in what UMA does and leverage the work others have<o:p></o:p></pre><pre>>> already put in place.<o:p></o:p></pre><pre>>><o:p> </o:p></pre><pre>>> John<o:p></o:p></pre><pre>>><o:p> </o:p></pre><pre>>> On Jul 26, 2016 12:06 PM, "Eve Maler" <<a href="mailto:eve.maler@forgerock.com">eve.maler@forgerock.com</a>><o:p></o:p></pre><pre>>> wrote:<o:p></o:p></pre><pre>>><o:p> </o:p></pre><pre>>> If we have Alice check off the FHIR resources she wants to share<o:p></o:p></pre><pre>>> individually and not share them as a prepackaged "first visit"<o:p></o:p></pre><pre>>> bundle, then a number of things get a bit easier for the services<o:p></o:p></pre><pre>>> involved (though the "HIV problem" doesn't get solved).<o:p></o:p></pre><pre>>><o:p> </o:p></pre><pre>>> We can next set about defining UMA resource sets and their attendant<o:p></o:p></pre><pre>>> scopes for that list of FHIR resources. Note that the scopes _can_<o:p></o:p></pre><pre>>> be unique per resource set, but need not be.<o:p></o:p></pre><pre>>><o:p> </o:p></pre><pre>>> I recommend that we plan for these to be profiled UMA resource set<o:p></o:p></pre><pre>>> TYPES. Alice's instance of a medication list type would differ from<o:p></o:p></pre><pre>>> Carol's, which would differ from David's, and so on.<o:p></o:p></pre><pre>>><o:p> </o:p></pre><pre>>> Eve Maler<o:p></o:p></pre><pre>>> ForgeRock Office of the CTO | VP Innovation & Emerging Technology<o:p></o:p></pre><pre>>> Cell +1 425.345.6756 [5] | Skype: xmlgrrl | Twitter: @xmlgrrl<o:p></o:p></pre><pre>>> FORGEROCK SUMMITS AND UNSUMMITS are coming to [6] SYDNEY, LONDON,<o:p></o:p></pre><pre>>> AND PARIS!<o:p></o:p></pre><pre>>><o:p> </o:p></pre><pre>>> On Mon, Jul 25, 2016 at 7:19 PM, Nancy Lush <<a href="mailto:nlush@lgisoftware.com">nlush@lgisoftware.com</a>><o:p></o:p></pre><pre>>> wrote:<o:p></o:p></pre><pre>>><o:p> </o:p></pre><pre>>> Hello all,<o:p></o:p></pre><pre>>><o:p> </o:p></pre><pre>>> My sense is that we want to start with a simple example. Like,<o:p></o:p></pre><pre>>> Alice can choose which resources she wants to share. Those can be<o:p></o:p></pre><pre>>> from the list Debbie displayed today or the list I sent – or<o:p></o:p></pre><pre>>> whatever the final list turns out to be. (The list can be changed<o:p></o:p></pre><pre>>> later.) But that list is a list of ‘FHIR Resources’. Alice can<o:p></o:p></pre><pre>>> choose to share either all, or she can specify which in the list she<o:p></o:p></pre><pre>>> wishes to share. (I think this is consistent with Adrian’s most<o:p></o:p></pre><pre>>> recent ‘b’ point.)<o:p></o:p></pre><pre>>><o:p> </o:p></pre><pre>>> While we can have resource sets, I don’t think we need to confuse<o:p></o:p></pre><pre>>> the conversation with that yet.<o:p></o:p></pre><pre>>><o:p> </o:p></pre><pre>>> Also, we have talked about confidentiality codes and the desire to<o:p></o:p></pre><pre>>> have Alice share her conditions, but exclude her HIV condition. I<o:p></o:p></pre><pre>>> think as a group we would like to be able to do that, but because it<o:p></o:p></pre><pre>>> is confusing it takes us off track. Just temporarily, let’s skip<o:p></o:p></pre><pre>>> that detail.<o:p></o:p></pre><pre>>><o:p> </o:p></pre><pre>>> If we start with Alice’s ability to share the FHIR resources, we<o:p></o:p></pre><pre>>> can work that through the more technical issues, and reach a point<o:p></o:p></pre><pre>>> where we agree. We can then add additional detail on top of that.<o:p></o:p></pre><pre>>><o:p> </o:p></pre><pre>>> As a group we all come from different places, often each of those<o:p></o:p></pre><pre>>> very different places are technical in nature. As a result, one<o:p></o:p></pre><pre>>> term can have different meanings to each individual. I think we<o:p></o:p></pre><pre>>> are close. The next step would be to define the flow for this, then<o:p></o:p></pre><pre>>> bring it back to the team for review.<o:p></o:p></pre><pre>>><o:p> </o:p></pre><pre>>> -Nancy<o:p></o:p></pre><pre>>><o:p> </o:p></pre><pre>>> NANCY LUSH<o:p></o:p></pre><pre>>><o:p> </o:p></pre><pre>>> <a href="mailto:nancy.lush@lgisoftware.com">nancy.lush@lgisoftware.com</a><o:p></o:p></pre><pre>>><o:p> </o:p></pre><pre>>> LUSH GROUP, INC<o:p></o:p></pre><pre>>><o:p> </o:p></pre><pre>>> Office: (401) 423-9111 [7]<o:p></o:p></pre><pre>>><o:p> </o:p></pre><pre>>> 28 Narragansett Ave<o:p></o:p></pre><pre>>><o:p> </o:p></pre><pre>>> PO Box 651<o:p></o:p></pre><pre>>><o:p> </o:p></pre><pre>>> <a href="http://www.lgisoftware.com">www.lgisoftware.com</a> [8]<o:p></o:p></pre><pre>>><o:p> </o:p></pre><pre>>> Cell:(401) 965-9347 [9]<o:p></o:p></pre><pre>>><o:p> </o:p></pre><pre>>> Jamestown, RI 02835<o:p></o:p></pre><pre>>><o:p> </o:p></pre><pre>>> _______________________________________________<o:p></o:p></pre><pre>>> Openid-specs-heart mailing list<o:p></o:p></pre><pre>>> <a href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.openid.net</a><o:p></o:p></pre><pre>>> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a> [10]<o:p></o:p></pre><pre>>><o:p> </o:p></pre><pre>>> _______________________________________________<o:p></o:p></pre><pre>>> Openid-specs-heart mailing list<o:p></o:p></pre><pre>>> <a href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.openid.net</a><o:p></o:p></pre><pre>>> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a> [10]<o:p></o:p></pre><pre>> <o:p></o:p></pre><pre>> <o:p></o:p></pre><pre>> Links:<o:p></o:p></pre><pre>> ------<o:p></o:p></pre><pre>> [1] <a href="tel:301-540-2311">tel:301-540-2311</a><o:p></o:p></pre><pre>> [2] <a href="tel:301-326-6843">tel:301-326-6843</a><o:p></o:p></pre><pre>> [3] <a href="http://nate-trust.org">http://nate-trust.org</a><o:p></o:p></pre><pre>> [4]<o:p></o:p></pre><pre>> <a href="https://docs.kantarainitiative.org/uma/rec-oauth-resource-reg-v1_0_1.html#resource-set-desc">https://docs.kantarainitiative.org/uma/rec-oauth-resource-reg-v1_0_1.html#resource-set-desc</a><o:p></o:p></pre><pre>> [5] <a href="tel:%2B1%20425.345.6756">tel:%2B1%20425.345.6756</a><o:p></o:p></pre><pre>> [6] <a href="http://summits.forgerock.com/">http://summits.forgerock.com/</a><o:p></o:p></pre><pre>> [7] <a href="tel:%28401%29%20423-9111">tel:%28401%29%20423-9111</a><o:p></o:p></pre><pre>> [8] <a href="http://www.lgisoftware.com">http://www.lgisoftware.com</a><o:p></o:p></pre><pre>> [9] <a href="tel:%28401%29%20965-9347">tel:%28401%29%20965-9347</a><o:p></o:p></pre><pre>> [10] <a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><o:p></o:p></pre><pre>> <o:p></o:p></pre><pre>> _______________________________________________<o:p></o:p></pre><pre>> Openid-specs-heart mailing list<o:p></o:p></pre><pre>> <a href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.openid.net</a><o:p></o:p></pre><pre>> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><o:p></o:p></pre></div></body></html>