[Openid-specs-ab] 2025-01-16 meeting minutes

[Aaron Parecki]

# OpenID Connect AB

Date: 2025-01-16

## Attendees

* Niels van Dijk
* Aaron Parecki
* Mike Jones
* Vladimir Dzhuvinov
* Elizabeth Garber
* Dick Hardt
* Brian Campbell
* Jan Vereecken
* Lukasz Jaromin
* Eruardo Perottoni
* Bjorn Help

## Minutes

* Intros from Jan, Niels, Eduardo

Upcoming Events

There are a set of OAuth interim working group meetings in progress. Next
topic: one-time tokens, then Private Key JWT

*   OAuth Interim Meetings on Mondays <https://events.oauth.net/tag/ietf>
*   FIDO Plenary, Feb 4-6, Melbourne, Australia
*   OAuth Security Workshop <https://oauth.secworkshop.events/osw2025>, Feb
26-28, Reykjavik, Iceland
*   IETF 122 <https://www.ietf.org/meeting/122/>, Mar 15-21, Bangkok,
Thailand
*   OpenID Workshop and IIW <https://internetidentityworkshop.com/>, Apr
7-10, Mountain View, California


Reminder about new call schedule. Every Thursday and every other Monday.
Next call on Monday the 20th.

Reminder of Active Specifications <
https://openid.net/wg/connect/specifications/>

### OpenID Provider Commands

https://github.com/dickhardt/openid-provider-commands

* Dick: This new draft from Karl (formerly Okta) pulls together a number of
things we've talked about over the last year
* OIDC Backchannel Logout explicitly says not to revoke refresh tokens
issued with offline access. But if you think an account has been taken
over, you want to kill those too, so there is a need for a command for
this. The "unauthorize" command in this draft does this.
* There are commands around account lifecycles, creating, suspending,
deleting, etc
* The metadata command enables the OP to send metadata and get back
metadata to the RP
* Most use cases fall into the enterprise SaaS b2b world where the OP is
managing identities for an enterprise and managing resources at the RP, as
opposed to a consumer use case
* Mike: There has been discussion among Vladimir and Aaron on the list
* Vladimir: When you say commands, is there any expectation about the
delivery, is it supposed to be guaranteed delivery or just try to send out
the token
* Dick: It is expected to be synchronous and if you don't get a response
back you assume it didn't work. Think of it more as RPC than signals. OP
Commands is "I want you to do something". The OP may not even send an ID
token to the RP unless it knows the RP will support certain commands.
* Vladimir: Is this only at registration
* Dick: The metadata command can happen at any time, so the OP might send
metadata before an initial login. There is also a tenant concept. OP says
"which commands will you support for this tenant", the RP replies, then the
OP can determine whether it will even send an ID token. Group management is
also part of OP commands.
* Dick: For RP SaaS apps that don't need all the functionality of SCIM,
they could use OIDC and OP Commands to provide SSO and
provisioning/deprovisioning instead of SAML and SCIM.
* Dick: We want to minimize the effort required by the RP to support this.
In SCIM, how the client authenticates is out of scope. In OP Commands it's
in scope, signed by the OP with the same key that signs the ID tokens, and
the schema of the commands builds on the schema of ID tokens. To ensure a
command can't be used as an ID token, it follows similar specs and prevents
a nonce from being in the ID token.
* Mike: does it also require a type value
* Dick: Yes, that changed to a MUST
* Brian: There was some interesting language when it was a SHOULD with
compatibility with existing deployments of commands. Was that a copy paste
mistake from another specification, or is that a hint that there is an
existing deployment that is now being considered as an actual specification
* Dick: It was unintentional, built upon the OpenID Backchannel Logout spec.
* Brian: The Backchannel Logout also profiles Security Event Tokens. It
looks like you didn't follow that construct?
* Dick: Yes, mainly because secevents focuses on it being an event, we want
to be clear this is a command not an event
* Brian: That makes sense. The use of "schema" in these things is maybe not
great, can be confusing to different audiences.
* Dick: The claims build on the same claims as in an ID token.
* Mike: I'd like to let this get discussed for a week then talk about it on
a call in a week

### Native SSO

There is one PR outstanding, George isn't here

https://bitbucket.org/openid/connect/pull-requests/744

Mike: This has two approvals and is largely editorial. I suggest it's time
to merge this unless there's any objections, then George will publish
another draft.

### OpenID Federation

https://github.com/openid/federation/pull/177

