<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">OpenID Connect Claims Aggregation:<br> No updates since draft -02 in September 2021</blockquote><div><br></div><div>This is inaccurate. There is a PR 745 standing since April 3. </div><div><a href="https://bitbucket.org/openid/connect/pull-requests/745">https://bitbucket.org/openid/connect/pull-requests/745</a> </div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">2025年4月15日(火) 10:24 David Waite via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"># OpenID Connect WG Call (Atlantic) Meeting Notes (2025-04-14)<br>
<br>
## Attendance<br>
<br>
* Michael Jones (MJ) - Chairing<br>
* David Waite<br>
* Dick Hardt - Chairing<br>
* Aaron Parecki<br>
* Andrii Deinega<br>
* John Melati<br>
* Michael Fraser (MF)<br>
* Tom Jones<br>
<br>
## Event Retrospective <br>
<br>
### OpenID Workshop and IIW, Apr 7-10, Mountain View, California<br>
<br>
Dick: <br>
<br>
> Cloudflare released information on how to use OpenID as part of SSH<br>
> negotiation<br>
> <br>
> OpenPubKey works by putting information into a nonce<br>
><br>
> Use a `cnf` claim in an `id_token` for DPOP.<br>
<br>
MJ: OpenID Connect UserInfo Verifiable Credentials was proposed for much of the<br>
same reasons but will be discussed later as inactive, was there overlap?<br>
<br>
Dick: Yes but the use cases are complicated, and it would be difficult to adapt<br>
<br>
### OpenID Federation Interop, April 28-30, hosted by SUNET in Stockholm<br>
<br>
MJ:<br>
<br>
> Putting together final logistics for OpenID Federation Interop, in 2 weeks in<br>
> stockholm. Please look at the attendee spreadsheet in the agenda - <br>
> specifically if you plan to attend and have dietary restrictions.<br>
<br>
## Inactive Specifications<br>
<br>
OpenID Connect Claims Aggregation: <br>
No updates since draft -02 in September 2021<br>
<br>
OpenID Connect UserInfo Verifiable Credentials: <br>
No updates since draft -00 in May 2023<br>
<br>
Self-Issued OpenID Provider v2:<br>
No updates since draft -13 in November 2023<br>
<br>
MJ:<br>
<br>
> Unfortunately the authors of these specifications aren't all on the call<br>
> today, so I'll take an action item to reach out to find out if these should<br>
> be marked as being inactive<br>
<br>
## OpenID Connect Relying Party Metadata Choices<br>
<br>
MJ:<br>
<br>
> Is it time for an Implementer’s Draft? Federation has a normative reference<br>
> to it and we'd like to lock in the IPR.<br>
<br>
MF: I did raise an issue <a href="https://github.com/openid/rp-metadata-choices/issues/2" rel="noreferrer" target="_blank">https://github.com/openid/rp-metadata-choices/issues/2</a><br>
about complications in use with Federation<br>
<br>
MJ: Agreed, we should have a discussion on this before calling for an<br>
implementer's draft<br>
<br>
## OpenID Provider Commands - Issues/PRs<br>
<br>
### Main PR<br>
<br>
Misc PR - expected to be non-controversial normative changes<br>
<a href="https://github.com/openid/openid-provider-commands/pull/12" rel="noreferrer" target="_blank">https://github.com/openid/openid-provider-commands/pull/12</a><br>
<br>
Has several issues which it attempts to resolve:<br>
<br>
[Rename commands URI to commands endpoint](<br>
<a href="https://github.com/openid/openid-provider-commands/issues/2" rel="noreferrer" target="_blank">https://github.com/openid/openid-provider-commands/issues/2</a> )<br>
<br>
Dick: This is meant to align with terminology elsewhere in OpenID/OAuth<br>
<br>
Aaron agreed<br>
<br>
[Add Audit command](<br>
<a href="https://github.com/openid/openid-provider-commands/issues/3" rel="noreferrer" target="_blank">https://github.com/openid/openid-provider-commands/issues/3</a> )<br>
<br>
[Add error event](<br>
<a href="https://github.com/openid/openid-provider-commands/issues/6" rel="noreferrer" target="_blank">https://github.com/openid/openid-provider-commands/issues/6</a> )<br>
<br>
Dick: Add to SSE so RP can indicate to the OP a critical failure<br>
<br>
[Add sub and tenant to command responses](<br>
<a href="https://github.com/openid/openid-provider-commands/issues/8" rel="noreferrer" target="_blank">https://github.com/openid/openid-provider-commands/issues/8</a>)<br>
<br>
[SSE not dependent on HTTP/1.1](<br>
<a href="https://github.com/openid/openid-provider-commands/issues/9" rel="noreferrer" target="_blank">https://github.com/openid/openid-provider-commands/issues/9</a>)<br>
<br>
Dick: Clarified text there<br>
<br>
[Add streaming response error message…](<br>
<a href="https://github.com/openid/openid-provider-commands/issues/10" rel="noreferrer" target="_blank">https://github.com/openid/openid-provider-commands/issues/10</a>)<br>
<br>
Dick: Used if the SSE request attempts to revive a stream which the RP no<br>
longer recognizes<br>
<br>
## Other issues<br>
<br>
[client_id / aud values](<br>
<a href="https://github.com/openid/openid-provider-commands/issues/4" rel="noreferrer" target="_blank">https://github.com/openid/openid-provider-commands/issues/4</a>)<br>
<br>
Dick: Should the client_id be a claim and the aud is the command endpoint?<br>
<br>
Aaron: Does this have overlap with the FAPI audience mismatch issue<br>
<br>
MJ: we decided to use the id across the board rather than the endpoint address<br>
<br>
Andrii: in this case aud will be the command endpoint on the RP side<br>
<br>
Dick: there should only be confusion if the client_id and command endpoint were<br>
the same value<br>
<br>
Aaron: One explicit call out by the researchers who discovered the issue was<br>
that multiple audience values should not be used<br>
<br>
Dick: agree we should research why FAPI did not decide to make it the endpoint<br>
<br>
MJ: we should also ask the researchers (who discovered the FAPI issue) this<br>
question, since they seem happy to contribute<br>
<br>
["roles" claim per IPSIE IL3](<br>
<a href="https://github.com/openid/openid-provider-commands/issues/11" rel="noreferrer" target="_blank">https://github.com/openid/openid-provider-commands/issues/11</a>)<br>
<br>
Aaron: text may be premature in that the IPSIE work has not agreed to use<br>
commands yet<br>
<br>
Dick: will make sure we send the right message - that the idea seemed valid in<br>
IPSIE, so worth applying the same model to commands<br>
<br>
[202 response for async command processing](<br>
<a href="https://github.com/openid/openid-provider-commands/issues/5" rel="noreferrer" target="_blank">https://github.com/openid/openid-provider-commands/issues/5</a>)<br>
<br>
Dick: in drupal community, deleting/suspending an account does not happen<br>
synchronously - it is done using a queue. Using a 202-style response would<br>
support this, but then the RP needs to tell the OP that it is completed<br>
<br>
[notifications](<br>
<a href="https://github.com/openid/openid-provider-commands/issues/7" rel="noreferrer" target="_blank">https://github.com/openid/openid-provider-commands/issues/7</a>)<br>
<br>
Dick:<br>
<br>
> How the RP tells the OP that it should perform a command, e.g. there's new<br>
> data for you to fetch. There's a notification to an OP endpoint, possibly RP<br>
> authenticated, otherwise the OP includes entropy for each RP that rotates<br>
<br>
Aaron: A 202 location can indicate a location to determine if a command <br>
completes<br>
<br>
Dick: thats polling; what I'm proposing is that a notification is pushed to<br>
the OP<br>
<br>
Aaron: the request can also include a notification response endpoint to<br>
side-step a lot of these issues<br>
<br>
Dick: how would we do this for a new metadata command or audit<br>
<br>
Aaron: I don't think of those as notifications<br>
<br>
DW: Would this work with the SSE mechanism already there?<br>
<br>
Dick: Some of these could go through a lot of manual workflow, so could take<br>
hours/days<br>
<br>
Dick: in some cases people were worried about a network socket being held open<br>
for extended periods of time<br>
<br>
Dick:<br>
<br>
> one motivation is to try to keep things optional, although there's a<br>
> potential that a RP will act two different ways, but we want complexity at<br>
> the OP<br>
><br>
> Another thing during the IIW session was brainstorming about RP->OP events<br>
> and OP->RP commands.<br>
<br>
DW:<br>
<br>
> I think you have a few choices - push vs pull, single event stream vs per<br>
> command, (one more forgotten) - once you decide those you'll have your<br>
> mechanism.<br>
><br>
> If you do not want the OP to have a way to authenticate the RP, that will<br>
> steer you a particular way - or require you put significant restrictions on<br>
> how the OP responds to RP notifications<br>
<br>
## Other<br>
<br>
Aaron: I noticed that there were a few issues on the old openid-commands repo<br>
which were not moved over<br>
<br>
Dick: I will double-check those<br>
<br>
Call ended<br>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></div>