1. OpenID Foundation Avatar OpenID Foundation
  2. WGs
  3. connect
  4. Issues

[Federation] Rename "Automatic Registration"

Issue #1588 resolved
Kristina Yasuda created an issue

Clients do not receive client_id and optionally secrets after “automatic registration“ in Federation specification, right? If so, I think a term “registration“ is misleading. We use this mechanism in OpenID4VP/SIOP v2 specs and prefer to call it just-in-time metadata exchange. would be good to align.

Comments (30)

  2. Giuseppe De Marco

    I support the concept of just-in-time metadata exchange without the involvement of the meaning of registration

  3. Giuseppe De Marco

    considering how federation works the registration is adopted in the OP that evaluate the RPs (if automatic client registration or explicit one)

    So I support the concept of the metadata exchange in OIDC4UC but in OIDC Federation we have some solid links to the OIDC client registrations

    this is a very interesting point, but I don’t believe that we should change the approach of OIDC Federation but instead create a specific profile of OIDC Federation for OIDC4UC if you agree

  4. Giuseppe De Marco

    a step going in this direction has been proposed here
    https://bitbucket.org/openid/connect/issues/1534/federation-trust-mark-hint-in-the-authz#comment-63911375

    where an RP may send its entity configuration (metadata) as a claim value of the signed request object. But, anyway, standing on how oidc federation works, the concept of client registration is important because it’s statefull, the OP won’t evaluate on each request the trust chain to the requestor

    the registered client in oidc federation correspond to a not expired trust chain, the final metadata is taken from this

    for legacy implementation that “decorates” themselves with oidc federation this may assume a more important implementation constraint, due to the need that they really need to push a metadata in a legacy metadata store containing all the registered clients

  8. Giuseppe De Marco

    @kristina is this this “autonomous” a typo? We only have automatic client registration and explicit client registration

    @tobias the client discovery maybe covered by metadata discovery? It can be for both client/RP/AS/OP

  9. John Bradley

    @kristina there is no clientID returned because it is included in the request, no secret because the client is registering a key that is persisted by the AS. This is more like registration than an ephemeral pairing.

    This will trigger a number of operations on the AS side so could be used as a denial of service and that also needs to be considered.

  11. Giuseppe De Marco

    @kristina regarding what John said we have some elements in the security considerations that exposes how a metadata disveory can be exploited to do resource exhaustion (considering kernel’s tcp backlog and somaxconn) or DDoS

  12. Roland Hedberg

    To add to what @John Bradley said, the end result from the OP’s point of view of a client using automatic or explicit registration is the same: the OP has somewhere stored away the fact that this is a client it, for the foreseeable future, will accept as someone that can use its services.

    Hence, both are examples of registration.

    ‌

  13. Tobias Looker

    I think there is a difference between recording an interaction with a client and establishing a record for a client you expect to see again. For example in the automatic registration model, does this mean every time a client makes an authorisation request using automatic registration, they are re-registering with the AS or does registration only apply to the first request? Its situations like this where the language tends to break down for me and hence why client discovery feels like a more fitting term.

    @Giuseppe De Marco I'm unsure what you mean by metadata discovery? However if you are noting that client discovery is just like provider discovery in reverse, then yes I agree with you.

    ‌

  14. Giuseppe De Marco

    @tobias on the first authz request: metadata discovery, truch chain building, metadata policy and finally the final metadata to be registered.
    then the trust chain expires and need to be periodically updated (or doing it on the next request, it’s an implementation option)

    the point is that we really have to prevent to start a new metadata discovery on each http request, this mechanism may represent a vector of propagation attacks, the amplification is 1 request triggers at least 3 request, or 5 or more, it depends by how many intermediary and how many authority_hints the entity configuration has.

    so registration happens only in the first time, and then may be updated in every moment to assure that the metadata will be always fresh.

    the metadata discovery is an hierarchical walk, from a leaf up to the trust anchor, quite different by the single http request to a static metadata as it is in openid-configuration

  15. Michael Jones

    On the 11-Aug-22 working group call, @John Bradley described that registration does occur. And in particular, upon subsequent use of the client_id, the server will likely not refetch the metadata from the entity statement, unless it has expired.

    Kristina said on the call that it would be useful to clarify how this use of the client_id differs from other kinds of registration. @Vladimir Dzhuvinov agreed.

  17. Tobias Looker

    the point is that we really have to prevent to start a new metadata discovery on each http request, this mechanism may represent a vector of propagation attacks, the amplification is 1 request triggers at least 3 request, or 5 or more, it depends by how many intermediary and how many authority_hints the entity configuration has.

    so registration happens only in the first time, and then may be updated in every moment to assure that the metadata will be always fresh.

    I understand and agree with these points the provider should not have to resolve the clients metadata each time if it has previously cached this information. I still believe framing this overall concept as “client discovery” vs as registration is more accurate. For instance we dont speak of provider registration when a client is first made aware of a new one, nor do we require client implementations to perform discovery on a provider that the client already knows (in fact provider discovery is entirely optional).

    The problem with the terminology of registration here is that it doesn’t match what is going on, for instance as you highlight the provider may periodically update their view of the client (by refreshing the client metadata they have cached for it), is this process re-registration? It makes more sense to frame the client as discoverable to the provider instead and for the provider to be free to remember it has seen the client previously to circumvent the need to resolve their metadata and validate it on each authorization request.

    ‌

  18. Giuseppe De Marco

    I can understand the semantic of the term client discovery, at the same time I’m aware that the term metadata discovery is a general term that covers the discovery operations for every kind of participant, if RP or OP or RS or any other. Furthermore in OIDC Federation a participant may be more than a single implementation, it may, for example, be at the same time a RP, a RS and a OP (and others).

    For these reasons the term client discovery may sound too much reductive in relation of the scopes, completely general, of the Federation spec.

    From an implementer point of view a client “registers” a AS/Provider because it evaluates and caches the trust chain related to this latter. An RP discovers all the OPs thanks to the listing endpoint (Federation API) and then evaluates the trust to each of them, before representing to the users the discovery page with all the authentication services (AS/OP) availables in a Federation. Having said this, well, the RP registers all the news OPs, periodically, without any human operations on its backend, this may be completely automatic if the implementation is smart enough. Considering dozens of OPs, well, the cache is a concrete implementation requirement in the real world that justifiy the term “registration”.

    At the same time an OP needs to register a Client because on Token endpoint, but also on the introspection one, it has to check the originating authz session and the client that started this latter (considering for instance the private_key_jwt that relyies on the sole client identity). Using a “client registration” in term of persistent information, an OP is able to avoid the metadata discovery and trust chain evaluation on each request to each of its endpoints, relying to the registration data only in a considerably adequate period of time (cache).

    the trust chain update/renewal for a RP, made by an OP, is not a new registration but a check that assures the data as fresh. To get this done the OP discovers again the RP metadata, starting from the .well-known/openid-configuration of this latter (entity configuration) and traveling the old path or a new one to build the final metadata.

    I’m aware that the term client registration has its story with the traditional implementation of oidc dynamic client registration, that in oidc federation has been definitively extended. I’m also aware that in SIOPv2 we abandoned the term registration in favor of client_metadata, change I supported with joy, and that for this latter we don’t know how the implementations of this will works, if they definitively will registers the RPs and periodically updates these, on each requests, or differently if they will save a new metadata linked to each authz request every time. But I believe that is an implementation aspect that we won’t cover in the specs not even under torture.

    Well, coming back to the scope and proposal of this issue, we made the following assumptions:

    • oidc federation relyies on entity configurations and statements and not to absolute metadata
    • oidc federation give a method to build dinamically a metadata, the trust verifier builds this latter by its own
    • the metadata is completely relative to the federation where it can be resolved to
    • the metadata are not exchanged between two entities, from an RP to an OP for instance. The metadata is a result of many exchanges from and to many parties, that carries statements as builing block of the final metadata
    • OIDC Federation may be implemented on top of legacy oidc implementations that relying on metadata storages (client registration schemas). The removal of the term “registration” could create interpretation difficulties for implementers who already have a legacy background
    • OIDC Federation proposes a standard way to “discover the trust” with roles and higly specialized endpoints

    my ideas:
    - even if SIOPv2 has defined client_metadata and an RP pushed this in its authz request, the trust verifier (OP) should check the compliance of this RP towards one or more trust framework and this represents in a way or another a kind of discovery (that costs one or many http requests) that can be exploited for propagation attacks without a cache (registration).

    • from the etymological point of view the registration of an event is also a logging implementation, registration means taking act in the form of material memory, so a Wallet may log all the RPs served in a time window to give to an user an overview of its usages and audiences, it registers all the RPs asking for something on a timeline with a retention policy.

    My question:
    What’s the claim of this Issue, may we rename “registration” concretely to what concrete alternative? Let’s do an exercise, I’d be vey happy to get Federation and SIOPv2 closer.

    My proposal:
    https://bitbucket.org/openid/connect/issues/1594/federation-trust-chain-in-authz-request
    it enables the possibility to push the chain of the statements involved in the trust chain, verifiables, and resolves by desing the problem of temporary disalignment of the metadata. It also reduce the effort OP side in establishing the trust, as @John Bradley mentioned, this is similar to OCSP stapling and wants to reduce the overall costs.

  19. Tobias Looker

    What’s the claim of this Issue, may we rename “registration” concretely to what concrete alternative? Let’s do an exercise, I’d be vey happy to get Federation and SIOPv2 closer.

    In general, in OAuth2/OIDC (forgetting federation for a second) we have two predominant patterns around client management that I see:

    • An out of bound pre-registration flow, where a client is registered often via an administrative process and assigned a client ID the client then uses
    • A dynamic registration flow where the client registers itself and obtains a client ID it uses in later flows.

    Beyond these I believe the language around registration breaks down as the client isn’t being assigned an identifier through a registration process, instead its just saying “this is me, learn more by resolving my metadata document”, the resolving party an OP/AS can cache this resolved result or fetch it each time, that is its per-view. The action however of resolving the clients metadata and then deciding whether to proceed with the transaction isn’t registration IMO. Therefore I believe the language or concept we are looking for here is more accurately captured as a “discoverable client” or “client discovery”.

  20. Tobias Looker

    +1 in general though @Giuseppe De Marco to resolving the differences between SIOP v2 and federation so we have one way of achieving this rather than multiple that are similar in their intent.

  21. Michael Jones

    As @John Bradley wrote:

    This is more like registration than an ephemeral pairing.

    And as @Roland Hedberg wrote:

    Hence, both are examples of registration.

    I believe that there’s consensus, at least among the OpenID Connect Federation editors, that “Automatic Registration” is correctly named.

    For context, I’ll also note that “Dynamic Client Registration” is the OAuth term used, and OpenID Connect Registration https://openid.net/specs/openid-connect-registration-1_0.html uses the same term. Using a different term would likely cause more confusion than it would solve.

    Also, for context, given Tobias' questions, the term “Discovery” often refers to the process of what SAML called “Home Realm Discovery” - determining what IdP to use. That’s in Section 2 https://openid.net/specs/openid-connect-discovery-1_0.html#IssuerDiscovery of the OpenID Connect Discovery spec. Whereas Sections 3 and 4 define OP metadata and how to obtain it after discovery has completed.

    I hope this naming context helps us all get on the same page.

  22. Giuseppe De Marco

    @Michael Jones yes, the sentiments tell us that registration is a legacy term, linked to a tradition and a language now common in the OAuth2 / OIDC world. I also believe that it won’t change in OIDC Federation.

    @Tobias I agree that in OIDC Federation the automatic client registration sounds more like a non-registration. The Client presents itself with its client_id and I believe that the term registration is only a strategy to make it more understandable, like an anchor to the past, that’s the term registration itself. But, I have also to admit that the OP saves in a storage (so, let’s say registers) the trust chain and the final metadata, that’s a sort of extended and completely different kind of client registration, with federative contexts and a retention policy defined by the Federation spec as well (exp of a trust chain, that’s mandatory). So I can still see the registration process in a concrete implementation, even with a different manner, even if we’ll remove the term registration or change it.

    In SIOPv2 we have a different approach, the client/rp makes its metadata available during the request (soon in oidcfed will have something similar but not a metadata, a statement chain self evaluated by the client and related to itself, see related issue). Well, the SIOPv2 would register this client/rp or not? I believe that’s an implementative design.
    Why SIOPv2 pushes it’s metadata instead of a client_id only? The answer would be: for offline and/or cross devices usecases without any wallet cloud backend as intermediator (a smartphone that doesn’t have any public endpoint and so on …). In OIDC Federation this wouldn’t be possibile, the trust needs online services and highly availables APIs, just designed for this.

    let’s say that “registration” may mean the first succesfull evaluation of a AS/OP regarding a client/rp that produce a kind of persistence for operational or logging purpose. The client/rp doesn’t ask for a registration, it only give its metadata, it’s up to the OP decide if the client should be registered or not. So I fully agree to leave the paramenter client_metadata in SIOPv2 as it is and also call it registration OP side, if this latter will establish the trust to that metadata before registering it.

    Having said this I believe that in oidc federation we’ll keep the term registration for legacy reasons, even if the automatic client registration is only a client_id-giver method, and also for the evidence of the implementative aspects, those merely technicals.
    In SIOPv2 we don’t have any sentiments that links us to the past, so we pushed the metadata in a new paradigm of interactions and trust negotiation, that considers new use-cases, assumptions and costratints. Well, in both cases the registration is made implicit OP side, even if it will be in memory only, the authz session needs persistence, even for few seconds, this means that the client will be registered anyway.

    probably you’re are saying <<let’s call it in another way>> but, at this point, it sounds more like a cosmetic claim than a real need. Well, the SIOPv2 will register or not the client/rp? I think it’s not in the specs but, in the real world probably it will. Am I mistaken?

  23. Michael Jones

    This was extensively discussed during the 15-Aug-22 working group call, as recorded in the minutes. There was consensus to close this in a week unless a compelling reason is identified to keep it open.

  24. Kristina Yasuda reporter

    I am not ok closing this issue without an action. If we are not changing parameter name, at least there needs to be more clarification text how this “registration“ is different from registration (DCR/out of band) that developers are used to:

    1. No need to do any step prior to the authorization request (DCR or out of band mechanisms)

      • → with “automatic registration“, include entity statement in Authz Request

    2. Usually, there is no verification that it is actually entity A (and not an attacker) registering entity A’s metadata

      • → with “automatic registration“, an entity registering metadata needs to control entity A’s domain

    also John mentioned that AS will assign a re-usable client_id to the clients who did “Autonomous Registration” - I am sorry if I missed it, but would be great if someone could point me to the specification text describing this. Because I personally think that there is no need for an AS to do so. AS just accepts URL in the client_id in the Authz Req as that client’s client_id. attacker trying to reuse victim’s client_id is not really an attack vector because attacker will just have to use the same metadata as the victim. and AS will just have to fetch Entity Statement once in a while according to its policy or when step-up authentication is needed.

    someone during the last week’s call mentioned that they shared the same confusion described in the issue, but once they started implementing it was easier because it felt closer to the usual registration. I think this is exactly the experience we should prevent because autonomous registration is different.

    ‌

  25. Michael Jones

    I think John was talking about a possible implementation strategy, not a normative requirement.

  26. Giuseppe De Marco

    I love the action!

    1. No need to do any step prior to the authorization request (DCR or out of band mechanisms) → we include the trust chain as all the statements that compose this, not only a single statement

    2. Usually, there is no verification that it is actually entity A (and not an attacker) registering entity A’s metadata. → I think that this is impossible, because an attacker should control the web service of the victim, considering that the entity configuration is hosted on the .well-known/openid-federation endpoint and also the attacker should be in possession of the private key of the victim, because the request object or the private_key_jwt in PAR or mTLS, during the authz request, must be signed. The trust chain brings the proof of the public key in possession of the RP, this is available in the entity statement of the superior.

    I’d push asap the trust_chain parameter in the authz request and we may also consider to add some explanatory text regarding the client registration, well, during automatic registration the client is completely unaware if the OP will register it or not, it simply pushes its authz request. I love this.

    ‌

  27. Michael Jones

    I believe that the Automatic Registration section at https://openid.net/specs/openid-connect-federation-1_0.html#name-automatic-registration already does some of what you’re asking for, Kristina. It describes how Automatic Registration works and how it’s different than traditional Dynamic Client Registration. For instance, it opens by saying that “Automatic registration allows an RP to send Authorization Requests to an OP without first registering with the OP.“

    That would be the place to put any additional descriptions of the differences that we feel would be useful. I’m also fine with that resolution.

  28. Michael Jones

    Per the 19-Aug-22 Federation Editor’s Call, Mike will create a PR incorporating the clarifications in the description of Automatic Registration that Kristina suggested.

  31. Log in to comment
Assignee
Type
bug
Priority
major
Status
resolved
Component
Federation
Milestone
–
Version
–
Votes
0
Watchers
1
Jira: the preferred issue tracker for Bitbucket. Join the team!