[Openid-specs-risc] Meeting notes
Atul Tulshibagwale
atul at sgnl.ai
Tue Jun 28 18:09:44 UTC 2022
Hi all,
Thanks for attending the working group call today. Here are the notes (also
stored here <https://hackmd.io/qbrLUwMORES9yEhaVLypOA>):
WG Meeting: 2022-06-28
<https://hackmd.io/qbrLUwMORES9yEhaVLypOA?view#Agenda>Agenda
- Intros and Reintros
- Identiverse recap
- Discuss stream ID in delivery endpoints
<https://github.com/openid/sse/issues/14>
- Required fields in CAEP events (Okta feedback)
<https://hackmd.io/qbrLUwMORES9yEhaVLypOA?view#Attendees>Attendees
- Atul Tulshibagwale (SGNL)
- Tim Cappalli (Microsoft)
- Shayne Miel (Cisco)
- Jason Garbis (AppGate)
- Steve Venema (ForgeRock)
- Edmund Jay ()
- Martin Gallo (SecureAuth)
- Tom Sato (VeriClouds)
- Frank Taylor (VMWare)
- Gail Hodges (OpenID Foundation)
<https://hackmd.io/qbrLUwMORES9yEhaVLypOA?view#Notes>Notes
<https://hackmd.io/qbrLUwMORES9yEhaVLypOA?view#Identiverse-Recap>Identiverse
Recap
-
Panel feedback
- Microsoft: > 25 million events per day
- Google: millions of events sent to 100s of thousands of apps
- Panel video link <https://www.youtube.com/watch?v=6Z6PMNNIlDY>
-
Booth feedback (Tom Sato)
- Panel was extremely well attended
- Many important people from the IDaaS community
- Okta, ForgeRock, Ping, etc.
- Attended by > 100 / 150 people
- Workday came to the OpenID SSE booth after the panel
- Okta team also visited the booth
- Booth was represented by Tom Sato, Nancy Cam-Winget (Cisco) and
Nick Wooler (Cisco)
- Questions about multi-tenanted ecosystems and how events could be
shared across tenants in such an environment
- Open issues with the credential compromised event
-
Stream ID issue:
- When the Transmitter is sending the event either using Push or Poll,
we need a way for the Transmitter to specify the stream ID
- In case of Push, the Receiver could specify it as a part of the
Receiver URL - do we need to do something in the spec for that
- The Transmitter’s Polling endpoint could have a Stream ID. We could
be more prescriptive about it
- We have to be normative about this
- Do we provide a parameter name or path component
- One possibility: For Push: Spec should specify that the Receiver
“SHOULD” define unique URLs for each Stream. For Poll, the spec should
recommmend how a Transmitter constructs the URL with the stream ID as a
path component
- We should modify the proposal such that the stream ID is always in
the path and not in the payload
- Is it easier in anyway to parse a payload compoent / query
parameter / path component?
- Would that only be on a Push?
- Would the metadata that describes all this have a placeholder for
the stream ID in the paths? Microsoft does something similar
with tenant ID
in Azure AD.
- Tim to review the OpenID Connect spec and figure out if anything
relevant can be used by us
- We should have one metadata for the Transmitter, not one metadata
per stream
- Shayne to update the PR to include path components instead of
stream IDs in payloads
- Should we have a path component to indicate the resource type? i.e.
“/streams/<stream-id>”
-
Interop testing
- OpenID will support building an implementation that can be used to
test against
- Tom spoke to Authlete and spoke to Mark Haine’s company, which has
done work on something similar for FAPI. They have experience on
how to do
this.
- It could cost between $10k - $20k to have such an implementation
(based on experience of building something similar for FAPI)
- Do they also do compliance testing? These two companies can do it
- The goal is that whenever this gets built, we hand it over to the
OpenID conformance testing team
-
Optional fields in CAEP events
- E.g. The “assurance level” field in the “assurance level change” event
- Optionality makes implementations complex
- Tim and Atul to setup time with Okta (Karl) to understand their
feedback and bring it back to the WG
-
Feedback from IDaaS
Issued raised
1. Re: compromised-credentials event - Sending PW across IDP is
probamatic. Verification Token can help
- Sending the hash of the password would require the Transmitter
and Receiver to agree on the hashing algorithm
- What are the use cases? Are there two? One where there is an
independent service, but is there a second case where the IdP
is indicating
that they know authoritatively that the credential is compromised.
- Can we add the “password verifier” in the event, such that a
Receiver can compare this value to their stored value and
determine if the
credential compromise event applies to them
- What is the use case of the identity provider notifying an SP of
“credentials compromise”?
- Atul to write this up and send it to the WG email for discussion
2. For large IDP, Polling million use identifier is not
possible.Sendto mechanism could help but how?
3. IDaaS needs a trasmitter hub structure within their ecosystem.
-
Proposed but not discussed:
- Outreach
1. Major webapps
2. CISA
3. Cybersecurity SETs
4. Specail WG Session for new comers
5. Webinar with iuse cases
- Testbed, reference implementation, testdata, conformance testing
1. We geenrated so much interest, many of new comers will need
these tools. Cost? Funds?
<https://hackmd.io/qbrLUwMORES9yEhaVLypOA?view#Action-Items>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20220628/a0cd19a1/attachment-0001.html>
More information about the Openid-specs-risc
mailing list