[Openid-specs-risc] Fwd: Notes from Today

Adam Dawes adawes at google.com
Fri Feb 17 05:19:20 UTC 2017

Hi all,

Thanks to Adam Stiles for compiling notes from today's F2F and to everyone
who participated. I think the discussion was very rich and we've got some
greater alignment on terminology and some clearer issues that we need to
work out wrt bootstrapping streams and the control plane.

We also agreed that there would be more extensive F2F within Security
Events at IETF around the above issues and that we would have a mega RISC
F2F May 4-5 at the tail of IIW with a dinner on May 4. I'll send out more
details on those later but please save the date if you would like to attend.

Here is my summary of the conversation:

Adam's Deck: https://docs.google.com/presentation/d/1odqjN8mSyFxKCh

Phil's Deck (attached)

Agreed upon (I hope) terminology and basic behavior:

   - Explicit Relying Party
   Relying party to an IDP such that the user account security is reliant
   on SSO technology like OAuth, OpenID Connect.
   - Implicit Relying Party
   Relying party to an IDP through a side channel account recovery process
   via email for email identifiers and SMS/Call for phone numbers.
   - RISC Authority
   A service provider where the compromise of an account at that service
   will directly open up Relying Parties to attack for the same account. For
   Explicit Relying Parties, the Identity Provider is the RISC Authority. For
   Implicit Relying Parties, the mailbox provider is the RISC Authority. For
   Implicit RPs, determining how to become a RISC Receiver involves looking at
   DNS to find a record that indicates if a mail service is used and then the
   RP would sign up for a stream with that provider.
   - RISC Receiver
   A service provider that registers to receive SETs from another provider.
   The term is agnostic as to whether the Receiver is the RISC Authority or
   implicit/explicit RP though the more common case will be when the Reciever
   is a Relying Party. RISC receivers are responsible for registering config
   info to receive events at any given transmitter.
   - RISC Transmitter
   A service provider that sends SETs to other providers. The term is
   agnostic as to whether the Receiver is the RISC Authority or
   implicit/explicit RP though the more common case will be when the Reciever
   is a Relying Party. The transmitter is responsible for offering a way for
   the Receiver to register to receive events. The Transmitter should also
   document Stream configuration information.
   - Stream
   The Stream establishes the data plane between the two parties and only
   flows in one direction. It also represents the bootstrapping configuration
   information that enables the Transmitter to send events to the Receiver. A
   service provider may choose to establish multiple Streams with a
   Transmitter in order to support decentralization or tenancy. The group is
   still discussing whether or not the Stream should be configurable via API
   or managed via SCIM.
   - Event family
   The set of SETs that can flow over the data plane. Transmitters should
   document which RISC event types it plans to publish and allow Recievers to
   specify exactly which events it wants to receive to enable limit sharing of
   - Subject
   The subject around which the event occurred. For most RISC cases this
   will be the user, as specified with a public identifier like email address
   or phone number.
   - Subscribe/Subscription
   The action of a Receiver requesting to add a Subject to the Stream. This
   forms the control plane for the Stream. The subscription action is intended
   largely for Implicit Relying Parties because Explicit Relying Parties are
   self-documenting. When a Receiver subscribes to receive events on a subject
   the Transmitter can provide a response that indicates it would also like to
   subscribe to events from Receiver for the same user.

---------- Forwarded message ----------
From: Adam Stiles <Adam.Stiles at lifelock.com>
Date: Thu, Feb 16, 2017 at 4:06 PM
Subject: Notes from Today
To: Adam Dawes <adawes at google.com>

*RISC F2F February 16, 2017 @ Oracle in Redwood City*


(Tushar?) Pradhan, PayPal

Michael MacLaughlin, Microsoft (michmcla at microsoft.com)

Annabelle Richard Backman, Amazon (richanna at amazon.com)

Dick Hardt, Amazon (dick at amazon.com)

Andrew Nash, Confyrm (andrew at confyrm.com)

Mike Jones - Microsoft, OID Board Hat

Phil Hunt, Oracle (phil.hunt at oracle.com)

Adam Stiles, Lifelock/Symantec (adam.stiles at lifelock.com)

*What Are The Events?*


•         Types of entities

◦          Mail provider (IDP)

◦          Explicit RP (oauth/sso)

◦          Implicit RP (email recovery). No explicit federation. (update
risk model)

◦          RISC publishers

◦          RISC subscribers

