<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="">Comments inline:<div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 12, 2015, at 4:47 PM, Debbie Bucci <<a href="mailto:debbucci@gmail.com" class="">debbucci@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div dir="ltr" class=""><div class=""><div class="">I trust my social account to support many facets of my private life and
if forced to use a separate username/pwd the public identifiers that point to my email and cell phone are captured anyway.. Also trained to
respond to SMS text and have a number of questions I answer on a regular
(somewhat annoying) basis for banking. So I kind of align with
Jeremy's thinking re: social identity although I would say social identity + some
other factor (id proofing or cell num or SMS or biometric ) may give
greater confidence in the social credential being used. That aligns
with trust elevation ... which is part of VOT's yet to be determined
calculus and kind of leads to Bill's questions<br class=""></div></div></div></div></blockquote><div><br class=""></div>Right, and the “binding” ceremony could include several factors. The primary of which should be a federated identity, in my opinion.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><br class=""><p class="MsoNormal"><span style="font-size:14pt;font-family:"Cambria",serif;color:rgb(68,84,106)" class="">So the question is, what are Alice’s options assuming she wants to use SSO between her PHR and the PCP portal?
</span></p><p class=""><span style="font-size:14pt;font-family:Symbol;color:rgb(68,84,106)" class=""><span class="">·<span style="font:7pt "Times New Roman"" class="">
</span></span></span><span style="font-size:14pt;font-family:"Cambria",serif;color:rgb(68,84,106)" class="">How does OpenId Connect transmit equivalent of the VoT concept of “P1.C3.A2”?</span></p></div></div></div></div></blockquote><div>It would be communicated inside the ID token, probably as a separate “vot" claim. This is in addition to:</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><p class=""><span style="font-size:14pt;font-family:"Cambria",serif;color:rgb(68,84,106)" class=""> .... What is the equivalent of SAML authNcontext? I know I've asked this several times but I have brain freeze to the answer. I thought it was UMA binding obligations . <br class=""></span></p></div></div></div></div></blockquote><div><br class=""></div><div>… the “acr" claim, which is the Authentication Context Reference. This is what would point to a “LoA” style definition that wraps up the vector inside of a context, but the vector is still very useful on its own for the RP to process. In many cases, the combination of the vector and the presence of trustmark / trust framework information can sit in place of an ACR.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><p class=""><span style="font-size:14pt;font-family:Symbol;color:rgb(68,84,106)" class=""><span class="">·<span style="font:7pt "Times New Roman"" class="">
</span></span></span><span style="font-size:14pt;font-family:"Cambria",serif;color:rgb(68,84,106)" class="">Map her credentials between systems?</span></p><p class=""><span style="font-size:14pt;font-family:"Cambria",serif;color:rgb(68,84,106)" class="">That's often how its done today. There is a mapping between the internal account info the 3rd party credential and some type of binding ceremony is done to validate the mapping.<br class=""></span></p></div></div></div></div></blockquote><div><br class=""></div><div>Exactly: you map the externalized credentials (iss/sub pair) to some local “account” object. You can do this in lieu of or, optionally, in addition to a local set of credentials.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class="">
<span style="font-size:14pt;font-family:Symbol;color:rgb(68,84,106)" class=""><span class="">·<span style="font:7pt "Times New Roman"" class="">
</span></span></span><span style="font-size:14pt;font-family:"Cambria",serif;color:rgb(68,84,106)" class="">Elevate her PHR login (credentials )?</span> <br class=""><br class=""></div>Well if the PHR can support mulit-factor - I would suggest if used its more secure than the username and password used alone. How can does the evidence that an in person person proofing (that met some standard workflow) was performed get registered for use elsewhere? Is it in the binding obligations? <br class=""></div><div class="">Could the patient authorization service - in this case I think its the PHR, provide adequate information for a resource server to make that determination .... I think this is where trust marks come in to play. <br class=""></div></div></div></blockquote><div><br class=""></div><div>The binding obligations are the legal bits that give all of this teeth. From a technical standpoint, it’s a matter of the RP accepting credentials and being signed on to a given trust framework.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""><span style="font-size:14pt;font-family:"Cambria",serif;color:rgb(68,84,106)" class="">
I guess this would open another discussion as to what
credentialing/authentication standards should HEART support to support
interoperability?
</span><br class=""><br class=""></div>800-63-2 for now <br class=""><div class=""><br class=""></div></div></div></blockquote><div><br class=""></div><div>Oh please no. The conflation of proofing, credentialing, assertions, and authentication contexts is driving a lot of the confusion here, and that publication is really at the source of a lot of that confusion today. I’d rather us talk about it in terms of the classes of items we care about (proofing, credentialing, etc) and help drive the work forward on other dimensions, like VoT and the GTRI Trust Marks effort.</div><div><br class=""></div><div> — Justin</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""><br class=""><br class=""></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Tue, May 12, 2015 at 3:33 PM, Kinsley, William <span dir="ltr" class=""><<a href="mailto:BKinsley@nextgen.com" target="_blank" class="">BKinsley@nextgen.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link="blue" vlink="purple" lang="EN-US" class="">
<div class=""><p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Cambria",serif;color:#44546a" class="">I liked that Justin’s first e-mail broken this down into pieces that help me understand what he is advocating. However, at the same time opening a hundred rabbit holes
to fall into</span><span style="font-size:14.0pt;font-family:Wingdings;color:#44546a" class="">J</span><span style="font-size:14.0pt;font-family:"Cambria",serif;color:#44546a" class=""> <u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Cambria",serif;color:#44546a" class=""><u class=""></u> <u class=""></u></span></p><p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Cambria",serif;color:#44546a" class="">I have two questions to start with:<u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Cambria",serif;color:#44546a" class=""><u class=""></u> <u class=""></u></span></p><p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Cambria",serif;color:#44546a" class="">To address one misunderstanding, in the use case, Alice’s PHR supports
<u class="">two-factor authentication</u> while the PCP system doesn’t; however, the PCP portal provides stronger proofing then Alice’s PHR does. Ideally Alice would want to manage everything including her credentials and profiles from her PHR.<u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Cambria",serif;color:#44546a" class=""><u class=""></u> <u class=""></u></span></p><p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Cambria",serif;color:#44546a" class="">So the question is, what are Alice’s options assuming she wants to use SSO between her PHR and the PCP portal?
<u class=""></u><u class=""></u></span></p><p class=""><u class=""></u><span style="font-size:14.0pt;font-family:Symbol;color:#44546a" class=""><span class="">·<span style="font:7.0pt "Times New Roman"" class="">
</span></span></span><u class=""></u><span style="font-size:14.0pt;font-family:"Cambria",serif;color:#44546a" class="">How does OpenId Connect transmit equivalent of the VoT concept of “P1.C3.A2”?<u class=""></u><u class=""></u></span></p><p class=""><u class=""></u><span style="font-size:14.0pt;font-family:Symbol;color:#44546a" class=""><span class="">·<span style="font:7.0pt "Times New Roman"" class="">
</span></span></span><u class=""></u><span style="font-size:14.0pt;font-family:"Cambria",serif;color:#44546a" class="">Map her credentials between systems?<u class=""></u><u class=""></u></span></p><p class=""><u class=""></u><span style="font-size:14.0pt;font-family:Symbol;color:#44546a" class=""><span class="">·<span style="font:7.0pt "Times New Roman"" class="">
</span></span></span><u class=""></u><span style="font-size:14.0pt;font-family:"Cambria",serif;color:#44546a" class="">Elevate her PHR login (credentials )?<u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Cambria",serif;color:#44546a" class=""><u class=""></u> <u class=""></u></span></p><p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Cambria",serif;color:#44546a" class="">So is this possible today with OpenId/oAuth/UMA? If so, how? If not, what is required?<u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Cambria",serif;color:#44546a" class=""><u class=""></u> <u class=""></u></span></p><p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Cambria",serif;color:#44546a" class="">Second:<u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Cambria",serif;color:#44546a" class="">While I like and generally agree with the concept that VoT is proposing, from my understanding, VoT is not a standard today; but a IETF discussion to perhaps become
a standard in the future. <u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Cambria",serif;color:#44546a" class=""><u class=""></u> <u class=""></u></span></p><p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Cambria",serif;color:#44546a" class="">I guess this would open another discussion as to what credentialing/authentication standards should HEART support to support interoperability?
<u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Cambria",serif;color:#44546a" class=""><u class=""></u> <u class=""></u></span></p><p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Cambria",serif;color:#44546a" class="">Bill<u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Cambria",serif;color:#44546a" class=""><u class=""></u> <u class=""></u></span></p><p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Cambria",serif;color:#44546a" class=""> <u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Cambria",serif;color:#44546a" class=""><u class=""></u> <u class=""></u></span></p><p class="MsoNormal"><b class=""><span style="font-size:11.0pt;font-family:"Calibri",sans-serif" class="">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif" class=""> Openid-specs-heart [mailto:<a href="mailto:openid-specs-heart-bounces@lists.openid.net" target="_blank" class="">openid-specs-heart-bounces@lists.openid.net</a>]
<b class="">On Behalf Of </b>Sarah Squire<br class="">
<b class="">Sent:</b> Tuesday, May 12, 2015 11:47 AM<br class="">
<b class="">To:</b> Maxwell, Jeremy (OS/OCPO)</span></p><div class=""><div class="h5"><br class="">
<b class="">Cc:</b> <a href="mailto:openid-specs-heart@lists.openid.net" target="_blank" class="">openid-specs-heart@lists.openid.net</a><br class="">
<b class="">Subject:</b> Re: [Openid-specs-heart] Vectors of Trust and the Binding Ceremony<u class=""></u><u class=""></u></div></div><div class=""><br class="webkit-block-placeholder"></div><div class=""><div class="h5"><p class="MsoNormal"><u class=""></u> <u class=""></u></p>
<div class=""><p class="MsoNormal">The problem is not that social credentials are insecure. The problem is that users often don't trust them. I think the idea here, as in NSTIC in general, is that users should be able to use their chosen Identity Provider (IdP). This creates
a market for IdPs that incentivizes them to get better.<u class=""></u><u class=""></u></p>
<div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p>
</div>
<div class=""><p class="MsoNormal">That said, because users don't pay for social IdPs, they are in a different class legally. Social IdPs are much more loosely regulated in terms of notification and consent than an IdP with a financial relationship with the user, like a
bank, university, or employer.<u class=""></u><u class=""></u></p>
</div>
</div>
<div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p>
<div class=""><p class="MsoNormal">On Tue, May 12, 2015 at 7:51 AM, Maxwell, Jeremy (OS/OCPO) <<a href="mailto:Jeremy.Maxwell@hhs.gov" target="_blank" class="">Jeremy.Maxwell@hhs.gov</a>> wrote:<u class=""></u><u class=""></u></p>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in" class="">
<div class="">
<div class=""><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d" class="">Why is a social credential a bad credential for authenticating to a patient portal? For many individuals,
the private details of their social accounts may be held <i class="">more </i>privately than their health records. There are a few celebrities that wish their iCloud accounts were more secure. Gmail allows for 2fx authentication if users want it. What about if/when
I can sign into my Microsoft Live account using facial recognition in Windows 10? Assume there existed a strong identity proofing method that is able to bind my social credential to my identity in the portal. Would allowing individuals to use a social credential
(for authentication to the portal) after this point be insecure?</span><u class=""></u><u class=""></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d" class=""> </span><u class=""></u><u class=""></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d" class=""> </span><u class=""></u><u class=""></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d" class=""> </span><u class=""></u><u class=""></u></p><p class="MsoNormal"><b class=""><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif" class="">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif" class=""> Openid-specs-heart [mailto:<a href="mailto:openid-specs-heart-bounces@lists.openid.net" target="_blank" class="">openid-specs-heart-bounces@lists.openid.net</a>]
<b class="">On Behalf Of </b>Eve Maler<br class="">
<b class="">Sent:</b> Monday, May 11, 2015 8:12 PM<br class="">
<b class="">To:</b> Justin Richer<br class="">
<b class="">Cc:</b> <a href="mailto:openid-specs-heart@lists.openid.net" target="_blank" class="">openid-specs-heart@lists.openid.net</a><br class="">
<b class="">Subject:</b> Re: [Openid-specs-heart] Vectors of Trust and the Binding Ceremony</span><u class=""></u><u class=""></u></p>
<div class="">
<div class=""><p class="MsoNormal"> <u class=""></u><u class=""></u></p>
<div class=""><p class="MsoNormal">The VOT work is really exciting, and Justin's description of it -- and the vulnerabilities lurking in locally managed accounts that often go unremarked -- is very helpful and on-point.
<span style="background:yellow" class="">Though "social" identities are perhaps not the best choices for logging in to patient portals</span>, the social-style login pattern works perfectly well, and need not increase risk.<u class=""></u><u class=""></u></p>
<div class=""><p class="MsoNormal"> <u class=""></u><u class=""></u></p>
</div>
<div class=""><p class="MsoNormal">BTW, if folks haven't noticed, there's a new OpenID Foundation work group called "<a href="http://openid.net/wg/risc/" target="_blank" class="">RISC</a>" (Risk and Incident Sharing Coordination)
to enable event notifications around compromised accounts, so that, e.g., a <a href="http://gmail.com/" target="_blank" class="">
gmail.com</a> confirmation loop compromise won't infect additional accounts. I believe that efforts like this will ultimately have more powerful impacts than all the password policies in the world. :-)<u class=""></u><u class=""></u></p>
</div>
</div>
<div class=""><p class="MsoNormal"><br clear="all" class="">
<u class=""></u><u class=""></u></p>
<div class="">
<div class="">
<div class="">
<div class="">
<div class=""><p class=""><b class="">Eve Maler<br class="">
</b>ForgeRock Office of the CTO | VP Innovation & Emerging Technology<br class="">
Cell <a href="tel:%2B1%20425.345.6756" target="_blank" class="">+1 425.345.6756</a> | Skype: xmlgrrl | Twitter: @xmlgrrl<br class="">
Join our <a href="http://forgerock.org/openuma/" target="_blank" class="">ForgeRock.org OpenUMA</a> community!<u class=""></u><u class=""></u></p>
</div>
</div>
</div>
</div>
</div><p class="MsoNormal"> <u class=""></u><u class=""></u></p>
<div class=""><p class="MsoNormal">On Mon, May 11, 2015 at 4:30 PM, Justin Richer <<a href="mailto:jricher@mit.edu" target="_blank" class="">jricher@mit.edu</a>> wrote:<u class=""></u><u class=""></u></p>
<div class=""><p class="MsoNormal">Swap 4 and 6 and it still works, but fed is simpler for Alice so she'll probably stop there.<u class=""></u><u class=""></u></p>
<div class="">
<div class=""><p class="MsoNormal" style="margin-bottom:12.0pt"> <u class=""></u><u class=""></u></p>
<div class=""><p class="MsoNormal">On 5/11/2015 7:27 PM, Debbie Bucci wrote:<u class=""></u><u class=""></u></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt" class="">
<div class="">
<div class="">
<div class=""><p class="MsoNormal"> <u class=""></u><u class=""></u></p>
</div><p class="MsoNormal">How will that simplify the current Federation process - maybe I'm asking how is the actual binding to the system performed:<br class="">
<br class="">
Current process often adds additional steps but you can get there <u class=""></u><u class=""></u></p>
</div>
<div class=""><p class="MsoNormal"><br class="">
1. Alice shows up at her doc’s<br class="">
2. Alice shows her ID and insurance card, these get verified<br class="">
3. A record gets created for Alice in the system<br class="">
4. The system issues Alice a new username and password - or one time link (likely bounced through her external personal email address from it-doesn’t-matter-where)<u class=""></u><u class=""></u></p>
</div>
<div class=""><p class="MsoNormal" style="margin-bottom:12.0pt"> 5. Alice logs in
<br class="">
6. Alice now given the option to use alternative (in person) with her personal digital identity (from it-doesn’t-matter-where as long as it registered in system's the metadata) and this is bound to her account (will assume via some session context
switch )<u class=""></u><u class=""></u></p>
</div>
<div class=""><p class="MsoNormal"> <u class=""></u><u class=""></u></p>
</div>
<div class=""><p class="MsoNormal"> <u class=""></u><u class=""></u></p>
</div><p class="MsoNormal"> <u class=""></u><u class=""></u></p>
</div>
<div class=""><p class="MsoNormal"> <u class=""></u><u class=""></u></p>
<div class=""><p class="MsoNormal">On Mon, May 11, 2015 at 6:11 PM, Justin Richer <<a href="mailto:jricher@mit.edu" target="_blank" class="">jricher@mit.edu</a>> wrote:<u class=""></u><u class=""></u></p><p class="MsoNormal" style="margin-bottom:12.0pt">The Vectors of Trust work that I mentioned on today’s call is, at its heart, an effort to take the different aspects of a “level of assurance” as defined in MB-0404 and SP-800-63 and
break them apart into individual components so that they can be considered separately. What’s driving this is that one of the biggest problems in the wild of 800-63 is that it conflates the strength of the credential with the strength of the proofing (among
other things), such that it doesn’t make sense within that context to have an anonymous credential with a high level of assurance. This is probably fine if you’re the government doing background checks on people before you hand out PKI cards to its employees
and contractors, but not only are there other use cases out there (to which 800-63 has time and again be erroneously applied) but also technologies have advanced significantly in the last decade.<br class="">
<br class="">
So in VoT we propose to break out identity proofing, credential strength/binding, and assertion strength. These names and categories are still up in the air, but the concept is that there are different parts that need to be communicated separately. So instead
of something coming across the wire as “LOA2”, it could come across as “P1.C3.A2”, which translates to “proofed at level 1, credentialed at level 3, asserted at level 2”. Now the question is: what does the RP do with this information? Well that depends on
who’s claiming it, and that’s where the trust framework and trustmark efforts come into play. These will serve as the anchor for the IdP to assert any particular vector, and the trust framework itself will let the RP know what it can do with that information.<br class="">
<br class="">
The list is here and the archives are available online:<br class="">
<br class="">
<a href="https://www.ietf.org/mailman/listinfo/vot" target="_blank" class="">https://www.ietf.org/mailman/listinfo/vot</a><br class="">
<br class="">
And to pull the curtain back a bit, I’m currently working on an update to my initial proposal now, with intention that it be discussed at the next IETF meeting in Prague. It’s not (yet) an IETF working group, so we’re still figuring out exactly where this is
going to ultimately land.<br class="">
<br class="">
<br class="">
<br class="">
As to the identity binding ceremony, it really fits in with what I’m discussing above: the proofing that is done at Alice’s IdP doesn’t really matter if Alice is doing some higher value proofing at her doctor’s office already. So what we’ve got today is something
like:<br class="">
<br class="">
1. Alice shows up at her doc’s<br class="">
2. Alice shows her ID and insurance card, these get verified<br class="">
3. A record gets created for Alice in the system<br class="">
4. The system issues Alice a new username and password (likely bounced through her external personal email address from it-doesn’t-matter-where)<br class="">
<br class="">
What I’m suggesting here is that we can use the identity federation technology to replace the last part of this, to:<br class="">
<br class="">
1. Alice shows up at her doc’s<br class="">
2. Alice shows her ID and insurance card, these get verified<br class="">
3. A record gets created for Alice in the system<br class="">
4. Alice logs in (in person) with her personal digital identity (from it-doesn’t-matter-where) and this is bound to her account<br class="">
<br class="">
<br class="">
Alice’s proofing is done in person so the IdP doesn’t need to do that. It’s nearly guaranteed to be a better security profile than giving Alice another password to manage, for many reasons I won’t enumerate on here right now because the internet would run out
of bits for my email. It’s going to be a much better user experience for Alice, who can use a familiar account to manage things. So are Alice’s attributes worthless? Hardly! The medical system is still going to want things like Alice’s display name and email
address, for its own uses, and the IdP can provide these as inputs, with Alice making sure they’re what she wants in the system. Otherwise, remember, Alice is just going to be filling out the “sign up” form herself anyway. The important thing is that the digital
identity (the iss/sub pairing in OIDC) is tied to a specific set of rights that include a specific medical record (or set of records).<br class="">
<br class="">
<br class="">
Now some people get all scared about talking to external IdPs, but it’s important, I believe, to point out that in the first case, Alice is probably going to do some kind of reset password link through her email address. Which means that anyone who manages
to 0wn Alice’s gmail account can now reset her password and log into her medical record. This turns out to be the same security profile as the second case, except that now Alice’s IdP can *also* look for suspicious activity of someone using her account at
her medical office. The explicit account binding ceremony lets both sides see clearly what’s up.<br class="">
<br class="">
<br class="">
As such, what I’m suggesting here (and in the VA-based “Steve” use case on the wiki) is that identity federation really does buy us a lot, and notions of “Alice needs a High LoA” really don’t make sense when you pull things apart. What we need to continue doing,
in HEART, is to break things down into their components and re-build them into the right systems for the world. The use cases can help guide us to what those pieces are, but remember that they don’t dictate what the systems will be.<br class="">
<span style="color:#888888" class=""><br class="">
— Justin<br class="">
</span><br class="">
_______________________________________________<br class="">
Openid-specs-heart mailing list<br class="">
<a href="mailto:Openid-specs-heart@lists.openid.net" target="_blank" class="">Openid-specs-heart@lists.openid.net</a><br class="">
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" target="_blank" class="">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><u class=""></u><u class=""></u></p>
</div><p class="MsoNormal"> <u class=""></u><u class=""></u></p>
</div>
</blockquote><p class="MsoNormal"> <u class=""></u><u class=""></u></p>
</div>
</div>
</div><p class="MsoNormal" style="margin-bottom:12.0pt"><br class="">
_______________________________________________<br class="">
Openid-specs-heart mailing list<br class="">
<a href="mailto:Openid-specs-heart@lists.openid.net" target="_blank" class="">Openid-specs-heart@lists.openid.net</a><br class="">
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" target="_blank" class="">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><u class=""></u><u class=""></u></p>
</div><p class="MsoNormal"> <u class=""></u><u class=""></u></p>
</div>
</div>
</div>
</div>
</div><p class="MsoNormal" style="margin-bottom:12.0pt"><br class="">
_______________________________________________<br class="">
Openid-specs-heart mailing list<br class="">
<a href="mailto:Openid-specs-heart@lists.openid.net" target="_blank" class="">Openid-specs-heart@lists.openid.net</a><br class="">
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" target="_blank" class="">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><u class=""></u><u class=""></u></p>
</blockquote>
</div><p class="MsoNormal"><u class=""></u> <u class=""></u></p>
</div>
</div></div></div>
</div>
<br class="">_______________________________________________<br class="">
Openid-specs-heart mailing list<br class="">
<a href="mailto:Openid-specs-heart@lists.openid.net" class="">Openid-specs-heart@lists.openid.net</a><br class="">
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" target="_blank" class="">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><br class="">
<br class=""></blockquote></div><br class=""></div>
_______________________________________________<br class="">Openid-specs-heart mailing list<br class=""><a href="mailto:Openid-specs-heart@lists.openid.net" class="">Openid-specs-heart@lists.openid.net</a><br class="">http://lists.openid.net/mailman/listinfo/openid-specs-heart<br class=""></div></blockquote></div><br class=""></div></body></html>