[Openid-specs-risc] call notes

[Atul Tulshibagwale]

Hi all,
Here are the notes from today's meeting. They are also stored here
<https://hackmd.io/@oidf-wg-sse/wg-meeting-20240206>:

Atul

-- 

<https://sgnl.ai>

Atul Tulshibagwale

CTO

<https://linkedin.com/in/tulshi> <https://twitter.com/zirotrust>
<atul at sgnl.ai>

WG Meeting: 2024-02-06 <https://hackmd.io/N6XpcaGWRCqQ2PKGJqy8pw#Attendees>
Attendees

   - Atul Tulshibagwale (SGNL)
   - Apoorva Deshpande (Okta)
   - Shayne Miel (Cisco)
   - Aaron Parecki (Okta)
   - Phil Windley ()
   - Marcus Almgen ()
   - Stan Bounev (VeriClouds)
   - Tim Wurtele ()

<https://hackmd.io/N6XpcaGWRCqQ2PKGJqy8pw#Agenda>Agenda

   - OAuth PR <https://github.com/openid/sharedsignals/pull/134>
   - Formal security analysis of SSF + CAEP + RISC

<https://hackmd.io/N6XpcaGWRCqQ2PKGJqy8pw#Notes>Notes
<https://hackmd.io/N6XpcaGWRCqQ2PKGJqy8pw#OAuth-PR>OAuth PR

   - (Apoorva) Intent is to specify how to use OAuth with SSF
   - (Atul) Should we refer to best practices for OAuth security?
   - (Apoorva) sure
   - (Shayne) If we are putting OAuth in this interop spec, would we have
   another interop spec for Transmitters and Receivers to use SSF?
   - (Shayne) OAuth is not secure enough for Duo's purposes, so we would
   not be able to get certification
   - (Aaron) What is the security concern?
   - (Shayne) HMAC signed user request
   - (Aaron) Making up your own authz scheme is not more secure than OAuth
   (typically)
   - (Aaron) FAPI is trying to do something like this, so you can look into
   that
   - (Atul) Does implementing OAuth give Cisco Duo any business benefit?
   - (Shayne) This is being discussed
   - (Aaron) Interop is fundamental for the spec to be useful
   - (Aaron) If you believe Bearer tokens are not secure, then perhaps
   there are two layers of security in the profile, one is basic, which uses
   bearer tokens, and the other is a higher security profile
   - (Apoorva) FAPI is just an OAuth profile, and we're trying to create
   something similar for SSF in this interop spec
   - (Aaron) I'd like to understand the concerns more and we should be able
   to come to some agreement on what should go into the interop profile
   - (Atul) Giving choices in interop profile makes it non-interoperable
   - (Aaron) FAPI has something like this - they have two categories of
   interoperability - "security profile" and "message signing"
   - (Aaron) So people would have to implement a "core", but some people
   can opt for a more advanced security model
   - (Shayne) There are two sections of what SSF does:
      - Stream Management
      - Actual stream control
   - (Shayne) Is that our opportunity to split the security profiles?
   - (Atul) I'd like to keep it simple so that any popular SaaS service
   (for example) can implement something to become interoperable

<https://hackmd.io/N6XpcaGWRCqQ2PKGJqy8pw#Formal-Security-Analysis>Formal
Security Analysis

   - (Marcus) FAPI has gone through a similar security analysis by
   University of Stuttgart
   - (Marcus) OpenID believes this is going to be useful for SSF too
   - (Marcus) We are starting very soon on doing this formal analysis, run
   until summer
   - (Marcus) It'll require collaboration in the form of PRs, questions,
   etc.
   - (Marcus) Since there is a financial agreement, it will help to keep
   things moving smoothly
   - (Marcus) We will need a point of contact from the WG
   - (Marcus) The OpenID Foundation wants us to look at specs that are
   approaching final stage
   - (Pedram) We are not analyzing the complete spec, but the configuration
   and discovery mechanism described in Section 6.
   - (Atul) How much did FAPI have to change?
   - (Marcus) Small changes
   - (Pedram) Mostly regarding the level of security the spec can assure,
   but not much changes to the actual spec

<https://hackmd.io/N6XpcaGWRCqQ2PKGJqy8pw#Action-Items>Action Items
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20240206/14df5d59/attachment-0001.html>