<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)"><style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@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;}
/* 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;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.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;}
/* List Definitions */
@list l0
{mso-list-id:2137290314;
mso-list-template-ids:1775295430;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></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'>This amorphous scope could also be represented in FHIR as a ConsentDirective.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><a href="http://hl7-fhir.github.io/consentdirective-consentdirective.html">http://hl7-fhir.github.io/consentdirective-consentdirective.html</a><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'>Sorry that ConsentDirective is such a mess right now. We are trying to resolve open-comments, while also doing design.<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 concept is that we need a resource in FHIR that can capture a complex policy. <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'>Such as: I give my guardian (X) read access to all my health information, except for the records during 1982, and except for records marked with the security-tag==Restricted. I further give Create/Update permission to schedule appointments. I further give Create but not Update permission to write observations. We ‘believe’ we can write these policies using ConsentDirective today…<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'>Once this kind of a policy is registered. Then a reference to that specific instance of a ConsentDirective could be a scope requested… This is not necessarily the vision today, the vision is more that this is rules that the Access Control Decision engine (however implemented) would use to determine if an action is authorized. But Scopes are simply broad requests for a multi-point decision to be made vs point-by-point.<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'>Sorry that I don’t know enough about UMA to help there.<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'>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><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"'> Openid-specs-heart [mailto:openid-specs-heart-bounces@lists.openid.net] <b>On Behalf Of </b>Eve Maler<br><b>Sent:</b> Tuesday, June 16, 2015 12:01 PM<br><b>To:</b> Justin Richer<br><b>Cc:</b> openid-specs-heart@lists.openid.net<br><b>Subject:</b> Re: [Openid-specs-heart] HEART Scopes & Resource Sets<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>The ability in OAuth for a client to request multiple resources and permissions over them seems valuable, of course. Given that "resource set registration" and "permission granting" are distinct activities in UMA, though, I'm reluctant to conflate them for OAuth historical reasons, and would prefer to think about how to solve the problem "correctly" if possible. (Josh, btw, I did give examples of distinct scopes over different resources, e.g., Salesforce's "chatter" scope. This pattern seems pretty common.)<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal>Though it didn't make it into UMA V1.0, the group discussed a pattern where the RS could register multiple permissions vs. just a single one, and there is a communications channel between the client and AS (the request for authorization data at the RPT endpoint) that could be used to convey the client's desires as well. I want to be clear that this is in the realm of potential <b>UMA extensions</b> (e.g., for consideration in V.next) rather than just HEART profiling. But the ease of experimenting with and creating extensions (e.g. adding JSON properties to requests and responses) is one big reason why we felt comfortable wrapping up V1.0 after a fairly lengthy development process.<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>In fact, FWIW, I've been having a discussion with some folks in a different context that looks exactly like "generous resource set/permission registration by the RS at the AS in response to a limited initial access request by a client". So this isn't a totally one-off conversation.<o:p></o:p></p></div></div><div><p class=MsoNormal><br clear=all><o:p></o:p></p><div><div><div><div><div><p><b>Eve Maler<br></b>ForgeRock Office of the CTO | VP Innovation & Emerging Technology<br>Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl<br>Join our <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__forgerock.org_openuma_&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=c5kzzfYQsMqNe16ufsx_ex-37vO5OdZxWdiMY3NLTUw&s=V4ANvo3RiGqeVCqKj2A2X2tAVz5LFrZlDFhG5-Zr44E&e=" target="_blank">ForgeRock.org OpenUMA</a> community!<o:p></o:p></p></div></div></div></div></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>On Tue, Jun 16, 2015 at 7:42 AM, Justin Richer <<a href="mailto:jricher@mit.edu" target="_blank">jricher@mit.edu</a>> wrote:<o:p></o:p></p><div><p class=MsoNormal>Eve,<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>The main difference is that it’s not at all uncommon in the OAuth world to ask for authorization to multiple resources protected by the same AS simultaneously. In fact, this is seen as a *feature* of the OAuth approach, since it’s lower decision overhead for the user (when done right). In that case, if a client asks for “read write delete” scopes of an AS, the AS still needs to know *what* those scopes apply to. Since OAuth doesn’t have any type of resource or audience identifier (a big hole in the spec), this gap has been usually filled by having a scope identify the resource. Note that this is still semantically sensible and doesn’t go against what “scope” is defined as.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>This is where you get the matrix definition. You’ve got some scopes that mean “where can I do things” and others that mean “what can I do there”. I think Josh’s approach of “what.where” is reasonable given this technical constraint, and not without precedent. As far as the AS is concerned, it’s dealing with just strings from the client, but it can still easily make the UX of the authorization page a little smart based on the understood semantics of these well-defined scopes.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal> — Justin<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p><div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><div><div><p class=MsoNormal>On Jun 15, 2015, at 7:44 PM, Eve Maler <<a href="mailto:eve.maler@forgerock.com" target="_blank">eve.maler@forgerock.com</a>> wrote:<o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p></div></div><div><div><div><div><p class=MsoNormal>Hi Josh-- Below...<o:p></o:p></p><div><p class=MsoNormal><br clear=all><o:p></o:p></p><div><div><div><div><div><p><b>Eve Maler<br></b>ForgeRock Office of the CTO | VP Innovation & Emerging Technology<br>Cell <a href="tel:%2B1%20425.345.6756" target="_blank">+1 425.345.6756</a> | Skype: xmlgrrl | Twitter: @xmlgrrl<br>Join our <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__forgerock.org_openuma_&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=c5kzzfYQsMqNe16ufsx_ex-37vO5OdZxWdiMY3NLTUw&s=V4ANvo3RiGqeVCqKj2A2X2tAVz5LFrZlDFhG5-Zr44E&e=" target="_blank">ForgeRock.org OpenUMA</a> community!<o:p></o:p></p></div></div></div></div></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>On Mon, Jun 15, 2015 at 2:24 PM, Josh Mandel <<a href="mailto:Joshua.Mandel@childrens.harvard.edu" target="_blank">Joshua.Mandel@childrens.harvard.edu</a>> wrote:<o:p></o:p></p><div><div><p class=MsoNormal>Hi all,<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I didn't mean to take a hard-line position on today's call about scope definitions! To my mind, our approach to scopes will need to work hand-in-hand with our approach to endpoint (or resource set) discovery -- so I feel a bit awkward discussing scopes here in isolation. But that said, let me see if I can at least highlight the tension that we heard in the past hour's discussion (in a neutral way):<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>---<o:p></o:p></p></div><div><p class=MsoNormal><i>Goal: Whatever the model, we want to support a use case where Alice signs into her resource server and can set some policies in an intuitive way. |She'd see something like (very, very roughly):</i><o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal> My Medications: <o:p></o:p></p></div><div><p class=MsoNormal> * Who can view?<o:p></o:p></p></div><div><p class=MsoNormal> * Who can write new prescriptions?<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>My Step Counts<o:p></o:p></p></div><div><p class=MsoNormal> * Who can view?<o:p></o:p></p></div><div><p class=MsoNormal> * Who can remove?<o:p></o:p></p></div><div><p class=MsoNormal>---<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>The question is about how this works under the hood. I think we were discussing two models:<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><b>Model 1: The "UMA-First" approach</b><o:p></o:p></p></div><div><p class=MsoNormal><i>We have a resource set like "Alice's Medications", with scopes like "view" and "prescribe". And we'd have a resource set like "Alice's Step Counts" with scopes like "view" and "delete".</i><o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><b>Model 2: The "OAuth-First" approach</b><o:p></o:p></p></div><div><p class=MsoNormal><i>We have a resource set like "Alice's FHIR Endpoint", with scopes like "Medications.view", "Medications.prescribe", "Steps.view", and "Steps.delete".</i><o:p></o:p></p></div><div><div><p class=MsoNormal><o:p> </o:p></p></div></div></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Talking about an "OAuth-first" approach for setting policies is making me confused. I know what it looks like to enable OAuth-like flows in UMA when Alice is both the requesting party and the owner of the resource. And I know what it looks like to enable Alice to set policies at an UMA authorization server (which might hold the results of a previous OAuth-like flow done in UMA). But I don't know what "setting policies in OAuth" means because the OAuth experience is about consenting at run time (possibly checking and unchecking individual scopes), and revoking tokens at the AS/RS.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>So the closest UX analog would probably be the wording displayed in an OAuth consent dialog, maybe something like:<o:p></o:p></p></div><div><ul type=disc><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1'>View [and prescribe] your medications<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1'>View [and delete] your steps<o:p></o:p></li></ul></div><div><p class=MsoNormal> <o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><div><div><p class=MsoNormal>If the *types* of Resource Sets and the allowed scopes are standardized in advance (which UMA supports), then a mapping between Model 1 and "vanilla" OAuth could be as simple as: "concatenate the UMA resource set type followed by ':' followed by the UMA scope name" -- so for example, you might derive an OAuth scope like "<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__openid.net_heart_resource-2Dtypes_StepCounts-3Ahttps-3A__openid.net_heart_scopes_view&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=c5kzzfYQsMqNe16ufsx_ex-37vO5OdZxWdiMY3NLTUw&s=0mTQz2RR8olvVSG_ACkhJzRacqxp2v3gLXA6ZhqWDfQ&e=" target="_blank">https://openid.net/heart/resource-types/StepCounts:https://openid.net/heart/scopes/view</a>". Or under Model 2, the scopes could be reused directly (no mapping required). <o:p></o:p></p></div></div></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>In what sense is "reuse" meant here? A coding model, or an architectural model, or a semantic model?... There are ways in which I could imagine a deep kind of semantic reuse being possible without concatenation tricks being necessary. However, not being a developer, I'm not sure if they match what you're thinking of.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>For example, in my previous response to the minutes email, I outlined how some APIs have implicit mappings between scopes and acceptable endpoints/resources to which they apply.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Let's say (totally making this up) the FHIR has two endpoints, with one endpoint for medication records and one for fitness steps. There's an UMA-standardized resource type for each. There's "<b><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__www.hl7.org_fhir_rsrc_med.json&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=c5kzzfYQsMqNe16ufsx_ex-37vO5OdZxWdiMY3NLTUw&s=LlLtJhH_OIlUQ8SrcVg9EKLAat9EbG1iG-ZuUXZgxD0&e=" target="_blank">https://www.hl7.org/fhir/rsrc/med.json</a></b>", with instances of it registered with scopes "<b>view</b>", "<b>download</b>", "<b>transmit</b>", and "<b>add</b>" (so some clients can insert new entries). Alice's medications might be in a resource something like "<b>/alice/meds</b>". (What's displayed in her AS dashboard might look a lot nicer than that.) And there's "<b><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__www.hl7.org_fhir_rsrc_step.json&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=c5kzzfYQsMqNe16ufsx_ex-37vO5OdZxWdiMY3NLTUw&s=ru9SOoymql5fFmJhLU7HIVtaL7Yle27JOrDGnsPcX4w&e=" target="_blank">https://www.hl7.org/fhir/rsrc/step.json</a></b>", with instances of it registered with scopes "<b>view</b>", "<b>download</b>", "<b>transmit</b>", and "<b>chart</b>". Alice's steps might be in a resource like "/alice/steps".<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>(If the scopes are in the form of URIs, they could be standardized to a further degree, in that a bunch of metadata could be pulled by the authorization server and used to present standard labels and icons, and other semantics could be linked to them.)<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>If the very same API were OAuth-protected, with the very same resource endpoints, there might still be the same resource endpoints, with the same scopes, where three of them work on both resource types, "<b>add</b>" only works on "<b>med</b>", and "<b>chart</b>" only works on "<b>step</b>". These resources could still have a standardized meaning in terms of both resource naming and schema/format; there just would be nowhere to "hook" a standardized resource type URI into.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Seen this way, the OAuth approach and the UMA approach are quite similar, differing only in the implicitness vs. explicitness of the resource set layer.<o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Of course, some interesting things happen when we layer in details like...<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>W<i>hat if Alice has access to <b>multiple records </b>(say, her own and her mother's)?</i> In vanilla OAuth the binding of permissions to these records is generally implicit. How should they play out in UMA? Under Model 1, we'd probably see two more Resource Sets created ("Alice's Mom's Medications" and "Alice's Mom's Steps"). Under Model 2, we'd probably see one more Resource Set created ("Alice's Mom's FHIR Endpoint").<o:p></o:p></p></div></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I've been doing some work around chained delegation of this sort. Indeed, these are separate records, and must remain that way. Alice may not have all the permissions over her mother's records that she has over her own! One way to present such "downstream" items is to present them under a separate "Shared With" area. And there are various ways to organize owned items, e.g. by who you tend to share them with or by function. In discussions with consumer IoT folks, it seems that smart light bulbs want to be gathered by "room".<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>FWIW...<o:p></o:p></p></div></div></div></div></div></div><p class=MsoNormal>_______________________________________________<br>Openid-specs-heart mailing list<br><a href="mailto:Openid-specs-heart@lists.openid.net" target="_blank">Openid-specs-heart@lists.openid.net</a><br><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dheart&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=c5kzzfYQsMqNe16ufsx_ex-37vO5OdZxWdiMY3NLTUw&s=W7yuOEE1q5v0b9HN875EHzZ1NnyWF2UJW3HAEpXkFmU&e=" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><o:p></o:p></p></div></blockquote></div><p class=MsoNormal><o:p> </o:p></p></div></div></div><p class=MsoNormal><o:p> </o:p></p></div></div></body></html>