[Openid-specs-risc] Notes from today's call

[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-20230711>.

Atul

-- 

<https://sgnl.ai>

Atul Tulshibagwale

CTO

<https://linkedin.com/in/tulshi> <https://twitter.com/zirotrust>
<atul at sgnl.ai>
WG Meeting: 2023-07-11
<https://hackmd.io/XtEW50GdRRir1mI-ZSC7uA?view#Agenda>Agenda

   - sub_id at the top level
   - -standardized scopes / authorization server endpoint Issue 74
   <https://github.com/openid/sharedsignals/issues/74>
   -

<https://hackmd.io/XtEW50GdRRir1mI-ZSC7uA?view#Attendees>Attendees

   - Atul Tulshibagwale (SGNL)
   - Mike Kiser (SailPoint)
   - Shayne Miel (Cisco)
   - Steve Venema (ForgeRock)
   - Apoorva Deshpande (Okta)
   - Tim Cappalli (Microsoft)
   - Phil Hunt (IndependentID)

<https://hackmd.io/XtEW50GdRRir1mI-ZSC7uA?view#Notes>Notes
<https://hackmd.io/XtEW50GdRRir1mI-ZSC7uA?view#sub_id-at-the-top-level>sub_id
at the top-level

[Phil]

   -

   SCIM Events spec doesn’t have to refer to SSF because it refers only to
   the “sub_id”
   -

   There may be scenarios where you need to keep the event payload
   confidential (no spec for that yet)
   -

   In CAEP / RISC you have subjects that are added or removed from the
   stream, so those can be the top-level “sub_id” claim, but other subject
   information (if needed) can be inside the event
   -

   [Steve] Could JWE cover the event payload encryption?
   -

   [Phil] It could be that the event has a claim that is JWE
   -

   [Steve] Sometime back we had talked about just using TLS, and not
   needing encryption in any use-case
   -

   [Phil] If we have a multi-hop environment, where you do not want to
   reveal the content of the event to intermediaries, then you may need
   encryption
   -

   [Steve] So the motivation seems to be scaling. Have any of the
   implementers on this call run into this issue?
   -

   [Phil] We just need to avoid getting into a situation where SSF is
   un-routable based on sub_ids
   -

   [Shayne] Do we have a way of doing this in a less “breaking” way, e.g.
   adding “sub_id” at the top-level in addition to being in the event?
   -

   [Tim] We need to make the change now, if we are thinking of it, because
   it will be harder to make the change later.
   -

   [Phil] Having duplicate information is OK for now, especially if we are
   going to deprecate on of them later
   -

   [Steve] We’d have to be very clear about which field takes priority
   -

   [Apoorva] The subject duplication is going to remain for some time due
   to existing implementations
   -

   [Steve] If people are already using “subject” in the event, and you are
   required to ignore any top-level claims that you don’t understand, then
   won’t it not break anything?
   -

   [Apoorva] If “sub_id” get included in the SSF spec, then won’t it be
   inconsistent with CAEP and RISC specs?
   -

   [Atul] The top-level claim will be “sub_id”, but the CAEP And RISC
   events reamin the same.
   -

   [Atul] We should just remove the “required subject field in every event”
   language from the SSF spec
   -

   [Atul] Conclusion: Add sub_id at the top-level, keep “subject” in
   events, but note that such usage is deprecated for new events being defined.

<https://hackmd.io/XtEW50GdRRir1mI-ZSC7uA?view#Standardizing-scopes>Standardizing
scopes

   - [Apoorva] The current proposal is likely to break current
   implementations, so can we define it in a way that doesn’t break existing
   implementations, e.g. by putting the new information in top-level claims

  {
     "issuer":
       "https://tr.example.com",
     "jwks_uri":
       "https://tr.example.com/jwks.json",
     "delivery_methods_supported": [
       "urn:ietf:rfc:8935",
       "urn:ietf:rfc:8936",
     ],
     "configuration_endpoint": "https://tr.example.com/ssf/mgmt/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" ]
     "supported_scopes": {
         "poll_endpoint": ["scope1", "scope2"],
         "status_endpoint": ["scope1"],
         "configuration_endpoint": ["scope3", "scope4"]
     },
     "authorization_servers": [
         { "scopes" : ["scope1", "scope2"],
        "servers" : [ "https://server1/.well-known",
"https://server2/.well-known"]
         }
         {
           "scopes" : ["scope3", "scope2"]
           "servers": ["https://server2/.well-known",
"https://server3/.well-known"]
         }
     ]
   }

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

   - Atul to write drafts for both issues discussed today
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20230711/665cc9ae/attachment-0001.html>