[Openid-specs-ab] OpenID Connect WG Call (Atlantic) Meeting Notes (2025-04-14)

Tue Apr 15 01:17:29 UTC 2025

# OpenID Connect WG Call (Atlantic) Meeting Notes (2025-04-14)

## Attendance

* Michael Jones (MJ) - Chairing
* David Waite
* Dick Hardt - Chairing
* Aaron Parecki
* Andrii Deinega
* John Melati
* Michael Fraser (MF)
* Tom Jones

## Event Retrospective 

### OpenID Workshop and IIW, Apr 7-10, Mountain View, California

Dick: 

> Cloudflare released information on how to use OpenID as part of SSH
> negotiation
> 
> OpenPubKey works by putting information into a nonce
>
> Use a `cnf` claim in an `id_token` for DPOP.

MJ: OpenID Connect UserInfo Verifiable Credentials was proposed for much of the
same reasons but will be discussed later as inactive, was there overlap?

Dick: Yes but the use cases are complicated, and it would be difficult to adapt

### OpenID Federation Interop, April 28-30, hosted by SUNET in Stockholm

MJ:

> Putting together final logistics for OpenID Federation Interop, in 2 weeks in
> stockholm. Please look at the attendee spreadsheet in the agenda - 
> specifically if you plan to attend and have dietary restrictions.

## Inactive Specifications

OpenID Connect Claims Aggregation: 
   No updates since draft -02 in September 2021

OpenID Connect UserInfo Verifiable Credentials: 
   No updates since draft -00 in May 2023

Self-Issued OpenID Provider v2:
   No updates since draft -13 in November 2023

MJ:

> Unfortunately the authors of these specifications aren't all on the call
> today, so I'll take an action item to reach out to find out if these should
> be marked as being inactive

## OpenID Connect Relying Party Metadata Choices

MJ:

> Is it time for an Implementer’s Draft? Federation has a normative reference
> to it and we'd like to lock in the IPR.

MF: I did raise an issue https://github.com/openid/rp-metadata-choices/issues/2
about complications in use with Federation

MJ: Agreed, we should have a discussion on this before calling for an
implementer's draft

## OpenID Provider Commands - Issues/PRs

### Main PR

Misc PR - expected to be non-controversial normative changes
https://github.com/openid/openid-provider-commands/pull/12

Has several issues which it attempts to resolve:

[Rename commands URI to commands endpoint](
    https://github.com/openid/openid-provider-commands/issues/2 )

Dick: This is meant to align with terminology elsewhere in OpenID/OAuth

Aaron agreed

[Add Audit command](
    https://github.com/openid/openid-provider-commands/issues/3 )

[Add error event](
    https://github.com/openid/openid-provider-commands/issues/6 )

Dick: Add to SSE so RP can indicate to the OP a critical failure

[Add sub and tenant to command responses](
    https://github.com/openid/openid-provider-commands/issues/8)

[SSE not dependent on HTTP/1.1](
    https://github.com/openid/openid-provider-commands/issues/9)

Dick: Clarified text there

[Add streaming response error message…](
    https://github.com/openid/openid-provider-commands/issues/10)

Dick: Used if the SSE request attempts to revive a stream which the RP no
longer recognizes

## Other issues

[client_id / aud values](
    https://github.com/openid/openid-provider-commands/issues/4)

Dick: Should the client_id be a claim and the aud is the command endpoint?

Aaron: Does this have overlap with the FAPI audience mismatch issue

MJ: we decided to use the id across the board rather than the endpoint address

Andrii: in this case aud will be the command endpoint on the RP side

Dick: there should only be confusion if the client_id and command endpoint were
the same value

Aaron: One explicit call out by the researchers who discovered the issue was
that multiple audience values should not be used

Dick: agree we should research why FAPI did not decide to make it the endpoint

MJ: we should also ask the researchers (who discovered the FAPI issue) this
question, since they seem happy to contribute

["roles" claim per IPSIE IL3](
    https://github.com/openid/openid-provider-commands/issues/11)

Aaron: text may be premature in that the IPSIE work has not agreed to use
commands yet

Dick: will make sure we send the right message - that the idea seemed valid in
IPSIE, so worth applying the same model to commands

[202 response for async command processing](
    https://github.com/openid/openid-provider-commands/issues/5)

Dick: in drupal community, deleting/suspending an account does not happen
synchronously - it is done using a queue. Using a 202-style response would
support this, but then the RP needs to tell the OP that it is completed

[notifications](
    https://github.com/openid/openid-provider-commands/issues/7)

Dick:

> How the RP tells the OP that it should perform a command, e.g. there's new
> data for you to fetch. There's a notification to an OP endpoint, possibly RP
> authenticated, otherwise the OP includes entropy for each RP that rotates

Aaron: A 202 location can indicate a location to determine if a command 
completes

Dick: thats polling; what I'm proposing is that a notification is pushed to
the OP

Aaron: the request can also include a notification response endpoint to
side-step a lot of these issues

Dick: how would we do this for a new metadata command or audit

Aaron: I don't think of those as notifications

DW: Would this work with the SSE mechanism already there?

Dick: Some of these could go through a lot of manual workflow, so could take
hours/days

Dick: in some cases people were worried about a network socket being held open
for extended periods of time

Dick:

> one motivation is to try to keep things optional, although there's a
> potential that a RP will act two different ways, but we want complexity at
> the OP
>
> Another thing during the IIW session was brainstorming about RP->OP events
> and OP->RP commands.

DW:

> I think you have a few choices - push vs pull, single event stream vs per
> command, (one more forgotten)  - once you decide those you'll have your
> mechanism.
>
> If you do not want the OP to have a way to authenticate the RP, that will
> steer you a particular way - or require you put significant restrictions on
> how the OP responds to RP notifications

## Other

Aaron: I noticed that there were a few issues on the old openid-commands repo
which were not moved over

Dick: I will double-check those

Call ended