[Openid-specs-ab] 2025-01-30 OpenID Connect AB/C Minutes

Thu Jan 30 16:00:18 UTC 2025

OpenID AB Minutes

Attendees

   - Michael Jones
   - Aaron Parecki
   - Brock Allen
   - Dick Hardt
   - Lukasz Jaromin
   - George Fletcher
   - Giuseppe De Marco
   - Eduardo Perottoni
   - Brian Campbell

Notetaker: Aaron Parecki

## Poll open

Vote to Approve Proposed Second Implementer’s Draft of OpenID for
Verifiable Credential Issuance Specification

https://openid.net/foundation/members/polls/349

FAPI 2 vote will be open next week

Brock introduces himself

Lukasz introduces himself

Antitrust policy reminder

https://www.openid.net/wp-content/uploads/2024/09/OIDF-Antitrust-Policy_Final_2024-09-12.pdf

## Upcoming Events

   - FIDO Plenary next week
   - OAuth Security Workshop registration and hotel block are still open
   - IETF Bangkok in March
   - OpenID Workshop prior to IIW in April

Proposed OpenID Federation interop event in Europe in the next few months.
Reply to the email on the list to indicate interest in participation and
where/when you would like it to be, many suggestions in the email thread.

## Private Key JWT

OAuth Interim Meeting on Monday Jan 27

Topic: Private Key JWT security issue

Presentation:
https://datatracker.ietf.org/doc/slides-interim-2025-oauth-04-sessa-private-key-jwt-aud-issues/

Described the problem and solution. Tighten the audience value to be the
issuer identifer. Work has been happening behind the scenes to update specs
to address this.

One of which is OpenID Connect Core, which had contradictory audience
advice between the normative text and example. The example showed issuer
identifier (desired), the normative text said it should be the token
endpoint (problem).

New draft 36 includes the updates
https://openid.net/specs/openid-connect-core-1_0-36.html

Link to updated RFC 7523

Joe updated CIBA core and published an editor's draft.

Mike asks Bjorn if he can publish the editor's draft of CIBA core on
openid.net

Bjorn: What is the change that was made?

Mike: Are you not read in to this discussion?

Bjorn: I know the background, but I don't know the change that was made.

Mike: The change is the same as what's made to FAPI 1 and 2 and Connect
Core. When sending Private Key JWT client assertion to the AS, the audience
of the PKJWT now must be the issuer identifier of the AS. The current
language in CIBA Core Final lists 3 different things it could be,
recommends that it be the issuer, but allows other things to be accepted.
The nature of the attack exploits the ambiguity of the audience. The change
says the audience is the issuer identifier.

Bjorn: So you're asking to publish an errata with this change as a draft?
Mike: Yes

Bjorn: Can you also open an issue in MODRNA so that this is tracked? There
is one more issue that is targeted for an errata.

Mike: Yes, will do

Brock: Question about the "typ" value, filip's recommendation to
distinguish old clients using the wrong value. How does that play in to
these changes?

Published individual draft updating RFC 7523

https://www.ietf.org/archive/id/draft-jones-oauth-rfc7523bis-00.html

Mike: This contains two media type registrations, client-authentication+jwt
can be used to tell the PKJWT is definitely using this updated OAuth spec.
Currently the OpenID specs that have been updated (FAPI 1, FAPI 2, Connect
Core, CIBA Core) do not say anything about a typ value, because until the
OAuth WG has decided to do that it's premature. In particular we're not
referencing the 7523 update at this time. It would be a non-breaking change
on a server to recognize the typ value and do strict validation, but we're
getting ahead of ourselves if we do more than that.

Brock: If we were all starting from scratch, you wouldn't need the typ
value, because new clients would be using the issuer value?

Mike: The JWT best current practices does recommend explicit typing of JWTs
so that you can't have a cross-jwt confusion attack. Today on my list is to
take the RFC 7523 update to the OAuth list

## OpenID Provider Commands

This spec was contributed here:

https://lists.openid.net/pipermail/openid-specs-ab/2025-January/010548.html

Dick: I've implemented parts of it and deployed to get a feel for how it
works. In discussions with people I've gotten a fair amount of positive
feedback.

Aaron: I was pushing back on the suggestion to add an API to the OP, I
think the benefit of this draft is sending signed tokens.

Brian: You've also had not positive feedback to the idea. I have mixed
feelings about this, I don't think that SCIM or SCIM Events or RISC/CAEP
really hit the mark, so I have some sympathy for trying to produce the same
results in a simpler way. But I am similarly concerned that this is yet
another attempt at the same problem that will further crowd the landscape
and confuse everyone. This is both a note of support and pushback. Logout
is another area that has failed us all.

Dick: My understanding of your feedback was worried about there being
another protocol. The SAML people also told us we didn't need OpenID
Connect, but it's widely deployed because it solves things simpler.

Brian: I don't think the equivalency between SAML and OpenID Connect. That
said, I'd love to see something people actually use instead of the ongoing
hype about all the problems that RISC/CAEP will solve for us.

Mike: Could you put a few sentences about that on the mailing list so that
it's on record?

Brian: I will

Aaron: Would it be possible to reduce the scope of the draft to reduce the
number of things it's recreating? There are definitely things that this
draft describe that are needed and not being adopted by other current ways
of doing it.

Mike: There is clearly more discussion needed

## Native SSO

https://openid.net/specs/openid-connect-native-sso-1_0.html

George: Based on feedback from Brian and Vladimir, it seems there is some
appetite for discussing alternatives to the ID token. It would create
significant breaking changes but we have that option.

Mike: Do you know what you would propose to the WG?

George: Do we need to leverage the ID token for the use case? This spec was
introduced before DPoP really got going. The device secret is also
something we could reconsider. My plan is to form a smaller group to
brainstorm the right sets of changes and bring those back to the WG. I
think the need is still present.

Aaron: A lot of people are asking for native-to-web SSO for embedded web
views. Could that be in scope?

George: It's definitely an expanded scope. I'm not against looking at
including this, but the question would be should app-to-app be included.
I'd love to start a thread on the list of things we think we should do with
this draft. These things are related but not the same.

Aaron: Also going from the native app to the actual browser on the device

George: I started to submit a draft for that in 2013. That one is really
difficult from a security perspective. My ask is for anyone interested in
this to email me and consider being part of the subgroup to create the
recommendation.

Brock: There will be a session at OSW about the embedded browser approach.

## OpenID Federation

Project view on github for Federation

https://github.com/orgs/openid/projects/2/views/1

Mike: Issue 178, clarifies language around DCR. Reviews are requested

Mike: Giuseppe, are there particular issues/PRs you want to bring to the WG?

G: I need to complete the privacy considerations for the federation specs.

https://github.com/italia/openid-federation-browser?tab=readme-ov-file#openid-federation-browser

G: This is a web tool to navigate the trust infrastructure based on OpenID
Federation. This tool shows the infrastructure we have in production.

Mike: Thanks for the discussions today.

---
Aaron Parecki
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250130/b05aee68/attachment-0001.htm>