Vladimir: Don't look at it yet, I might retract it. We think there is an
opportunity to simplify the combinations further. There are 3 conditional
combinations currently defined, something Roland implemented years ago is
to stop processing early. We could devise a rule if there is a value
operator then ignore other operators that might be present, so we could
drop the conditional checks for the default operator.
Mike: I assume the value still has to be consistent with the restrictions
of the other operators. For example if you have "must be A or B" and a
value operator of "C" it should throw an error right?
Vladimir: Value has the top priority, when a trust anchor says this
operator, the logic is nobody else should be able to override it. If an
entity down the trust chain adds another operator, this should be
disregarded because the value operator has precedence over the others.
Mike: That goes against the principle of equal opportunity
Vladimir: In principle we allow every authority to contribute to policy.
However if the superior authority has made the choice to fix a certain
parameter then the subordinates should not be able to override it.
Mike: It should be an error if the subordinate attempts to
Vladimir: Yes. The overall objective of #177 is to make it possible to have
multiple trust anchors in federations and devise policies that would work
even when you can't satisfy all policies. However the metadata published by
the leaf entities could still satisfy these conditions. I tried to argue
this in the PR. Say we have a situation where we have a single trust anchor
and you're an authority somewhere down the trust chain. You would look up
the policy the trust anchor set and not try to add an operator or policy
that would conflict. However if you have multiople trust anchors and have
to consider multiple superior policies having this allowance would make it
possible for a given trust anchor policy to work without combination or
merge errors. It makes an allowance to let policies work in a wider set of
scenarios without breaking the hierarchy principle. The hierarchy principle
is whatever policy set by a trust anchor shouldn't be made more permissive
by an intermediate.
Mike: Sure but if the intermediate expresses something in conflict with
superiors that's inconsistent and should be flagged as an error not
permitted.
Vladimir: Yes that's one way to look at it
Niels: I think the point is to not permit it but to overrule it. By having
a value set at a trust anchor level it will disallow an intermiediate to be
more permissive. On one hand I would agree, on the other hand I dont think
you can assume you can always step in greenfield and build something
consistent. In the real world you will run in to inconsistent federation
topologies.
Mike: My point is if you try to apply an inconsistent policy it should
result in an error. Providing incentive to fix inconsistent policies.
Niels: There might be an inability to fix inconsistencies, that might exist
because there is a requirement within their local federation.
Mike: I'm being strident about this because we wrote down a clear set of
principles. All the parties in a trust chain have equal authority. Whether
the value came from an intermediate or a trust anchor the value has the
same weight.
Vladimir: It would be good to look at concrete examples, we haven't tested
this yet.
Mike: I don't want to take all of our time on this, is this written down?
Vladimir: No this is just an idea.
Mike: Can you write this as a comment in the PR or create a new issue, it
sounds like this will allow things that would previously have been errors
to not be errors, so this deserves discussion before moving forward.
Vladimir: Don't consider #177 yet

### Issue 178

https://github.com/openid/federation/issues/178

Mike: There were places where the language suggested using other forms of
registration rather than static registration like is usually done. Vladimir
also wrote a PR, 179
Vladimir: This is editorial, clarifies that federations that have OIDC or
OAuth entities can utilize other methods to register clients that use the
openid federation trust chain. They aren't limited to explicit and
automatic methods specified.
Mike: People should review this

Mike: Any other OpenID Federation topics? None

### Federation Wallet Architecture

https://github.com/orgs/openid/projects/1/views/1

Mike: The github feature "projects" can be used as a status board to drive
discussion around issues and pull requests. Giuseppe put in the time to
characterize his view of the outstanding issues for this spec.
Unfortunately he has a conflict right now otherwise would have been here.
Mike: Issue 19 https://github.com/openid/federation-wallet/issues/19 says
endpoint randomization should be closed. There was a lot of pushback in the
discussion prior to adoption. Therefore unless anyone has an objection I'm
going to close it on the call. Closed.
Mike: Issue 39 https://github.com/openid/federation-wallet/issues/39 will
assign Giuseppe
Mike: Issue 42, trust mark with intended usage.
https://github.com/openid/federation-wallet/issues/42 I think this is ready
for a PR to do this.
Mike: Anyone can speak up if you want to talk about something in particular.
Mike: 41 complex trust mark examples. I don't think this is controversial,
but I would want to see the text to see what people should gain from this.
Will mark as ready for a PR.
Niels: Looking at 41, these are some of the examples discussed in figuring
out what we would want in R&E. I wasn't aware he had taken it so far which
is good.
Mike: Niels would like to talk about the SURF architecture next week.
Mike: Issue 22. https://github.com/openid/federation-wallet/issues/22 In
order to make this actionable, we should file separate issues for each. We
should consider whether to do each of the things in the list separately in
their own issues.
Mike: Issue 37. https://github.com/openid/federation-wallet/issues/37
Status list for trust mark status checks.
Niels: I hadn't considered hooking trust marks into status lists. We are
mostly using short lived trust marks. It looks like there was more
discussion than what is written here.
Mike: Please note that in the issue.

Call closed.


---
Aaron Parecki
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250116/6aaf3ab9/attachment.htm>