[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
Lh46sydRk9uEsjZEB9RUhTW9V1lLs/edit?usp=sharing
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
data.
- 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*
Attendees
(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?*
Notes
• 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
about?
• 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
connection
◦ 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
*Summary*
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?
DH:
• 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
entities
Conversation about whether we can use SCIM
PH: Why are we inventing a new system?
http://www.simplecloud.info/
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
<(650)%20214-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