<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<a href="https://bitbucket.org/openid/connect/wiki/Connect_Meeting_Notes_2021-03-25_Atlantic" id="LPlnk683290">openid / connect / wiki / Connect Meeting Notes 2021-03-25 Atlantic — Bitbucket</a><br>
</div>
<div style="font-family: Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
# OIDC Spec Call 2021-03-25
<div><br>
</div>
<div>## Attendees </div>
<div>* Tim Cappalli</div>
<div>* Mike Jones</div>
<div>* Brian Campbell</div>
<div>* Joseph Heenan</div>
<div>* Filip Skokan</div>
<div>* Tom Jones</div>
<div>* George Fletcher</div>
<div>* Bjorn Hjelm</div>
<div><br>
</div>
<div>## Notes</div>
<div>### Upcoming Events</div>
<div><br>
</div>
<div>IIW</div>
<div><br>
</div>
<div>* 4/20 - 4/22</div>
<div>* [George] Use cases discussion would be a good session</div>
<div>* [Mike] Maybe an update on logout</div>
<div>* [Tom] Likely to be some on SIOP</div>
<div>* [Mike] Different folks have different goals for SIOP. Need to be more crisp about which parts of the problem the spec is solving.</div>
<div><br>
</div>
<div>OpenID Workshop</div>
<div><br>
</div>
<div>* 4/21</div>
<div><br>
</div>
<div>### Special Topics Calls</div>
<div><br>
</div>
<div>Browser Interactions STC</div>
<div><br>
</div>
<div>* [Tim] We'll be converting George and Vittorio's list to Github issues in the [IETF repo](https://github.com/IDBrowserUseCases/docs) and asking people to contribute PRs against them</div>
<div><br>
</div>
<div>### Issues</div>
<div><br>
</div>
<div>[1213](https://bitbucket.org/openid/connect/issues/1213/private_key_jwt-client_secret_jwt-audience)</div>
<div><br>
</div>
<div>* [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)</div>
<div>* [Filip] Audience should be clear but worried about introducing what are viewed as breaking changes. We should create an errata
</div>
<div>* [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</div>
<div>* [Filip] RFC 7523 says you MAY use the token endpoint URL</div>
<div>* [Mike] Connect says SHOULD</div>
<div>* [Filip] Why should it be the token endpoint URL when you're talking to a completely different endpoint</div>
<div>* [Mike] Can't make a breaking change in errata</div>
<div>* [Brian] It is very close to a breaking change</div>
<div>* [George] Can this be addressed in OAuth 2.1 or a best practice document? Feels like a best practice thing</div>
<div>* [Filip] Goal is to make the Connect certification suite accept the issuer identifier</div>
<div>* [Brian] Strongly agree it should accept issuer now without errata</div>
<div>* [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.
</div>
<div>* [Joseph] Like what was done in CIBA and PAR, any of the values are accepted (actual URL, issuer identifier and token URL)</div>
<div>* [Brian] Conformance test should allow. Warning doesn't seem necesary</div>
<div>* [Joseph] Change has to be made to both OP and RP sides</div>
<div>* [Mike] Why didn't implementations use the token endpoint value?</div>
<div>* [Joseph] People like felt it looked odd to set it to the token endpoint and then calling a different endpoint</div>
<div>* [Certification issue](https://gitlab.com/openid/conformance-suite/-/issues/877)</div>
<div>* [George] OP that passed before may fail after change</div>
<div>* [Brian] Working towards the reality of how it works </div>
<div>* [Filip] RP recommendation, use token endpoint as a fixed value and audience. AS - accept 3 values.</div>
<div>* [Mike] Keep discussing on these issues</div>
<div>* [George] Can we require it in the certification?</div>
<div>* [Brian] Fair point. From the certification perspective, could we warn in both cases and keep it symmetric</div>
<div>* [Joseph] Not great when two certified implementations can't talk to each other</div>
<div>* [Brian] Thought about doing an update to 7523. Worthwhile?</div>
<div>* [Filip] Might not help Connect since it is defined separately.</div>
<div>* [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</div>
<div> </div>
<div>(1216)[https://bitbucket.org/openid/connect/issues/1216/query-over-rp-initiated-logout]</div>
<div><br>
</div>
<div>* [Filip] Draft change coming that may change this</div>
<div>* [Joseph] Any s ecurity concern of accepting an ID token that isn't valid?</div>
<div>* [Filip] If I'm not going to use it, it falls into the planned draft change</div>
<div>* [Filip] Need broader audience on this one</div>
<br>
</div>
<div>
<div style="font-family: Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div id="Signature">
<div name="divtagdefaultwrapper" style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:; margin:0">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<div style="font-weight:normal; orphans:auto; text-align:start; widows:auto"></div>
</div>
</div>
</div>
</div>
</body>
</html>