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

Wed Apr 16 07:10:01 UTC 2025

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

This is inaccurate. There is a PR 745 standing since April 3.
https://bitbucket.org/openid/connect/pull-requests/745

2025年4月15日(火) 10:24 David Waite via Openid-specs-ab <
openid-specs-ab at lists.openid.net>:

> # 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
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250416/d8207f33/attachment-0001.htm>