1.
RISC Status Report
Marius Scurtescu, Adam Dawes, Luke Camery
October 16, 2017
OpenID Foundation Workshop at PayPal

2.
Overview
● Introduction
● IETF secevent Status
● RISC Profile
○ RISC Events
○ Opt-Out
○ SET Profile
○ Delivery Profile
○ Management API profile
● RISC Use Cases
● Implementation Status
● Q&A

3.
Introduction

4.
An exploit at one service often leads to
hacks elsewhere
● Attackers use account recovery mechanism to
gain access to other accounts
● As largest email provider, Gmail hacks are
especially valuable to gain access to other
Internet services
● Compromise results in privacy breach, financial
loss, data loss
How Apple and Amazon
Security Flaws Led to My
Epic Hacking

5.
SSO doesn’t close the loop on user safety
Users can’t evict an attacker from a session bootstrapped with SSO
● There is no “password change” feature to kill sessions when using SSO
● How can we “kill passwords on the Internet” if SSO has weaknesses?
Single Sign Out Not Desirable
● Abrupt logouts for RP and IDP
● Lots of chattery state checks which don’t scale for IDP

6.
The solution...

7.
Sharing important security events
across providers
Risk and Incident Sharing and Coordination WG

8.
How is information shared with others?
RISC signals are sent only to the
apps the user is using

9.
How do we know the user’s apps?
Explicit relationship
via OAuth
Implicit relationship
registered via API
Request RISC for
alice@gmail.com
Contract
Required
For any app For any major app where
users benefit

10.
IETF
secevent
Status

11.
Security Event Token
● https://tools.ietf.org/html/draft-ietf-secevent-token
● last call
● no open issues

12.
Delivery
● https://tools.ietf.org/html/draft-ietf-secevent-delivery
● working group draft
To do:
● clarification to authorization
○ allow receiver to specify full HTTP authorization header

13.
Management API (aka Control Plane)
● https://tools.ietf.org/html/draft-scurtescu-secevent-simple-control-plane
● https://github.com/independentid/Identity-Events/blob/master/draft-hunt-seceven
t-stream-mgmt.txt
● 2 individual drafts
○ simple, focused on RISC use cases
○ SCIM friendly
To do:
● improve draft so it can be easily profiled by both RISC and SCIM
● add secevent discovery document
● authorization header configuration
● receiver event type list configuration

14.
RISC Profile

15.
RISC Profile
● OIDF bitbucket
● one profile spec to:
○ profile 3 IETF specs
○ define RISC events

16.
RISC Events
● account-credential-change-required
● account-deleted
● account-disabled
○ attribute: reason (hijacking, bulk_account)
● account-enabled
● identifier-changed
○ attribute: new-value
● identifier-recycled
● recovery-activated
● recovery-information-changed
● sessions-revoked
Base URI: http://schemas.openid.net/secevent/risc/event-type/

17.
RISC Events - Moved
Potential OAuth Profile:
● tokens-revoked
● other possible events:
○ token-revoked
○ client-secret-changed

18.
Opt-Out
Events:
● opt-in
● opt-out-initiated
● opt-out-cancelled
● opt-out-effective
States:
opt-in opt-out-initiated
opt-out
opt-out-initiated
opt-out-cancelled
opt-out-effective
opt-in

19.
SET Profile
● work in progress
● to profile:
○ signature key resolution (based on new discovery doc)
○ composite subject
■ risc_subject: { iss: "https://idp.example.com/", sub: "123abc" }
■ risc_subject: { email: " bob@example.com " }
■ risc_subject: { phone_number: "+1-123-456-7890" }
○ aud claim: client id
○ security consideration for Id Token and Access Token confusion

20.
Delivery Profile
● property in secevent discovery doc for signature key
●

21.
Management API Profile
● authorization using access tokens
● client id associated with access token identifies receiver
● Client Credential Grant to be used by receiver to obtain access token
● composite subject in add/remove APIs
○ email_verified and phone_number_verified also needed
○ {
risc_subject: {
email: "bob@example.com ",
},
meta: {
email_verified: true,
}
}

22.
RISC Use Cases

23.
RISC Use Cases Draft
● currently IETF individual draft
○ https://tools.ietf.org/html/draft-scurtescu-secevent-risc-use-cases
● to be moved to OIDF

24.
Implementation
Status

25.
Implementations
● Google
○ Live: transmitter with explicit use case
○ implicit use case: in progress
● Amazon
○ in progress
● PayPal
○ in progress

26.
Legal &
Next Steps

27.
Legal Agreement for Implicit Use Case
● Symmetric, obligation light agreement
○ Focuses on privacy requirements around data
● No obligations to send or act on any signals
● Consortium style rather than many bilateral agreements
○ Requires consent from all parties to add parties (EU style)
○ Ability to drop out at any time
● Drafted by Google and getting final approvals for distribution

28.
Next Steps
● November: IETF 100 Singapore
● January: Enigma Conference, get abuse teams together
● March: IETF 101 London
● April: official launch at RSA Conference 2018

29.
Q&A