[Openid-specs-risc] Meeting notes: 2021-04-13

[Richard Backman, Annabelle]

Hello SSE Working Group,

Notes for the April 13th, 2021 working group meeting can be found here: https://docs.google.com/document/d/1ZFwJJDwwSBNKX35VObClC1ctMbMMuHJtr5qY-7xsLW8/edit#

They are also pasted below for your convenience:

––

Attendees:

  *
Annabelle Backman (AWS)
  *
Matt Domsch (SailPoint)
  *
Stan Bounev (VeriClouds)
  *
Lee Tschetter (Okta)
  *
Martin Gallo (SecureAuth)
  *
Jeff Broberg (SecureAuth)
  *
Nick Dawson (Tesla)
  *
Ryan Alexander (Prove)
  *
Asad Ali (Thales)

Agenda:

  *
Carry over from 4/6?
     *
Resync request
  *
Open PRs
     *
Renamed CAEP Event Types to CAEP Specification<https://bitbucket.org/openid/risc/pull-requests/9/renamed-caep-event-types-to-caep> (Atul)
     *
Add Compromised Credential Use Case<https://bitbucket.org/openid/risc/pull-requests/2> (Stan)
  *
CAEP vs. RISC event namespace

Notes:

Resync request - Atul’s topic, but he can’t be here today, so hold until next meeting.

CAEP Event Types Spec name

  *
List of event types
  *
It is not a protocol, it is a list of JSON objects.
  *
CAEP name has better recognition
  *
Are there other groupings (session management, security posture) which are more descriptive
  *
Lee: user targets vs Session targets
  *
MS Implementation is called CAE.
  *
Do we need to have them separated by namespace at all? It’s helpful to have groupings of event types, but it’s not clear RISC, CAEP, OAuth, SSE groupings are the right ones.
  *
ACTION ITEM: Annabelle to send a concrete proposal to the list
  *
Stan: confusion among us translates to even more confusion among adopters. Tim is seeing same as they start to discuss with external partner implementations

Compromised Credential Use Case PR

  *
Trivial fixups
  *
Stan agreed to make event_timestamp optional
  *
Event does not include any timestamps yet
     *
Considering adding event timestamp
     *
When the compromise happened, or when the compromise was discovered?  Recommend to have detected_timestamp and event_timestamp as two separate members.
  *
Stan will create an event description and JSON examples.
  *
Patches must be made to the source spec file (XML or MD), as TXT files are generated.


Other implementations?

  *
Login.gov<http://Login.gov> implementation - both IDP and RP support for RISC events
  *
https://developers.login.gov/security-events/ and https://github.com/18F/identity-idp

Ryan Alexander (Prove, nee Payphone), VP Fraud

  *
Could SSE be used for fraud feedback? Banking world.
  *
Getting trustworthiness of phones, phones being misused.
  *
Standard for sharing fraud feedback?
  *
Runs a committee of 11 of the top banks (Prove Advisory Committee)
  *
Feedback comes from banks or other institutions
  *
Common device identifier (IMEI or other) shared between institutions
  *
Multiple identities being used on a phone; a phone may be “taken over” by malware
  *
Annabelle: sounds similar to RISC initial use cases, replace IDP with Bank.
  *
RISC covers Provider-to-Provider event communication
  *
ACTION ITEM: See also Nat Sakimura and the Financial Grade API effort. Annabelle to do an email intro.
  *
ACTION ITEM: Ryan to sign onto the OIDF IPR. See also Don.
  *
Parties: sharing between banks, reporting phone numbers involved in fraud, overlap between banking, telecom, gaming fraud. “Fraud is not a competitive advantage.”
  *
Cross-industry sharing. Security shortcomings at carriers affect the whole security ecosystem.
  *
This Spec work is about events, but is not defining an event clearinghouse operations model.  Banks can do this themselves.
  *
Andrew Nash with Confirm was interested in clearinghouse usecase for compromised email accounts. Not sure what was eventually built.

—
Annabelle Backman (she/her)
Co-Chair, OpenID Foundation Shared Signals & Events Working Group
richanna at amazon.com<mailto:richanna at amazon.com>




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20210413/426b2bef/attachment-0001.html>