# WG Meeting: 2022-07-12
## Agenda
- Intros and Reintros
- Gail CISA discussion
- Pending Verification use case - Mark Haine
- Review Okta feedback on CAEP
- IDaaS feedback from Identiverse

## Attendees
- Atul Tulshibagwale (SGNL)
- Mark Haine (eKYC &IDA WG Chair - considrd.consulting)
- Tom Sato (VeriClouds)
- Gail Hodges (OIDF)
- Andrii Deinega ()
- Steve Venema (ForgeRock)
- Topher Marie (Strata Identity)
- Karl McGuinness (Okta)
- Nancy Cam-Winget (Cisco)
- Jason Garbis (Appgate)
- Martin Gallo (SecureAuth)
- Nick Wooler (Cisco - Webex)
- Tim Cappalli (Microsoft)
- Haoyu Li (Okta)

## Notes

### Gail CISA discussion
- {Gail} CISA folks reached out at Identiverse
- Could SSE work be of value for US Gov community
- Brief with CISA on Monday 7/18
- {Tom} Priority item was ZT principles and how to apply them. That is their focus.
- <link to CISA panel discussion>
- {Nancy} can help review the doc
- {Jason} what angle is CISA looking for? Spec readout or brainstorming, etc
- {Tom} Introductory meeting. This is first interaction with CISA
- {Gail} Interested in moving beyond consumer use cases into commercial / enterprise, more towards the CAEP set of use cases

### Pending Verification use case

- {Mark Haine} communication of identity verification metadata
- [Issue](https://bitbucket.org/openid/ekyc-ida/issues/1233/how-to-represent-pending-verification) in eKYC working group issue tracker prompting this discussion
- Unknown data until the user authenticates themselves
- IdP may kick off a workflow to gather additional attributes to satisfy the RP
- Doesn't fit inside a normal OIDC transaction, due to synchronous nature
- CAEP Token Claims change grabbed attention, but not exactly the same use case
- IdP needs to update the RP that there's been a change to the verified claims. Token Claims change event is close, but need to just notify that there's been a change, and have the RP call back to IdP to get new claims
- Could this be a configuration change instead of making changes to ID Assurance or CAEP specs. Could potentially be a new event type in CAEP
- {Atul} If there wasn't any semantic in the event that tells the receiver they need to take action, would that still meet needs or does it need to be explicit
- {Mark} Hint rather than requirement. It is up to the receiver whether they actually do it (ex: time may have expired)
- Claims Request parameter has the option to request claims be returned in token vs UserInfo endpoint
- Prefer folks to use UserInfo endpoint for claims of this nature
- {Martin} What is different than the existing Token Claims change event?
- {Mark} Claims provided in the event vs requesting a call back
- {Martin} What about the assurance level change event?
- {Mark} Would need to follow up about that event
- {Atul} If we changed the token claims change event and made the claims attribute optional, could that work?
- {Mark} Yes, that could meet the requirement.
- Also might be good to just provide a list of claims that have been updated, but not the values.
- {Jason} seems to be hesitation about PII in the events. If there is an agreement in place already, shouldn't this already be addressed?
- {Tim} Having this flexibility is important
- {Jason} Seems like PII issues could be addressed through
- {Atul, Karl} This could add some complexity to the Receiver implementation
- {Tim} Not all implementers need to implement everything
- {Mark} There's no Receiver metadata
- {Tim} It can be specified during registration
- {Tim} Leaving the claims empty is ambiguous since an empty claim is a valid claim. So it needs to either be a new top level claim with an array of token claims names or a new event.
- {Mark} A number of implementers are interested in solving for this use case, e.g. Yes.com, Investment and Savings Alliance in the UK
- {Mark} joint meeting and architecture doc?
- {Atul} we can start with a new event type so that implementers can choose to implement the new event or not

### Okta feedback on CAEP
- [Okta Feedback](https://hackmd.io/4woFIbHERnuqTNlKKQFjWA?view)
- {Karl} Credential change event: body of event overloaded instead of having a registry like model. Each credential type would have a schema. Shouldn't need to keep versioning in CAEP events.
- Reason codes are missing.
- AMR-style registry
- {Mark} Similar problem in eKYC/IDA WG
- {Mark} Challenge is who maintains registry over time and where it lives
- {Atul} Is result that registry is out of date and people are using proprietary values?
- {Mark} yes
- {Karl} IANA has JWT claim and AMR
- {Karl} Aren't there already dependencies since subject identifiers are in IETF?
- {Atul} Subject identifiers were adding in the SSE spec as well; reference IETF spec for rest
- {Martin} similar discussion when adding compromised credential to RISC
- {Nancy} SET draft was under secevents WG
- {Tim} SSE is a set of profiles of IETF so they wouldn't necessarily need to be driven via IETF
- {Nancy} secevents group is still active
- {Nancy} every RFC can define rules for how you can register things
- {Tim} Is the only way to establish an IANA registry via IETF?
- {Nancy} No
- {Atul} Need to ask OIDF how to set up IANA registries for OIDF specs
- {Nancy} Establish a whole new OIDF registry
- {Karl} Assurance Level Change event: if you look at OIDF suite of protocols, no defined way to express assurance level. No defined ACRs either.
- {Karl} End-to-end implementation including session establishment, changing it with CAEP is not possible today
- {Tim} There's no dependency in SSE on an auth session
- {Karl} This seems useful only if we have a clear end-to-end scenario
- {Karl} There's no reason code for an assurance level change. An MDM may be responsible for an assurance change level, but it may not know the assurance level. So right now you need to collect a lot of data from multiple parties to create the event
- {Tim} We've never really solved that since people involved ...
- {Karl} If I were to put my SSO hat on, I'd have it use the ACRs than AAL
- {Tim} Would you just use token claims change?
- {Karl} potentially
- {Atul} If we cannot use the event in its current form, can we remove it?

< These all need to be created as issues in Github >

### IDaaS feedback from Identiverse

## Action Items
- Atul to add the Identiverse SSE panel video to the SSE website
- Atul to review the Google Doc for the CISA meeting in advance of the meeting on Monday
- Send your email addresses to Atul or Tim to add yourself to the Slack channel
- Add discussion item for credential compromise in the next event.