openid-risc-use-cases.xml

<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type='text/xsl' href='http://xml2rfc.tools.ietf.org/authoring/rfc2629.xslt' ?>
<!DOCTYPE rfc PUBLIC "-//IETF//DTD RFC 2629//EN" "http://xml2rfc.tools.ietf.org/authoring/rfc2629.dtd">
<!--
  NOTE:  This XML file is input used to produce the authoritative copy of an
  OpenID Foundation specification.  The authoritative copy is the HTML output.
  This XML source file is not authoritative.  The statement ipr="none" is
  present only to satisfy the document compilation tool and is not indicative
  of the IPR status of this specification.  The IPR for this specification is
  described in the "Notices" section.  This is a public OpenID Foundation
  document and not a private document, as the private="..." declaration could
  be taken to indicate.
-->

<rfc docName="openid-risc-use-cases-0_1" category="info" ipr="none">

  <?rfc toc="yes" ?>
  <?rfc tocdepth="5" ?>
  <?rfc symrefs="yes" ?>
  <?rfc sortrefs="yes"?>
  <?rfc strict="yes" ?>
  <?rfc iprnotified="no" ?>
  <?rfc private="Draft" ?>
  <?rfc comments="yes"?>

  <front>
    <title>OpenID RISC Use Cases</title>

    <author initials="M." surname="Scurtescu" fullname="Marius Scurtescu">
      <organization>Coinbase</organization>
      <address>
        <email>marius.scurtescu@coinbase.com</email>
      </address>
    </author>

    <date year="2023" month="February" day="09"/>
    
    <workgroup>Shared Signals Working Group</workgroup>

    <abstract>


<t>This document describes the RISC use cases and helps with
defining the requirements for token format and event distribution.</t>



    </abstract>


  </front>

  <middle>


<section anchor="intro" title="Introduction">

</section>
<section anchor="defs" title="Definitions">

<t><list style="symbols">
  <t>Transmitter - the entity that sends security events</t>
  <t>Receiver - the entity that receives security events</t>
  <t>IdP - Identity Provider, in most cases but not always this is the transmitter</t>
  <t>RP - Relying Party, in most cases but not always this is the receiver</t>
  <t>RISC - Risk and Incident Sharing and Coordination, see
http://openid.net/wg/risc/</t>
  <t>SCIM - System for Cross-domain Identity Management, see
http://www.simplecloud.info/</t>
</list></t>

</section>
<section anchor="use-cases" title="Use Cases">

<section anchor="explicit-idp-to-rp" title="Explicit IdP to RP">

<t><list style="symbols">
  <t>Transmitter: IdP</t>
  <t>Receiver: RP</t>
</list></t>

<t>Simplest use case, IdPs send security events to relevant RPs.</t>

<t>RP can make control plane calls to the IdP and can authenticate with access
tokens issued by IdP.</t>

</section>
<section anchor="explicit-rp-to-idp" title="Explicit RP to IdP">

<t><list style="symbols">
  <t>Transmitter: RP</t>
  <t>Receiver: IdP</t>
</list></t>

<t>The RP can also send RISC events back to IdP. We want to make it very easy for
the RP to do that, no complicated registration steps and crypto of possible.</t>

<t>IdP can document well-known endpoint for data plane (where it receives events).
RP can use access token when sending events on data plane and maybe does not
need to sign SETs.</t>

<t>If RP is sophisticated and is exposing its own control plane then during RP
stream registration with IdP (either manual or programmatic) it can advertise
its own issuer and that issuer through .well-known can specify full transmitter
functionality of RP.</t>

</section>
<section anchor="implicit-idp-to-rp" title="Implicit IdP to RP">

<t><list style="symbols">
  <t>Transmitter: implicit IdP</t>
  <t>Receiver: implicit RP</t>
</list></t>

<t>Example: Google and Amazon, Amazon account can be backed by gmail address.
Amazon acts as implicit RP to Google in this case.</t>

<t>Google and Amazon need legal agreement, When Amazon account is created or
updated with gmail address Amazon makes REST call to Google to enroll this new
email address for RISC events. If enrollment succeeds then RISC events will flow
bidirectionally (see next section, for simplicity only unidirectional is
considered in this section).</t>

<t>Assumption: Amazon/RP is registered with Google/IdP as an OAuth 2 client and can
use access tokens for control plane.</t>

<t>Open question: what are the implications of unverified email addresses?</t>

<t>Open question: discovery of hosted domains, how does Google know that
example.com is managed by Oracle and that subject enrollment should be sent to
them?</t>

</section>
<section anchor="implicit-rp-to-idp" title="Implicit RP to IdP">

<t><list style="symbols">
  <t>Transmitter: implicit RP</t>
  <t>Receiver: implicit IdP</t>
</list></t>

<t>No enrollment call is strictly necessary. The RP can start sending events to IdP
as new identifiers show up.</t>

</section>
<section anchor="pseudo-implicit" title="Pseudo-implicit">

<t>Common email address or phone number used by two different RPs.</t>

<t>Example: Amazon and PayPal, both Amazon and PayPal each have an account with the
same gmail address.</t>

<t>Mutual discovery by exchanging email address hashes.</t>

<t>Open question: legal and privacy implications</t>

</section>
<section anchor="idaas" title="Identity as a Service">

<t>Example: Google Firebear, IdaaS manages large number of RPs and implements RP
functionality on their behalf.</t>

<t>IdaaS should be able to manage SET distribution configuration for its RPs with a
given IdP using the credentials already established between the RP and the IdP.
Control plane operation to create/update stream allows that.</t>

<t>Assumption: IdaaS can impersonate RP at IdP (can obtain access token on behalf
of RP)</t>

</section>
<section anchor="secaas" title="Security as a Service">

<t>Similar to IdaaS described in previous section, but the service provider has its
own set of credentials different from the credentials and RP is using. The SP
cannot impersonate the RP at IdP. The IdP must define delegation rules and allow
the SP to make requests on behalf of the RP.</t>

</section>
<section anchor="on-premise-rp" title="On-Premise RP">

<t>The RP (receiver) is behind a firewall and cannot be reached through HTTP. The
only way to deliver events is if the RP periodically polls an endpoint provided
by the transmitter.</t>

</section>
</section>


  </middle>

  <back>

  </back>
</rfc>