RISC, SET, Match!

Subtitle: Deciphering WTF RISC and SSE are.

This is a published work in progress.

I was recently asked to help with a RISC project. After wondering if that meant I'd finally get a SPARCstation, I was relieved to learn that the acronym now refers to Risk Incident Sharing and Coordination at the OpenID foundation.

My relief soon turned to panic as I saw how ethereal and acronym-heavy the available documentation was. RISC is one of two applications implementing SSE (Shared Signals and Events), the other being CAEP (Continuous Access Evaluation Protocol). It describes a framework for Transmitters to send information about Events about Subjects to Receivers, over a Stream. The "streams" are formatted as SETs (Security Event Tokens), which are implemented as JWTs. Quoting the RFC, "A SET describes statements of fact from the perspective of an issuer about a subject.  These statements of fact represent an event that occurred directly to or about a security subject, for example, a statement about the issuance or revocation of a token on behalf of a subject."

Any remaining questions you have can be answered by the RFCs.

Unless your question is, "Huh?", which is where I found myself. Maybe we can figure this out together.

Google Does It

Google implements this as Cross-Account Protection, and provides a succinct introduction that's helpful.

So let's start somewhere nice and concrete. We use Gmail / Google Apps for email at work. Beyond email, the Google account is used for authentication, via their Sign in With Google feature. Logging into our software for scheduling interviews, for example, I just sign in with Google. A lot of other software works the same way.

But what if my Google account was compromised? Sure, IT at work can lock the account or force a password reset–after I figure out how to contact them without being able to look up their info in my email account. But what about all the SaaS services I've logged into?

Sites using Sign In With Google (aka Google Identity) can request that Google notify them via a webhook of important security events. For example:

• If a Google account is compromised, a site can expire that user's session cookies in our app.
• If Google closes the account for being a spammer, we can get an account-disabled event with the reason=bulk-account attribute set, and we probably want to do something on our side to see if they're sending spam in our app.

And suddenly, this all feels less ethereal. Google even calls out near the top that this is an implementation of RISC. Those webhooks/callbacks are the Security Event Tokens, submitted to a Receiver endpoint.

This also helps me understand something else: what stops me from creating a malicious Receiver and requesting notice of what happens with all Google accounts? Isn't this a security risk?

It's not actually addressed, but the concrete example makes this easier to reason about. If I implement Sign In With Google on my site, Google already knows who's used Google to log into my site. It would only be reasonable for them to ignore requests for events concerning unrelated third parties.

Microsoft does it

We saw RISC at Google. Microsoft's Azure AD implements the other half of SSE, the Continuous Access Evaluation Protocol.

.gov does it

login.gov, providing OpenID Connect access to various government sites, also implements Security Events – bidirectionally. Sites using login.gov can receive SETs, but they also accept incoming events. (One presumes a greater degree of trust exists between .gov sites than with random sites letting people log in via Google.)

Event Types

The full list of supported event types in RISC is here: