<div dir="ltr">
<p class="gmail-p1" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue"">Thanks Martin and Atul - There are definitely multiple layers here, which we need to explore.</p>
<p class="gmail-p2" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue";min-height:15px"><br></p>
<p class="gmail-p1" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue"">Commenting on Martin’s first reply in which he makes the good point that the compromised credential can be of many different types (e.g. password, bearer token, Certificate, FIDO security key, etc), and the credential may be in one of many different forms (plaintext, hashed, potentially encrypted, etc).<span class="gmail-Apple-converted-space"> </span>The implication of this is that - regardless of whether this information is intended to be transmitted as part of a CAEP event or via a proprietary API, there still needs to be an agreed-upon taxonomy with which to communicate the format of the data being sent, if we intend for an automated system to be able to reliably act upon the result.</p>
<p class="gmail-p2" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue";min-height:15px"><br></p>
<p class="gmail-p1" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue"">Tom/Stan from VeriClouds - How does your system handle this classification? (I do not remember, and I sadly didn’t take detailed notes about this from the March 22 meeting). e.g. is there normalization (or an assumption thereof) by the transmitter in terms of the credential format?</p>
<p class="gmail-p2" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue";min-height:15px"><br></p>
<p class="gmail-p1" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue"">Let’s take a step back - is our use case / intention that the Receiver be able to act on this Credential Compromised event in an automated way? Or to initiate a manual validation process? There are risks on both sides, both from false negatives and from malicious positives (e.g.<span class="gmail-Apple-converted-space"> </span>“denial of service”). If the our goal is more to enable a manual validation process - this presumes a lower volume of events - then including the credential in an extended CAEP message could be useful, as long as there is a privacy-preserving mechanism of some sort. This could also avoid the problem of having to define a taxonomy for how the credentials are formatted, since the human reviewer will be presumably able to determine this. Alternatively, we could simply follow the current model and rely on a non-standard additional mechanism for the Receiver to obtain the credentials.<span class="gmail-Apple-converted-space"> </span></p>
<p class="gmail-p2" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue";min-height:15px"><br></p>
<p class="gmail-p1" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue"">Aiming for an automated process is more challenging, especially since it feels like it’ll be more brittle, and rely on correct classification of the credential in order to avoid false negatives by the Receiver. It feels like the damage from a false negative (where there actually is a compromise of a valid credential, but the system mistakenly rejects it) is worse than a false positive (the claimed credential is invalid, but the system indicates it’s compromised anyway) for a Credential Compromised event.</p>
<p class="gmail-p2" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue";min-height:15px"><br></p>
<p class="gmail-p2" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue";min-height:15px"><br></p>
<p class="gmail-p1" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue"">(I will reply to Atul’s email in a separate thread in order to keep them separate and focused)</p>
<p class="gmail-p2" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue";min-height:15px"><br></p>
<p class="gmail-p1" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue"">Regards</p>
<p class="gmail-p1" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue"">Jason</p></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 18, 2022 at 5:07 PM Martin Gallo <<a href="mailto:mgallo@secureauth.com">mgallo@secureauth.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div lang="EN-US" style="overflow-wrap: break-word;">
<div class="gmail-m_-790147840605600501WordSection1">
<p class="MsoNormal"><span style="color:rgb(31,73,125)">Hey all,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">Just wanted to provide some feedback, at least from my perspective, as this topic was discussed when we introduced the Compromise Credential event, but not sure if ended correctly capture in the notes.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">I think the “credential compromise” event is one of great value for Identity Providers and other services alike, but as mentioned it has some challenges. In particular, you want to signal that something happened
(the compromise) to a particular subject, without revealing the credential itself. For some of the credential types, this is not a problem (e.g. a FIDO2 security key can be referenced by it’s public identifier, an X.509 certificate by its serial number or
fingerprint) but the problem is with bearer tokens and memorized secrets.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">Main challenges IMHO are:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">- Compromised credentials can be found in different formats, and the transmitter of the event not always might have it in a reversible format. For example, a data breach might contain users password hashes extracted
from a compromised database (sometimes salted, sometimes not), while another data breach might directly contain the users’ password in plain text. There might be even cases where the same data breach contains credentials that are store in different formats
or using different algorithms.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">- There receiver might not have the credential stored at all, or have it in a format that is not reversible and different from the one that the transmitter have.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">- Identifying the exact credential (e.g. username and password combination) in the event is not possible without leaking information about the credential itself.
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">This is a known challenge and has been explored by both the academia as well as the industry, which has several security vendors providing these services with privacy-preserving protocols and mechanisms. A good
paper that I like to use as reference is “Protocols for Checking Compromised Credentials” by Lucy Li <a href="http://et.al" target="_blank">et.al</a>. [1], in which the protocol and threat model for checking compromised credentials is formalized.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">Going to Jason’s point and the actual proposal, I think that having a standardized method to check compromised credentials that works in an interoperable way and covers the different scenarios in a privacy-preserving
way is going to be very challenging. My suggestion is that, unless we want to enter into the burden of supporting a secure and privacy-preserving mechanism to actually identify the exact credential (which might be a little bit out of scope), we do keep the
current specification of the event with the semantic of signaling that “a credential related to the subject identifier was compromised”. The validation of the credential can be provided by the transmitter as a separate or related service, but using a check
protocol that provides the aforementioned guarantees. BTW, VeriClouds demo’ed their implementation (with two separate API calls) at the March 22<sup>nd</sup> SSE WG meeting [2].<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">Bests,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">Martin.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">[1] <a href="https://dl.acm.org/doi/10.1145/3319535.3354229" target="_blank">
https://dl.acm.org/doi/10.1145/3319535.3354229</a><u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">[2] <a href="https://hackmd.io/@oidf-wg-sse/wg-meeting-2022_03_22#VeriClouds-demo" target="_blank">
https://hackmd.io/@oidf-wg-sse/wg-meeting-2022_03_22#VeriClouds-demo</a><u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"><u></u> <u></u></span></p>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in">
<p class="MsoNormal"><b>From:</b> Openid-specs-risc <<a href="mailto:openid-specs-risc-bounces@lists.openid.net" target="_blank">openid-specs-risc-bounces@lists.openid.net</a>>
<b>On Behalf Of </b>Jason Garbis via Openid-specs-risc<br>
<b>Sent:</b> Thursday, July 14, 2022 4:33 PM<br>
<b>To:</b> Atul Tulshibagwale <<a href="mailto:atul@sgnl.ai" target="_blank">atul@sgnl.ai</a>><br>
<b>Cc:</b> <a href="mailto:openid-specs-risc@lists.openid.net" target="_blank">openid-specs-risc@lists.openid.net</a><br>
<b>Subject:</b> Re: [Openid-specs-risc] RISC Compromise Credential event<u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="gmail-m_-790147840605600501gmail-p1" style="margin:0in"><span style="font-size:10pt;font-family:"Helvetica Neue",serif">Thanks Atul - here’s a recap, and an idea for discussion around the the RISC Credential Compromise event<u></u><u></u></span></p>
<p class="gmail-m_-790147840605600501gmail-p2" style="margin:0in;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;min-height:15px">
<span style="font-size:10pt;font-family:"Helvetica Neue",serif"><u></u> <u></u></span></p>
<p class="gmail-m_-790147840605600501gmail-p2" style="margin:0in;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;min-height:15px">
<span style="font-size:10pt;font-family:"Helvetica Neue",serif"><u></u> <u></u></span></p>
<p class="gmail-m_-790147840605600501gmail-p1" style="margin:0in;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal">
<span style="font-size:10pt;font-family:"Helvetica Neue",serif">Atul’s notes:<u></u><u></u></span></p>
<p class="gmail-m_-790147840605600501gmail-p2" style="margin:0in;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;min-height:15px">
<span style="font-size:10pt;font-family:"Helvetica Neue",serif"><u></u> <u></u></span></p>
<p class="gmail-m_-790147840605600501gmail-p1" style="margin:0in;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal">
<i><span style="font-size:10pt;font-family:"Helvetica Neue",serif">Proposal</span></i><span style="font-size:10pt;font-family:"Helvetica Neue",serif"><u></u><u></u></span></p>
<p class="gmail-m_-790147840605600501gmail-p1" style="margin:0in;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal">
<i><span style="font-size:10pt;font-family:"Helvetica Neue",serif">We should include a “password verifier” field in the Compromise Credential event.</span></i><span style="font-size:10pt;font-family:"Helvetica Neue",serif"><u></u><u></u></span></p>
<p class="gmail-m_-790147840605600501gmail-p1" style="margin:0in;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal">
<i><span style="font-size:10pt;font-family:"Helvetica Neue",serif">The verifier should contain the digest of the password</span></i><span style="font-size:10pt;font-family:"Helvetica Neue",serif"><u></u><u></u></span></p>
<p class="gmail-m_-790147840605600501gmail-p1" style="margin:0in;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal">
<i><span style="font-size:10pt;font-family:"Helvetica Neue",serif">A separate field should contain an indicator of the algorithm used to compute the digest</span></i><span style="font-size:10pt;font-family:"Helvetica Neue",serif"><u></u><u></u></span></p>
<p class="gmail-m_-790147840605600501gmail-p1" style="margin:0in;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal">
<i><span style="font-size:10pt;font-family:"Helvetica Neue",serif">Issues</span></i><span style="font-size:10pt;font-family:"Helvetica Neue",serif"><u></u><u></u></span></p>
<p class="gmail-m_-790147840605600501gmail-p1" style="margin:0in;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal">
<i><span style="font-size:10pt;font-family:"Helvetica Neue",serif">How can the Transmitter and Receiver agree on the algorithm?</span></i><span style="font-size:10pt;font-family:"Helvetica Neue",serif"><u></u><u></u></span></p>
<p class="gmail-m_-790147840605600501gmail-p1" style="margin:0in;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal">
<i><span style="font-size:10pt;font-family:"Helvetica Neue",serif">Is it feasible to send the verifier without knowing the “salt” value</span></i><span style="font-size:10pt;font-family:"Helvetica Neue",serif"><u></u><u></u></span></p>
<p class="gmail-m_-790147840605600501gmail-p2" style="margin:0in;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;min-height:15px">
<span style="font-size:10pt;font-family:"Helvetica Neue",serif"><u></u> <u></u></span></p>
<p class="gmail-m_-790147840605600501gmail-p2" style="margin:0in;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;min-height:15px">
<span style="font-size:10pt;font-family:"Helvetica Neue",serif"><u></u> <u></u></span></p>
<p class="gmail-m_-790147840605600501gmail-p1" style="margin:0in;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal">
<span style="font-size:10pt;font-family:"Helvetica Neue",serif">Use Case: A service provider discovers an alleged credential (username/password combination) in an untrustworthy location (e.g.<span class="gmail-m_-790147840605600501gmail-apple-converted-space">
</span>a Dark Web repository).<span class="gmail-m_-790147840605600501gmail-apple-converted-space"> </span>
This credential is for a specific identity and may be claimed to be for a specific service - let’s say it’s for
</span><a href="mailto:DarthVader@Comcast.net" target="_blank"><span class="gmail-m_-790147840605600501gmail-s1"><span style="font-size:10pt;font-family:"Helvetica Neue",serif;color:rgb(220,161,13)">DarthVader@Comcast.net</span></span></a><span style="font-size:10pt;font-family:"Helvetica Neue",serif">
and the alleged password is “Th3DarkS1deR0cks”. In this example, our user Darth likely uses his Comcast email as the identifier for many online services (bank, health club, etc), so this credential is actually for an unknown site or sites. (The compromise
may or may not identify the service for which this credential is supposedly valid e.e. EmpireBank). If Darth has poor password security practices, he may in fact reuse this password across multiple sites.<span class="gmail-m_-790147840605600501gmail-apple-converted-space"> </span><u></u><u></u></span></p>
<p class="gmail-m_-790147840605600501gmail-p2" style="margin:0in;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;min-height:15px">
<span style="font-size:10pt;font-family:"Helvetica Neue",serif"><u></u> <u></u></span></p>
<p class="gmail-m_-790147840605600501gmail-p1" style="margin:0in;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal">
<span style="font-size:10pt;font-family:"Helvetica Neue",serif">The service provider here wants to emit an event that this credential has been compromised, but wants to to avoid transmitting this password as cleartext.<span class="gmail-m_-790147840605600501gmail-apple-converted-space"> </span><u></u><u></u></span></p>
<p class="gmail-m_-790147840605600501gmail-p2" style="margin:0in;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;min-height:15px">
<span style="font-size:10pt;font-family:"Helvetica Neue",serif"><u></u> <u></u></span></p>
<p class="gmail-m_-790147840605600501gmail-p1" style="margin:0in;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal">
<span style="font-size:10pt;font-family:"Helvetica Neue",serif">Problem: How can the transmitter securely convey the password to the receiver for validation and necessary action? It feels wrong to rely on only transport security to encrypt the password, since
it’s entirely likely that the event will be logged or examined during its transmission.<u></u><u></u></span></p>
<p class="gmail-m_-790147840605600501gmail-p2" style="margin:0in;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;min-height:15px">
<span style="font-size:10pt;font-family:"Helvetica Neue",serif"><u></u> <u></u></span></p>
<p class="gmail-m_-790147840605600501gmail-p1" style="margin:0in;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal">
<span style="font-size:10pt;font-family:"Helvetica Neue",serif">Approach: The transmitter should be able to obfuscate the password in a receiver-specific way, so that only the intended receiver can access it.<span class="gmail-m_-790147840605600501gmail-apple-converted-space"> </span><u></u><u></u></span></p>
<p class="gmail-m_-790147840605600501gmail-p2" style="margin:0in;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;min-height:15px">
<span style="font-size:10pt;font-family:"Helvetica Neue",serif"><u></u> <u></u></span></p>
<p class="gmail-m_-790147840605600501gmail-p1" style="margin:0in;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal">
<span style="font-size:10pt;font-family:"Helvetica Neue",serif">First idea:<span class="gmail-m_-790147840605600501gmail-apple-converted-space">
</span>Assumption: Receiver only stores the hashed password value. Could the transmitter hash the password, and only send the hashed value to the receiver?<u></u><u></u></span></p>
<p class="gmail-m_-790147840605600501gmail-p1" style="margin:0in;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal">
<span style="font-size:10pt;font-family:"Helvetica Neue",serif">Issue: This would require that the the receiver inform the transmitter of its hashing algorithm and salt mechanism, which is not information that should be shared<u></u><u></u></span></p>
<p class="gmail-m_-790147840605600501gmail-p2" style="margin:0in;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;min-height:15px">
<span style="font-size:10pt;font-family:"Helvetica Neue",serif"><u></u> <u></u></span></p>
<p class="gmail-m_-790147840605600501gmail-p1" style="margin:0in;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal">
<span style="font-size:10pt;font-family:"Helvetica Neue",serif">Second Idea: The receiver provides a public key to the transmitter as part of a (to-be-specified) registration or stream setup process. The transmitter then uses this key to encrypt the password
within the event. Only the intended receiver has the corresponding private key, so the password is obfuscated in transit. The receiver can then decrypt the password, and then hash it (as needed) to compare it to its stored value, without having to share anything
about its hashing mechanism.<u></u><u></u></span></p>
<p class="gmail-m_-790147840605600501gmail-p2" style="margin:0in;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;min-height:15px">
<span style="font-size:10pt;font-family:"Helvetica Neue",serif"><u></u> <u></u></span></p>
<p class="gmail-m_-790147840605600501gmail-p2" style="margin:0in;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;min-height:15px">
<span style="font-size:10pt;font-family:"Helvetica Neue",serif"><u></u> <u></u></span></p>
<p class="gmail-m_-790147840605600501gmail-p1" style="margin:0in;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal">
<span style="font-size:10pt;font-family:"Helvetica Neue",serif">Thoughts? How much of a can of worms does this open up, in terms of now needing to specify a stream creation and registration protocol? Or, would it be sufficient for us to recommend that the
credential SHOULD be obfuscated, and that the mechanism for that is (for now) out of scope for the spec?<u></u><u></u></span></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Tue, Jul 12, 2022 at 7:19 PM Atul Tulshibagwale via Openid-specs-risc <<a href="mailto:openid-specs-risc@lists.openid.net" target="_blank">openid-specs-risc@lists.openid.net</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin:5pt 0in 5pt 4.8pt">
<div>
<p class="MsoNormal">Hi all,<u></u><u></u></p>
<div>
<p class="MsoNormal">A couple of weeks ago, I had agreed to write up the issue regarding the compromise credential event in RISC. Here's the little note: <a href="https://hackmd.io/eDzKdeVITr22DNcw7FRt1Q?view" target="_blank">https://hackmd.io/eDzKdeVITr22DNcw7FRt1Q?view</a><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I think Jason Garbis has some interesting suggestions on how we can solve the issue that hashing the password requires the salt value, which is not with the Transmitter in this case. Jason, would you care to comment?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Thanks,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Atul<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
<p class="MsoNormal">_______________________________________________<br>
Openid-specs-risc mailing list<br>
<a href="mailto:Openid-specs-risc@lists.openid.net" target="_blank">Openid-specs-risc@lists.openid.net</a><br>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-risc" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-risc</a><u></u><u></u></p>
</blockquote>
</div>
</div>
</div>
</blockquote></div>