Added sequence diagrams with RFC 9101

[mhfoo]

What type of PR is this?

Add one of the following kinds:

• documentation

What this PR does / why we need it:

Implement RFC 9101 for securing the /authorise endpoint.

Which issue(s) this PR fixes:

Fixes #93

Special notes for reviewers:

Please review the diagrams and provide your comments.

Changelog input

 release-note
Update diagram to reflect RFC 9101

Additional documentation

This section can be blank.

docs

[bigludo7]

Hello @ECORMAC
Any update on this?
I've noted to wait from feedback from you before to move forward.

[ECORMAC]

Hi Ludovic,
My apologies for the dealy. Checked the last flow done by Ming (simplified showing the aggregator etc.). I think it looks good now. Good-to-go from my side.
Thanks,
Cormac

[bigludo7]

/LGTM

[fernandopradocabrillo]

Hi, I've checked with my collegues from Identity and there are a few issues we are yet not sure about:

1. The request object according to RFC 9101 is not yet in the CAMARA ICM profile. It will probably be but, for now, is not yet approved,
2. The max_age param does not make sense in this flow since network auth must occur for every authorization. See previous comment
3. The way the scopes and purposes are sent is not the one appoved for the current version of ICM in CAMARA.
4. In general, aggregation or federetion should be out of the CAMARA scope. It is something defined in Opengateway, in CAMARA the API consumer could be the BE of an App or an aggregator, but CAMARA is not involve in how the routing should be or if there is or not a Telco Finder, etc. It is an entity defined in Opengateway.

The main thing here is that, even being a Telefónica's proposal, the use of RFC9101 hasn't been defined or agreed at CAMARA level yet, so I think we should at least wait for the ICM resolution and then continue with this topic.

[bigludo7]

I'm not sure how to move forward on this... @mhfoo @fernandopradocabrillo @ECORMAC @AxelNennker any suggestion?

[mhfoo]

I'm not sure how to move forward on this... @mhfoo @fernandopradocabrillo @ECORMAC @AxelNennker any suggestion?

@bigludo7 The intention is to raise it again for Spring25 meta-release. see ICM issue #128

I will create the issue in ICM again, before 30 Sept and add to the following:
ICM 0.3.0 - preparing the scope for meta-release Spring25

[ECORMAC]

I'm not sure how to move forward on this... @mhfoo @fernandopradocabrillo @ECORMAC @AxelNennker any suggestion?

@bigludo7 The intention is to raise it again for Spring25 meta-release. see ICM issue #128

I will create the issue in ICM again, before 30 Sept and add to the following: ICM 0.3.0 - preparing the scope for meta-release Spring25

@bigludo7: As Ming states think we agreed earlier to deal with this in the Spring release.

[mhfoo]

to update this PR based on the following: ICM PR 226

[hdamker]

Please be careful with this PR ... within the proposed public release of ICM 0.3.0 is a direct link to https://github.com/camaraproject/NumberVerification/blob/main/documentation/API_documentation/assets/uml_v0.3.jpg which must be resolved there before you can proceed here with the PR (as this PR would delete the picture).

[hdamker]

cc: @camaraproject/identity-and-consent-management_codeowners

[bigludo7]

I'm not sure about the status of this PR. We have it for a long time and we hadn't got a consensus from the WG to merge it.

I see a lot of value of this contribution as this is really good documentation but of course as mentioned by @hdamker it must be fully compliant with ICM work.

[jpengar]

Please be careful with this PR ... within the proposed public release of ICM 0.3.0 is a direct link to https://github.com/camaraproject/NumberVerification/blob/main/documentation/API_documentation/assets/uml_v0.3.jpg which must be resolved there before you can proceed here with the PR (as this PR would delete the picture).

@hdamker Fixed on ICM side. See camaraproject/IdentityAndConsentManagement#269 (comment). I think just replacing the existing link with the root path of the number verification repository would be fine IMHO. Including the image here would create dependencies between repositories (e.g. to ensure the image is up to date and so on) that I think are simply not needed in this case.

[AxelNennker]

Why do we need this PR?
Github introduced mermaid support in February 2022. NumberVerification can integrate all diagrams directly where needed.

Dependency of ICM to this PR is resolved on ICM side. Up to the team here how to proceed with he PR.

[hdamker]

Again me ... during the creation of the PR for r2.2 (#169 to resolve #168) I've seen that the API description had also a link to
https://github.com/camaraproject/NumberVerification/blob/main/documentation/API_documentation/assets/uml_v0.3.jpg.

Within the release PR I changed the link to https://github.com/camaraproject/NumberVerification/blob/r2.2/documentation/API_documentation/assets/uml_v0.3.jpg to avoid that this link will be broken in the future.

Please consider how to continue with this figure and the PR.

@AxelNennker

Github introduced mermaid support in February 2022. NumberVerification can integrate all diagrams directly where needed.

The YAML isn't only presented in GitHub (btw: GitHub is not rendering YAML files), but e.g. also in Redoc, Swagger or other places outside of GitHub. For that you need a link to a picture file I suppose, but if all these tools can present mermaid ...

[mhfoo]

Suggestion to use different filenames and not overwrite the previous valid image.

These sequence diagrams are to explicitly indicate that the signed request should be performed on the backend server.
There were questions from the community on how standalone and federated flows should be.