[Openid-specs-ab] WG Meeting notes 15th May 2025

Fri May 16 15:28:47 UTC 2025

I am running into a large number of ID scenarios where action is not
completed in session but later.
Others are looking at issuing java script promises.
But in many cases this is closer to ID maintenance.
for example TSA PreCheck requires updates which are checked against
back-end data offline and issued later.
One way to deal with this is application level sessions that extend over
multiple TLS sessions.
Another problem is feed back when multiple endpoints are requested.
I got a 2nd factor request that claimed it was sent to me, but didn't say
which endpoint to re-establish a session.
and then the notification was in junk mail when I was looking at text
messages.
This does not seem like an extension to OIDC.

Peace ..tom jones

On Fri, May 16, 2025 at 3:45 AM Lukasz Jaromin via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> Hi Everyone. Please find the notes from the A/B WG call below.
>
> *Participants: *Michael Jones (chair), Brian Campbell, Filip Skokan,
> Lukasz Jaromin, Frederik Krogsdal Jacobsen
>
> *Introductions*
> Frederik joined the call for the first time. He introduced himself and the
> company he works for, called Criipto. He decided to join the working group
> to discuss a certain proposal for an extension of the OpenID Connect
> specification. The extension is related to deferred issuance of ID tokens
> to address real-life cases where the token is not ready at the end of the
> flow but can be obtained later.
>
> We followed with a round of introductions.
>
> *Summary of the OpenID Federation Interop Event hosted by SUNET in
> Stockholm*
> Mike provided a general update. Lukasz Jaromin added to it.
> It was a fruitful event. We built a couple of federations. Building these
> federations went smoothly. There were some improvement proposals discussed
> (some of which are reflected as Jira issues).
>
> The test federations remain up, so people are encouraged to interop test
> their implementations. If anyone wants to do that, instructions can be
> found here:
> https://docs.google.com/document/d/1Ho7wNGLz6I_6YrI7zCSWtLXSoctH3aRP/edit
>
> The document accessible via the link above also contains the results of
> testing.
>
> *Announcements*
> Reminder that IETF 123 registration is open:
> https://www.ietf.org/meeting/123/
>
> The IANA registrations for algorithms used in JOSE and COSE are done. The
> Fully-Specified Algorithms for JOSE and COSE
>
> https://datatracker.ietf.org/doc/draft-ietf-jose-fully-specified-algorithms/
> is now in the RFC Editor queue.
>
> The JOSE algorithm registrations are at:
>
> https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms
>
> The COSE algorithm registrations are at:
> https://www.iana.org/assignments/cose/cose.xhtml#algorithms
>
> *Agenda item 4: Specs and repositories*
> RP metadata choices is in the 45-day review period. Call to review it:
> https://github.com/openid/rp-metadata-choices
>
> *Agenda item 6: Claims aggregation draft*
> The draft is closed:
> https://openid.net/specs/openid-connect-claims-aggregation-1_0.html (see
> agenda for details).
> A technical edit needs to be done, then we’ll publish it.
>
> *OpenID provider commands*
> We will not talk about this today. We are lacking key people in the
> meeting.
>
> *Extended Subordinate Listing*
> Draft 2 was published not long ago.
> Lukasz: We encourage implementers to pick it up. There were discussions at
> the interop event about potentially other endpoints using pagination too.
> It would be worth applying a universal approach everywhere and perhaps
> include them in this spec. I'm hoping to have a follow-up on that topic
> with the group that was considering it.
>
> *OpenID Federation Specification*
> There are 24 issues that we need to take care of to reach final status.
> Not all of them have actions on them.
>
> *Agenda Item 10: Native SSO*
> George is not here. We’ll skip.
>
> *Agenda Item 11: Possible new drafts*
> *OpenID Connect Enterprise Extensions*
> https://github.com/dickhardt/enterprise-extensions?tab=readme-ov-file
> Potential overlap with IPSIE WG? IPSIE is not creating new normative
> specifications but creates profiles of existing specifications.
> Request to the WG members to read it and provide feedback. After that,
> we’ll decide whether to move forward with a call for adoption.
>
> *Ephemeral Subject Identifier draft*
> The draft has been submitted and was missed earlier because it was
> submitted as a reply to the meeting minutes.
> Link to the mail archive from April is here:
> https://lists.openid.net/pipermail/openid-specs-ab/2025-April/010728.html
> and in the agenda.
> Call to the WG to read this one and provide feedback.
>
> *Frederik presentation – Deferred ID token issuance*
> The deck is available here:
> https://fkj.github.io/slides/iiw-oic-dtr-apr-2025.pdf
>
> Discussion on CIBA vs. this new approach. What are the arguments for the
> need for this new proposal?
> There’s no backend. We don’t know who the user is. This is the difference
> between this and CIBA. In this case, we don’t know who the user is.
>
> There is one extra slide added to the presentation compared to the one
> presented at IIW and linked above – with a summary and conclusion. The
> Extra slide content:
>
> *Results from lIW session*
>
>    - *Small extension to OpenID Connect*
>    - *Take heavy inspiration from OpenID4VCI: Deferred Credential
>    Endpoint*
>    - *Flow modifications:*
>       -
> *Token endpoint returns a long-lived access token instead of an identity
>       token (MUST use DPoP)*
>       - *Poll/ping design on a new endpoint where access token can be
>       exchanged for an identity token once ready*
>
>
>    - *Questions:*
>       - *Should client request deferral or should it be a server
>       decision?*
>       - *New endpoint name? (/ deferred_token would match VC| spec)*
>
>
> Frederik discussed options and thoughts on backward compatibility and how
> that could potentially be addressed.
>
> Discussion on purpose and alignment with the WG charter.
> At IIW, there was discussion with the eKYC team. This is mostly for KYC
> purposes and would not be used for login flows.
>
> Comment: OpenID Connect is about login.
> "I am logging in and now I want to add some additional claims to the
> already logged-in user."
> Q: What do you get when you wait (in the scenario with login)?
> A: Potentially some additional claims at the user info endpoint.
>
> Example use case: I take a picture of my passport, ML says "I’m not sure
> about this" and a human needs to check it. This takes time and extends the
> process. At the login endpoint, it would be an unverified claim. When
> verified by a human, the token with that claim is ready to be issued.
>
> Comment/Thought: If you don’t do login, it is not Connect. It is more
> aligned with openid4vc specs.
>
> Comment/Thought: It could be done on top of the OpenID commands. It was
> discussed during the IIW.
>
> Final feedback to Frederik:
> To adopt it, the WG would have to understand how it relates to existing
> implementations. What problems are not being solved now that this could
> address?
>
> Lukasz Jaromin
>
> Head of Standards and Product Strategy
>
> T.
>
>
>
> +44 20 4583 6770
>
> lukasz.jaromin at raidiam.com
>
>
> <https://cloud.letsignit.com/collect/bc/652d0421e161c54081b81962?p=TMTQYP7uhVuEibYQ91RsC3IoNUOt5RBT8PxKu46ijB2dgYDas3ErY4e5aF36Y1QJAFvBq2HuNtKxmETJCut3KpCEIhZSyMrKEv86z2lTEIZvXWEQB9EFnTGMHp0zHr0amR6353_yp-GqFqaiskCLVrZHUSx89Swc40vs2oPD5o4=>
>
> The content of this email is confidential and intended for the recipient
> specified in message only. It is strictly forbidden to share any part of
> this message with any third party, without a written consent of the sender.
> If you received this message by mistake, please reply to this message and
> follow with its deletion, so that we can ensure such a mistake does not
> occur in the future.
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250516/fa82ef5f/attachment-0001.htm>