# WG Meeting: 2022-04-19
## 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}

## 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)

## Notes
### 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

### HackMD
- Any feedback on HackMD?

### 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)

### 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

### 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.

### RISC Review Period
- Reach out again to Mike Jones to start the review

## Action Items