◦          AD: lines between publishers/subscribers blurred (subscriber can
publish back)

◦          Are events authoritative (Email IDP Gmail versus Amazon)?

◦          AD: Different parties can do different things

◦          PH: P2P sharing…

◦          PH: Clearinghouse/gateway… what happens propagating events
downstream (Oracle as gateway)?

◦          Amazon: events only passed to RP and not beyond. Not interested
in rebroadcast.

•         Is term receiver more clear than subscriber?

◦          DH: publish/subscribe overloaded

◦          Agreement: SET transmitter and SET receiver

•         Agreement: term: events

◦          Implied push model (Google doesn’t want to support pull. Doesn’t
want to play with greedy recipients)

•         Query for email state? Separate use case (valid, but separate)

•         Term for Enrolling a user?

◦          Subscription (name is up for debate)

▪          event types

▪          entities

▪          domains

▪          planes

•         Channel - connection between entities

•         Registration of interest

•         Term: connection/feed/stream (is this a contract)?

•         DH: A connection between entities and events can flow

•         Who: subjects. how do we indicate which subjects we have interest

•         Subject is the who. Don’t necessarily apply to people

•         Events are denominated by subjects

•         DH: Likes “subscribes”. Subscribe to these kinds of things about
these kinds of subjects

•         Agreed: what do we call it when we want to express interest in a
subject and a set of events? At a subject level…

•         A subscription: I want to get this kind of information about this
kind of subject

◦          Eg. Google and Amazon setup a connection

•         Agreed

◦          Event family is global for the connection

◦          Subscription is expressing interest about a subject on a

◦          We need these terms to live in Secevents spec

◦          There can be multiple connections between entities

•         Control plane = RPC-style?

PH: use SCIM as control plane


Entities establish a connection (Amazon and Google)

That connection specifies

•         which events they are interested in

•         how they will communicate, endpoint, etc.

•         connections are one-directions (established by receiver to
receive from transmitter)

Receivers express interest in subjects on that connection (subscription)

Control plane is always from receiver to transmitter

Control plane is fixed for a transmitter across many connections

Relationship is a connection

Data plane is a stream

AD: Let’s get data flowing. Let’s setup connections manually now. How do we
help users? Google only interested in receiving events from large RP/IDP

Broker - middleman

Agent - operating on behalf of another. Customer has delegated to you to
operate on their behalf

PH: Oracle tenancy. Are they brokers, agents? Issue is do we hold keys on
behalf and re encrypt to tenancy?


•         A stream is a connection (one direction)

◦          Console/manual (out of band)

▪          Creds (keys)

▪          What: events

▪          Endpoints

▪          Initial setup/bulk subscription: Not in spec. Friendly agreement
not to DDOS. Assume 1000 TPS

◦          Control plane

▪          Subscribe/unsubscribe

▪          Ping

◦          Stream

▪          Events

AD: we are going to whitelist streams based on contracts with other

Conversation about whether we can use SCIM

PH: Why are we inventing a new system?


To SCIM or not to SCIM - that is the question

How do we discover what IDP is authoritative for an email?

DH: Magical DNS record that says this IDP is authoritative for the domain

Discovery via DNS

MM: Do we need to define the authoritativeness?

AD: Do we agree that we need to indicate in these events? Whether the
transmitter is authoritative?

What does authoritative mean? Managing the email identifier?

ARB: Some events are low value (events from Google about an account that
logged into IMDB via Google Social (and ymail.com account) are low value.
Events from Yahoo would be high value.

Next F2F

Next F2F @ SecEvent @ IETF

Then do F2F @ IIW, Thursday afternoon, dinner. Friday morning to wrap by
mid afternoon. AD to coordinate. MM to check on space.

What is boundary between SecEvent and RISC?

DH: Stream is clearly in SecEvent.

The information contained in this transmission may contain privileged and
confidential information. It is intended only for the use of the person(s)
named above. If you are not the intended recipient, you are hereby notified
that any review, dissemination, distribution or duplication of this
communication is strictly prohibited. If you are not the intended
recipient, please contact the sender by reply email and destroy all copies
of the original message.

Adam Dawes | Sr. Product Manager | adawes at google.com | +1 650-214-2410
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20170216/29b299e5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RISC-F2FII-Distribution.pptx
Type: application/octet-stream
Size: 78423 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20170216/29b299e5/attachment-0001.obj>

More information about the Openid-specs-risc mailing list