Release r1.1 (Release Candidate)

[PedroDiez]

What type of PR is this?

• documentation
• subproject management

What this PR does / why we need it:

Blockchain Public Address Release r1.1 (Release Candidate) PR (Spring25)

Which issue(s) this PR fixes:

Fixes #66
Fixes #63
Fixes #65
Fixes #64

Special notes for reviewers:

The following PRs MUST be merged prior to this one:

Update User Stories filename in #67
API Spec aligment with Commonalities and ICM in #69
Basic Test cases definition in #70
Generate API Readiness Checklist in #68

Changelog input

Release r1.1 (Release Candidate) for Blockchain Public Address API

Additional documentation

This section can be blank.

docs

[hdamker]

Hi @PedroDiez thanks for creating the release PR. I've created for the review camaraproject/ReleaseManagement#138, but seems we need to wait until the open PRs are merged.

The release PR

• touches also the YAML file(s), checklist, test definitions and set the right version numbers in all files
• the checklist could have been part of the release PR, as it describes the status of the repository at time of the release. A separate PR isn't necessary for that

Minor point:

• https://github.com/camaraproject/BlockchainPublicAddress/blob/main/code/API_definitions/README.MD should be deleted

[PedroDiez]

Hi @hdamker,

Thanks for the comments.

• Understood about API Readiness Checklist (will do in that way in the next releases)
• Have also addressed the README.md removal

[tanjadegroot]

this PR needs updates, and the other PRs should be merged before this on. this should be the last PR to merge.

[tanjadegroot]

Some updates needed and PRs still to be merged before the release PR can be merged.
gettting there :-)

[PedroDiez]

I will wait to make updates until merge of PRs

• API Spec Alignment with Commonalities and ICM - Release 1.1 #69
• API readiness checklist update for r1.1 #68

So i can also address some minor points (e.g. version and servers.url adaptation)

[tanjadegroot]

I will wait to make updates until merge of PRs

• API Spec Alignment with Commonalities and ICM - Release 1.1 #69
• API readiness checklist update for r1.1 #68

So i can also address some minor points (e.g. version and servers.url adaptation)

Please try to have that done this week.

[PedroDiez]

I will wait to make updates until merge of PRs

• API Spec Alignment with Commonalities and ICM - Release 1.1 #69
• API readiness checklist update for r1.1 #68

So i can also address some minor points (e.g. version and servers.url adaptation)

Please try to have that done this week.

Have manage comments. Waiting to merge #69 first and align branch

[tanjadegroot]

Mandatory template for 2 legged Auth is missing
PhoneNumber related errors (as defined by commonalities guidelines and in https://github.com/camaraproject/Commonalities/blob/r2.2/artifacts/CAMARA_common.yaml) seem to be missing

Also some further comments on API consumer facing documentation. API provider focused documentation should be in supporting documents.

[tanjadegroot]

Line 10. repleace "API family" by just "APIs", as the API family concept no longer exists in CAMARA.
If this API and its repository is part of a Sub Project? you should mention it here as well

[PedroDiez]

Ok, changed to "APIs".

In this case the Sub-proyect equals to The CAMARA Repository

[tanjadegroot]

Line 14.: "telco service providers have the opportunity to provide 3rd parties with the following capability"
Suggest to change to: "API providers offer API consumers the following capability"

[PedroDiez]

ok, done

[tanjadegroot]

You may remove the commented lines (as you used them below

[PedroDiez]

ok, done

[tanjadegroot]

there should never be a "main" in a link, only the release (in this case "r1.1") so this link should be:

** The Release r1.1 for the Blockchain Public Address APIs is available.

and I would put it just under the title.

[hdamker]

Just to make it explicit: the link to the release will be https://github.com/camaraproject/BlockchainPublicAddress/releases/tag/r1.1 (and will be valid only after the release got created)

[PedroDiez]

Thanks, i indicated wrong link

[tanjadegroot]

Suggested change

	* The release **r1.1 - rc** is available in [r1.1](https://github.com/camaraproject/BlockchainPublicAddress/tree/r2.1), and includes the following APIs:
	* The release **r1.1 - rc** is available in [r1.1](https://github.com/camaraproject/BlockchainPublicAddress/tree/r1.1), and includes the following APIs:

[hdamker]

The link to the release will be https://github.com/camaraproject/BlockchainPublicAddress/releases/tag/r1.1

[PedroDiez]

ok, done

[tanjadegroot]

line 18: "Notice that the mobile phone number used as input may even not belong to the same Telco Operator exposing the API. It is expected a communication between Telco Operators to resolve the Blockchain Public Address(es). For example a Telco Operator will receive the request, identify the Telco Operator which owns the mobile phone number, and forward the request using a 2-legged approach to contact the other Telco Operator."

This description is focused on the API provider, not the API consumer who does not want to know about the complexity between Telco's etc.

I would drop this whole paragraph

[PedroDiez]

Ok, done, understood the rationale.

[tanjadegroot]

Logically line 19 should go before line 17

[tanjadegroot]

line 19: Change "sub" to "user

[PedroDiez]

I will rephrase that.

[tanjadegroot]

line 22: before this section, you need tto include the mandatory text from Commonalities from this section:
https://github.com/camaraproject/Commonalities/blob/r2.2/documentation/API-design-guidelines.md#appendix-a-normative-infodescription-template-for-when-user-identification-can-be-from-either-an-access-token-or-explicit-identifier

[PedroDiez]

This is a template issued for APIs that may work in 2/3 legged in order to avoid the API Misuse implicitly exposing Number Verification feature.

The template has not been indicated because it is not the case for Blockchain Public Address. The rationale under it is indicated below:

• Perform a binding is a only 3-legged mode operation, and "phoneNumber" indication is required to enforce the procedure to ensure the binding process
• Remove a binding does not use "phoneNumber" as a input
• Retrieve a list of bindings may work in 2/3legged mode and always requires "phoneNumber" as an input to perform the logic.

[tanjadegroot]

on the endpoint description: please make sure that what is written about 2 legged / 3 legged is in synch with the lates commonalities.
You may also explain here any API specific errors returned.

see also https://github.com/camaraproject/Commonalities/blob/r2.2/documentation/API-design-guidelines.md#appendix-a-normative-infodescription-template-for-when-user-identification-can-be-from-either-an-access-token-or-explicit-identifier

[PedroDiez]

addressed in above comment

[PedroDiez]

Mandatory template for 2 legged Auth is missing PhoneNumber related errors (as defined by commonalities guidelines and in https://github.com/camaraproject/Commonalities/blob/r2.2/artifacts/CAMARA_common.yaml) seem to be missing

Also some further comments on API consumer facing documentation. API provider focused documentation should be in supporting documents.

Good point Tanja, let me explain below in this thread

[tanjadegroot]

@camaraproject/blockchain-public-address_codeowners - please proceed to release for M3 closure

[hdamker]

@PedroDiez removed myself from the reviewers as @tanjadegroot has already done the review for Release Management