OIDC Spec Call 2021-03-25

Attendees

• Tim Cappalli
• Mike Jones
• Brian Campbell
• Joseph Heenan
• Filip Skokan
• Tom Jones
• George Fletcher
• Bjorn Hjelm

Notes

Upcoming Events

IIW

• 4/20 - 4/22
• [George] Use cases discussion would be a good session
• [Mike] Maybe an update on logout
• [Tom] Likely to be some on SIOP
• [Mike] Different folks have different goals for SIOP. Need to be more crisp about which parts of the problem the spec is solving.

OpenID Workshop

• 4/21

Special Topics Calls

Browser Interactions STC

• [Tim] We'll be converting George and Vittorio's list to Github issues in the IETF repo and asking people to contribute PRs against them

Issues

1213

• [Filip] RFC under IETF, same method under core 1.0 and deployments. In order to be interoperable, client has to put 4 different audiences (issuer, fixed value of token endpoint, introspection endpoint, mTLS endpoint alias)
• [Filip] Audience should be clear but worried about introducing what are viewed as breaking changes. We should create an errata
• [Mike] Both the Connect spec and RFC 7523 say you should use the token endpoint URL and as long as you do that, you're compatible with both
• [Filip] RFC 7523 says you MAY use the token endpoint URL
• [Mike] Connect says SHOULD
• [Filip] Why should it be the token endpoint URL when you're talking to a completely different endpoint
• [Mike] Can't make a breaking change in errata
• [Brian] It is very close to a breaking change
• [George] Can this be addressed in OAuth 2.1 or a best practice document? Feels like a best practice thing
• [Filip] Goal is to make the Connect certification suite accept the issuer identifier
• [Brian] Strongly agree it should accept issuer now without errata
• [Mike] Conformance suite should be driven from the spec. Token endpoint + another value, good. No token endpoint, not good. Not dereferencing it, just equality check.
• [Joseph] Like what was done in CIBA and PAR, any of the values are accepted (actual URL, issuer identifier and token URL)
• [Brian] Conformance test should allow. Warning doesn't seem necesary
• [Joseph] Change has to be made to both OP and RP sides
• [Mike] Why didn't implementations use the token endpoint value?
• [Joseph] People like felt it looked odd to set it to the token endpoint and then calling a different endpoint
• Certification issue
• [George] OP that passed before may fail after change
• [Brian] Working towards the reality of how it works
• [Filip] RP recommendation, use token endpoint as a fixed value and audience. AS - accept 3 values.
• [Mike] Keep discussing on these issues
• [George] Can we require it in the certification?
• [Brian] Fair point. From the certification perspective, could we warn in both cases and keep it symmetric
• [Joseph] Not great when two certified implementations can't talk to each other
• [Brian] Thought about doing an update to 7523. Worthwhile?
• [Filip] Might not help Connect since it is defined separately.
• [George] When do we need to do a dot release for OIDC? We should publish something (this is the preferred way that client authentication should work, etc

(1216)[https://bitbucket.org/openid/connect/issues/1216/query-over-rp-initiated-logout]

• [Filip] Draft change coming that may change this
• [Joseph] Any s ecurity concern of accepting an ID token that isn't valid?
• [Filip] If I'm not going to use it, it falls into the planned draft change
• [Filip] Need broader audience on this one