[Openid-specs-risc] Call notes

[Atul Tulshibagwale]

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

WG Meeting: 2022-04-19
<https://hackmd.io/@oidf-wg-sse/wg-meeting-20220419#Agenda>Agenda

   - Intros and Reintros
   - Gail & OIDF Workshop at IIW
   - Quick Overview: HackMD
   - Token revocation use case {Tim}
   - Complex subject into its own spec? {Tim}
   - eKYC use case for Token Claims Change {Tim}
   - RISC draft review period {Atul}

<https://hackmd.io/@oidf-wg-sse/wg-meeting-20220419#Attendees>Attendees

   - Atul Tulshibagwale (SGNL)
   - Tim Cappalli (Microsoft)
   - Monty Wiseman ()
   - Nancy Cam Winget (Cisco)
   - Gail Hodges (OpenID Foundation)
   - Asad Ali (Thales)
   - Tom Sato (VeriClouds)
   - Frank Taylor (VMWare)

<https://hackmd.io/@oidf-wg-sse/wg-meeting-20220419#Notes>Notes
<https://hackmd.io/@oidf-wg-sse/wg-meeting-20220419#OIDF-Workshop-at-IIW>OIDF
Workshop at IIW

Key Message to share with the workshop group

   - Refresher on SSE and its activities
   - Use cases
   - Plans for the rest of the year

Token Revocation Talk

   - Could token revocation be a separate event?

Sushi Dinner hosted by VeriClouds / Tom Sato!

   - Message Tom if you would like to go
   - Sunday night

<https://hackmd.io/@oidf-wg-sse/wg-meeting-20220419#HackMD>HackMD

   - Any feedback on HackMD?

<https://hackmd.io/@oidf-wg-sse/wg-meeting-20220419#Token-Revocation-Use-Case>Token
Revocation Use Case

   -

   Add event named “token-revoked”, contains the SAML assertion Id or “jti”
   claim
   -

   What other fields should be included
   -

   The only other mechanism that exists is the OAuth token revocation spec,
   which has some limimtations
   -

   What about similar other use cases: step-up and SCIM updates? Those seem
   unrelated, becuase they are prescriptive and not descriptive
   -

   Token revocation could be “this is an action that has occured, and you
   can do what you want with it”. The SCIM event could be similar
   -

   Are there best practice issues with conflating SCIM provisioning with
   SSE updates?
   -

   The SSE event could be an observation that “there is a group membership
   change”
   -

   Having a SCIM receiver ignore SSE notifications could be disastrous
   -

   Consumers other than IdPs or IAMs could use the SSE updates
   -

   Two peers may use SCIM for different purposes. One could be IdP, but
   another could be serving other functions beyond IdP and IAM (e.g. SaaS
   provider, vulnerability assessor)
   -

   We can define the intent and usage, but actual implementations may use
   the same protocol features in other ways
   -

   CAEP is currently descriptive: A recipient can do anything they want
   -

   How is a “token revocation” different from a “session revocation”:
   - Not all relying parties treat the IdP’s view of the world as far as
      sessions is concerned, whereas a token revocation would mean the
recipient
      should revoke all sessions associate with the token
      - Currently, there is scope for ambiguity, so a tageted event for
      token revocation would be good to remove such ambiguity
      - Receiver of the event may not be an IdP
   -

   We need more discussion on other events (step up may already be present,
   SCIM related event needs discussion)

<https://hackmd.io/@oidf-wg-sse/wg-meeting-20220419#Complex-Subjects-into-its-own-Spec>Complex
Subjects into its own Spec

   - EKYC group wants to use the complex subject spec
   - They initially created one big spec and split it out
   - They are interested in splitting out the complex subject spec so that
   they could reuse it
   - Mutually beneficial
   - Should keep the complex subject spec in OpenID for now

<https://hackmd.io/@oidf-wg-sse/wg-meeting-20220419#eKYC-group-interest-in-SSE>eKYC
group interest in SSE

   - Use case: Pending verification. User signs-in, RP requests “verify X
   claim”. Could they use SSE to notify the RP?
   - It is a “token claims change”, but it deviates in that the current
   event supports changing any claim in the token.
   - The eKYC don’t want to send a new value in the event, but request the
   RP to obtain a new token
   - Can we add an additional optional flag to the event that has a value
   “userInfo”, which requires the RP to go fetch the claims again
   - Is this actually a “token claims change?”
   - Separate use case: Could the “token claims change” event contain a new
   ID Token that the RP can use
   - We probably need to get the OIDC group’s views on this
   - In person discussion at OSW and EIC (Berlin May 10-13)
   - Is using the “token claims change” value with a claim that didn’t
   previously exist in the token a legitimate use case? Yes, because you can
   today send a token claims change event with new claims.

<https://hackmd.io/@oidf-wg-sse/wg-meeting-20220419#RISC-Review-Period>RISC
Review Period

   - Reach out again to Mike Jones to start the review

<https://hackmd.io/@oidf-wg-sse/wg-meeting-20220419#Action-Items>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20220419/fb3f6ba0/attachment-0001.html>