OpenID Foundation RISC WG Update from workshop at Oracle on april 4, 2018. Presented by Marius Scurtescu from Google.

1. RISC Status Report
Marius Scurtescu, Adam Dawes
April 2, 2018
OpenID Foundation Workshop at Oracle

2. Overview
● Introduction
● IETF secevent Status
● RISC Specs
○ RISC Events
○ OAuth Events
○ RISC Profile
● Implementation Status
● Legal & Next Steps
● 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
"...defines the Security Event Token (SET) data structure. A SET describes a
statement of fact from the perspective of an issuer about the state of a security
subject, which is intended to be shared with one or more recipients."
● https://tools.ietf.org/html/draft-ietf-secevent-token
● several minor changes
● last call, under review
● no (major) open issues

12. Delivery
"...defines how a series of security event tokens (SETs) may be delivered to a
previously registered receiver using HTTP POST over TLS initiated as a push to the
receiver, or as a poll by the receiver."
● https://tools.ietf.org/html/draft-ietf-secevent-delivery
● several minor changes
● working group approved splitting into two drafts: push and poll

13. Management API
"...defines an HTTP API for a basic control plane that event transmitters can
implement and event receivers may use to manage the flow of events from one to
the other."
● moved into RISC Profile

14. Subject Identifiers
"...defines a structure called a Subject Identifier: a JSON object containing a set of
claims that collectively uniquely identify a subject, according to a simple schema
called a Subject Identifier Type."
● currently part of RISC Profile
● to be extracted as standalone draft and moved to IETF secevent

15. RISC Specs

16. RISC Specs
● OIDF bitbucket: https://bitbucket.org/openid/risc/
● three specs:
○ RISC profile of IETF Security Events (risc-secevent)
○ RISC Event Types (risc-event-types)
○ OAuth Event Types (oauth-event-types)

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

18. OAuth Events
Base URI: http://schemas.openid.net/secevent/oauth/event-type/
● token-revoked
● tokens-revoked
● client-disabled
● client-enabled
● client-credential-changed

19. RISC Profile: Subject Identifiers
● to be extracted as an IETF secevent draft
{
"iss": "https://idp.example.com/",
"jti": "756E69717565206964656E746966696572",
"iat": 1520364019,
"aud": "636C69656E745F6964",
"events": {
"http://schemas.openid.net/secevent/risc/event-type/account-enabled": {
"subject": {
"subject_type": "iss-sub",
"iss": "https://issuer.example.com/",
"sub": "abc1234",
}
}
}
}

20. RISC Profile: Transmitter Discovery
/.well-known/risc-configuration
{
"issuer": "https://tr.example.com",
"jwks_uri": "https://tr.example.com/jwks.json",
"delivery_methods_supported": [
"http://schemas.openid.net/secevent/risc/delivery-method/push",
"http://schemas.openid.net/secevent/risc/delivery-method/poll"],
"configuration_endpoint": "https://tr.example.com/risc/mgmt/stream",
"status_endpoint": "https://tr.example.com/risc/mgmt/status",
"add_subject_endpoint": "https://tr.example.com/risc/mgmt/subject:add",
"remove_subject_endpoint": "https://tr.example.com/risc/mgmt/subject:remove",
"verification_endpoint": "https://tr.example.com/risc/mgmt/verification",
}

21. RISC Profile: Management API
● Stream Config (Get/Create/Update)
● Stream Status
● Add Subject
● Remove Subject
● Verification
○ Verification Event

22. RISC Profile: Authorization
● generic authorization recommendation
● not OAuth 2 or OIDC specific

23. RISC Profile: secevent profiling
● SET Profile
○ signature key resolution
○ subject at event level
○ explicit typing
○ 'exp' and 'aud' clarifications
○ single event, aliases OK
● Distribution Profile
○ configuration meta
● Security Considerations

24. Implementation
Status

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

26. Legal &
Next Steps

27. Legal Agreements
● Google drafted initial bi-lateral agreement and shared with number of parties
● 10 companies got together in January to agree on generalized “open source”
agreement based on Google’s initial draft.
● Google and Amazon working together to revise draft and contribute it to RISC
WG for further input by other companies
● Goal is to provide standardized contract that can be executed bi-laterally
across different parties.

28. Next Steps
● April 5: Face-to-Face at Google, Mountain View
● April 20: Face-to-Face at TBD, Seattle area
● April: NO official launch at RSA Conference 2018
● July: IETF 102 Montreal

29. Q&A