[Openid-specs-risc] Call notes

Tue Jul 12 18:03:35 UTC 2022

Hi all,
Thanks for attending the OpenID SSE WG call today. The notes are pasted
below and stored here <https://hackmd.io/cPoNSMLYQ62dy_iGWLFrkQ?view>:
WG Meeting: 2022-07-12
<https://hackmd.io/cPoNSMLYQ62dy_iGWLFrkQ?view#Agenda>Agenda

   - Intros and Reintros
   - Gail CISA discussion
   - Pending Verification use case - Mark Haine
   - Review Okta feedback on CAEP
   - IDaaS feedback from Identiverse

<https://hackmd.io/cPoNSMLYQ62dy_iGWLFrkQ?view#Attendees>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)

<https://hackmd.io/cPoNSMLYQ62dy_iGWLFrkQ?view#Notes>Notes
<https://hackmd.io/cPoNSMLYQ62dy_iGWLFrkQ?view#Gail-CISA-discussion>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

<https://hackmd.io/cPoNSMLYQ62dy_iGWLFrkQ?view#Pending-Verification-use-case>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 <http://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

<https://hackmd.io/cPoNSMLYQ62dy_iGWLFrkQ?view#Okta-feedback-on-CAEP>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 >
<https://hackmd.io/cPoNSMLYQ62dy_iGWLFrkQ?view#IDaaS-feedback-from-Identiverse>IDaaS
feedback from Identiverse
<https://hackmd.io/cPoNSMLYQ62dy_iGWLFrkQ?view#Action-Items>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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20220712/91d25a35/attachment-0001.html>