Add protocol version and variant identifier

[Nat Sakimura]

It probably is a good idea to have a parameter to state that the messages involved is for FAPI v.2 Baseline so that appropriate verification can be invoked by the receiver of the message, especially as it is there v.2.

[Dave Tonge]

I like this idea in principle, but I’m worried about it in practice.

How would we pass this parameter in the following exchanges:
- PAR
- Token Request

would there just be a parameter sent in the form post, e.g. version=fapiv2baseline

would we need to register that parameter here: https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#parameters

what would the AS do differently when it receives that parameter.

would we also need to register the parameter for use as authorisation server metadata and client registration metadata?

[Brian Campbell]

Probably a good idea in principle but I’m similarly concerned about what it would mean in practice for for FAPI. There are a lot of questions in the details and I fear trying to shoehorn something in would do more harm than good.

[Joseph Heenan]

I think it was kind of hinted at in one of the recent calls that perhaps a DCR/DCM key/value to indicate fapi & version thereof could be one way forward.

Having thought about that a bit I do kind of like the idea - for a server that’s supporting multiple use cases having a client able to say “I want to do fapi2” when it registers can be a handy shortcut to correctly setup the client. (I think some servers are kind of doing this today by inferring what security profile the client will be required to do based on the scopes the client requests in the DCR request, but that doesn’t work so well in a RAR world probably.)

[Takahiko Kawasaki]

It is helpful to implementations of endpoints (such as authorization endpoint, token endpoint, dynamic client registration/management endpoint and backchannel authentication endpoint) to provide a request parameter that indicates which profiles should apply when the request is processed.

If such request parameter is developed, it should be able to contain multiple values. For example, like profiles=fapi1advanced+openbankingbrasil. In addition, the request parameter should be generic enough for various endpoints to be able to accept. The RAR specification defines authorization_details and states that the parameter can be used wherever the scope parameter can appear. We may be able to learn how to define a generic parameter from the RAR specification.

[Takahiko Kawasaki]

Implementations of the DCR/DCM endpoint of Open Banking Brasil must reject requests when the root certificate of the client certificate is not one issued from the OBB authority. The conformance suite actually tests the requirement. A generic-purpose AS implementation cannot conform to the requirement directly, so a custom AS implementation has to branch from the generic implementation of the certificate requirement must be processed somewhere else such as at a reverse proxy.

If a DCR/DCM request includes a new request parameter like profiles=openbankingbrasil, AS implementations will be able to support OBB without branching.

[Anoop Saxena]

One option we can explore is profile and sub-profile. Profile for FAPI defined ENUMs (Basic, Advance etc). This can be registered at the time of DCR/DCM step. Sub-profile can be region specific and can be open string to give flexibility for each region to define .

[Dave Tonge]

Moving issue to DCR/DCM component

[Nat Sakimura]

Issue #598 was marked as a duplicate of this issue.

[Joseph Heenan]

Discussed on today’s call - there’s no current impetus to make progress on the DCR/DCM spec - the new FAPI ecosystem that was looking to adopt DCR/DCM seems to be going in the direction of using OIDC federation instead, so this doesn’t seem to be a priority for anyone (the working group’s time is probably currently more usefully spent on the implementation & deployment advice document and getting FAPI2 to ‘Final’).

[Dave Tonge]

we discussed on the call that DCR/DCM is not as important as getting FAPI2 to final and getting the Implementation advice document completed. We will leave this on the backlog