[Openid-specs-risc] Call notes

[Atul Tulshibagwale]

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

Atul

-- 

<https://sgnl.ai>

Atul Tulshibagwale

CTO

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

WG Meeting: 2022-06-27
<https://hackmd.io/i9spoIOLRkGuco8JThJbSw?view#WG-Meeting-2022->WG Meeting:
2022- <https://hackmd.io/i9spoIOLRkGuco8JThJbSw?view#Agenda>Agenda

   - Pull requests
   - Standardized scopes
   - Subject Identifiers

<https://hackmd.io/i9spoIOLRkGuco8JThJbSw?view#Attendees>Attendees

   - Atul Tulshibagwale (SGNL)
   - Shayne Miel (Cisco)
   - Eric Karlinsky (Okta)
   - Topher Marie (Strata)
   - Steve Venema (ForgeRock)
   - Apoorva Deshpande (Okta)
   - Phil Hunt (Independent ID)

<https://hackmd.io/i9spoIOLRkGuco8JThJbSw?view#Guests>Guests

   - Muneera (Apple)

<https://hackmd.io/i9spoIOLRkGuco8JThJbSw?view#Notes>Notes
<https://hackmd.io/i9spoIOLRkGuco8JThJbSw?view#Pull-Requests>Pull Requests

   - Most pull requests are merged. A few waiting on a pending review
   - Building HTML. Look at: <put url here></put>

<https://hackmd.io/i9spoIOLRkGuco8JThJbSw?view#Standardized-Scopes>Standardized
Scopes

   - [Eric] How does a Receiver know which scopes to request in order to
   setup a stream
   - [Atul] Can extend that to other functionalities, e.g. Poll a Stream
   - [Eric] Can we have an attribute in the well-known endpoint, which is
   an array of scopes that are supported. It could be two separate attributes.
   This could solve it.
   - How does a Receiver know which of the scopes are absolutely needed
   versus not needed.
   - There should be some indication of which scopes can do what
   - [Atul] I had a proposal:

   {
     "issuer":
       "https://tr.example.com",
     "jwks_uri":
       "https://tr.example.com/jwks.json",
     "delivery_methods_supported": [
       { "method": "urn:ietf:rfc:8935" },
       {
         "method": "urn:ietf:rfc:8936",
         "scopes_supported": ["poll_stream", "read"]
       }
     ],
     "configuration_endpoint": {
       "url": "https://tr.example.com/ssf/mgmt/stream",
       "scopes_supported": ["create_stream"]
     }
     "status_endpoint":
       "https://tr.example.com/ssf/mgmt/status",
     "add_subject_endpoint":
       "https://tr.example.com/ssf/mgmt/subject:add",
     "remove_subject_endpoint":
       "https://tr.example.com/ssf/mgmt/subject:remove",
     "verification_endpoint":
       "https://tr.example.com/ssf/mgmt/verification",
     "critical_subject_members": [ "tenant", "user" ]
   }


   - [Eric] For any of this, we need authentication
   - [Eric] We should require the metadata to have scopes if an endpoint
   requires authentication
   - [Phil] I’d expect there to be an OAuth server to issue the token with
   the scopes. And what is the nature of the client? Is it another SSF server?
   Is it a command line tool?
   - [Phil] If you’re building a command line tool, you need to specify
   both endpoints, but the spec defines only one endpoint
   - [Phil] The spec assumes it is always one server talking to another
   token
   - [Atul] Just putting scopes doesn’t define where the AuthZ server is
   - [Shayne] Access token doesn’t contain the stream ID
   - [Steve] Interop will be a pain point if we don’t have standardized
   scopes
   - [Steve, Atul] We could recommend a set of scopes and still allow other
   scopes to be used
   - [Eric] What is the namespace these scopes are in? Are they globally
   unique? How do we avoid conflicts with existing scopes?
   - [Steve] Can we define a SSF namespace?
   - [Shayne] Do they need to be globally unique? The OpenID Connect scopes
   seem very simple like “profile” or “email”
   - [Phil] You don’t need to register with IANA, you can just use a URN
   syntax like urn:openid:ssf:create_stream or something like that
   - Everyone on the call agrees that having a few standard scopes that are
   recommended, but allowing Transmitters to use different scopes will be a
   good addition to the spec

<https://hackmd.io/i9spoIOLRkGuco8JThJbSw?view#Subject-Identifiers>Subject
Identifiers

   - [Atul] Should subjects be at the top level, or should they be inside
   events. Also, should we use “sub_id” as the SecEvents Subject Identifiers
   spec is now standardizing that.
   - [Phil] From a common processing / routing point of view, how can a
   router or processor avoid having to parse individual events. It should just
   be able to parse top-level items such as “aud” or “exp”
   - [Phil] Streams may need to filter by subjects, if it is at the
   top-level, it will be better
   - [Shayne] Can we do both? Always put it at the top-level, but include
   it within the event when the event demands it
   - [Atul] Does putting “subject” as a required field in every “events”
   claim solve?
   - [Phil] This could be problematic if events are encrypted. The subject
   being available at the top-level can help route events even if the contents
   are encrypted
   - [Phil] The point is to use a registered claim.
   - [Apporva] If routing is the concern, wouldn’t it suffice to put the
   stream id in the JWT?
   - [Shayne] The stream ID is specific to the Tx - Rx communication, so
   shouldn’t be in the JWT
   - [Phil] My use case: Each SCIM server in a cluster is using a common
   router to push events. You may have multiple hops involved before the SCIM
   Receiver receives the event. You will need to re-sign the event at each hop
   if the stream ID is in the JWT.
   - [Atul] Since the stream ID information is at the URL level, even
   before getting to the JWT, so it’s not a concern for routing
   - [Phil] A single trigger may cause a SCIM and a RISC event (e.g.
   password changed), and if the formats are different, the routing logic for
   each type of event will need different processing
   - [Shayne] Existing events that have encrypted payloads don’t use SSF
   right now, extracting the sub_id to the top-level may enable those
   events to use SSF
   - [Steve] Struggling with a single subject. How would you decide which
   is the more important subject in a hypothetical “transfer” event.
   - [Phil] We need the concept of a primary subject, otherwise how would
   you do “add subject” and “remove subject”
   - [Steve] We have “complex” in SSF, but the SubIds draft talks about
   “aliases”, can we reconcile those?
   - [Phil] I only realized this because we cannot deploy SET PUSH and POLL
   on a point-to-point basis. We have to have recovery points, and routing
   becomes important.
   - [Steve] We have the PUSH and POLL RFCs, does it make sense to have a
   different RFC for these complex store and forward cases?
   - [Phil] SSF defines registration (which is different for push vs poll)
   - [Apoorva] Circling back to the encryption requirement. If we encrypt
   the event, and have a sub_id that is outside, won’t we be leaking PII? We
   would need to encrypt the subject in order to get this. (+1 from Shayne and
   Phil)
   - [Atul] We may want to keep the spec the same to avoid conflicting with
   existing implementations
   - [Phil] If SCIM and CAEP/RISC events differ a lot, then the processing
   infrastructure gets complex. Non-standard placement of subject will kill
   interop
   - [Steve] If you add a top-level claim then doesn’t the spec say you can
   ignore that claim.
   - [Atul] Should we discuss the top-level sub_id with replication in
   events?

<https://hackmd.io/i9spoIOLRkGuco8JThJbSw?view#Action-Items>Action Items

   - Atul to create an issue to describe the scopes requirement
   - Shayne to double check if he has proposed the top-level sub_id in the
   GitHub issue.
   - Phil to investigate whether unknown claims are required to be
   understood
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20230627/93088f42/attachment-0001.html>