[Openid-specs-ab] July 26 Minutes

[David Waite]

Apologies for the delay

-DW

# OpenID Call July 29th, 2024

## Attendees

* Mike Jones (Chair)
* Andrii Deinega
* Brian Campbell
* David Waite
* Dima Postnikov
* Tom Jones

## Announcements

### OpenID Federation

Mike Jones: 

> Implementer’s Draft published:
> https://openid.net/specs/openid-federation-1_0-ID4.html
>
> The move to GitHub was timed with this publication, from
> https://bitbucket.org/openid/connect/src/master/ to
> https://github.com/openid/federation
>    
> Proposing to triage old issues and PRs in Bitbucket, with an eye to
> close them outright, or point to new issues/PRs in GitHub
>    
> Also proposing to check in a file in the old repository pointing
> to new repository, which is how we have done this previously
> with the DCP spec move.

(No objections on call to proposals)

## Pull requests (Bitbucket)

[#589] [Federation] Allow retrieving metadata from existing locations

[#589]: https://bitbucket.org/openid/connect/pull-requests/589

Proposal: close with a message saying it won’t be merged due to the
move to GitHub

(No objections on call)

[#731] [#732] [#736] (3 part change for new Federation endpoints and
related metadata)

[#731]: https://bitbucket.org/openid/connect/pull-requests/731
[#732]: https://bitbucket.org/openid/connect/pull-requests/732
[#736]: https://bitbucket.org/openid/connect/pull-requests/736

Proposal: leave these open until new draft is submitted to working
group

(No objections on call)

## Issues (Federation, Bitbucket)

[#2158] Metadata parameter value arrays for RP metadata

[#2158]: https://bitbucket.org/openid/connect/issues/2158/metadata-parameter-value-arrays-for-rp

Need to look at it to figure out where it belongs. Author indicates
it maybe a Dynamic Client Registration enhancement, rather than a
Federation-specific change

[#2160] The iat parameter in Trust Mark status requests creates great
overhead for no good reason

[#2160]: https://bitbucket.org/openid/connect/issues/2160/the-iat-parameter-in-trust-mark-status

Proposal: close with status that it has been replaced by 
https://github.com/openid/federation/issues/24

(No objections on call)

[#2161] Error in Trust Mark status response (8.4.2)

[#2161]: https://bitbucket.org/openid/connect/issues/2161/error-in-trust-mark-status-response-842

Proposal: close with status that it has been replaced by 
https://github.com/openid/federation/issues/25

(No objections on call)

## Other Administratia 

Mike Jones:
> Thursday after publication of the OpenID Federation Implementer's 
> Draft, went through the IANA Considerations section and requested
> registry.
> 
> The reason we are requesting registrations now is because it is a 
> very stable spec, but not yet done. We want feedback from 
> designated experts before publishing the final spec.

> For example, Mark Nottingham noticed the schema for the 
> .well-known path registration was not defined, where we almost 
> certainly want to lock that down to HTTPS 
> (see: https://github.com/openid/federation/issues/22) 

Brian: what is the stability of these entries?

Mike: we do not anticipate any changes unless issues are found with
the registrations themselves

Mike Jones:

> There is a new proposed Federation profile spec which has been 
> written, the “OpenID Federation Wallet Architectures Draft”.
>
> https://lists.openid.net/pipermail/openid-specs-ab/2024-July/010345.html
>
> (rendered document:
> https://peppelinux.github.io/federation-wallet/main.html). 
>
> The normative parts are deployed in pilot.
> 

After disussion between Mike and Brian, the plan was to discuss this 
further during the Thursday meeting on whether to put forth a call
for adoption.

## Issues (Connect)

[#2162] Recommendation to the use of explicit typing for ID Tokens

[#2162]: https://bitbucket.org/openid/connect/issues/2162/recommendation-to-the-use-of-explicit

Mike: historic background - SWT (Simple Web Tokens) existed as a set
of query parameters including `typ=SWT`, and was transliterated as a
JWT requirement.

DW: I am working on an initial set of instructions for implementers
on how to understand the syntax of a JOSE-style message when you
don’t implicitly understand whether you received specifically e.g.
JWS vs SD-JWT. Part of this would be a best practice of registering
a structured suffix, and that applications should use this when they
further constrain their messages

[#2158] Metadata parameter value arrays for RP metadata

[#2158]: https://bitbucket.org/openid/connect/issues/2158/metadata-parameter-value-arrays-for-rp

Proposal here is for preferred-order arrays of names for client
metadata values which only provide a single option.

Mike: Polymorphic property names may cause implementer issues, 
so may prefer pluralization/ “_supported” spellings

DW: This doesn’t require federation, but there are lots of different
specs which might want to use this which could have different
interpretations. This does make assumptions on how RP implementations
are built (e.g. single endpoints for token methods/ASs)

Mike: should this be considered a federation issue? Author doesn’t
seem to feel so, and it is now open in both places

DW: Since the author doesn’t think this is a federation issue, close
it from the federation repository until it exists and we identify
federation issues/changes that result

Mike: sounds good

EOB