A couple comments here:

1. The use of OpenId securityScheme (the never-ending topic haha)
2. I think we should have different scopes for each operation:
   • sim-swap:subscriptions:create for the Create operation
   • sim-swap:subscriptions:read for the List and Detail operations
   • sim-swap:subscriptions:delete for the Delete operation

Agree - fixed.

@bigludo7
if we already have the security property in every operation, the global security is redundant right? I think we can remove it

@fernandopradocabrillo Which one do you think we can remove ? I followed https://swagger.io/docs/specification/authentication/openid-connect-discovery/ pattern.

@bigludo7
We can have the security property in every operation or have it global. I think it is better to have it in every endpoint so we can specify the scope that applies to each operation properly

I know this is the same model we are using in Device Status but, and I would like your opinion here too, for me it does not make sense that the suscriptionDetail is optional. I should not be able to make the request without sending the details, what would be the response?

Yes got your point. As the subscription/notification is still 'fresh' I guess we're still testing it. I changed the cardinality to mandatory.

should we refence RoamingNotificationEventType here as well?

I will prefer not. If we list all event type in all API that will be complicated to maintain.
Perhaps we should provide 'somewhere' a listing of all event type managed within our CAMARA APIs?

But currently we list only exact one of them. API client must know what events it can receive and implement corresponding logic. One can keep the list open, but at least base type of events must be described. Events like "even notification subscription ends" and "MSISDN subscription ends" are critically important and must be included in the "base" list of event types.
All above if IMO :)

@gregory1g Thanks for the feedback
We have only one type for subscribtion but 2 type are managed by notification. Indeed org.camaraproject.sim-swap.v0.subscription-ends is also described in this yaml. We do not plan to provide subscription for this one and send them automatically once the subscription terminates (for any reason). This is described in the doc part.

We should add in this documentation than the same resource for subscription as notification are managed for all other CAMARA APIs.

ok.

"if the API server has to stop sending notification prematurely." sounds a bit unclear, what about using more simple wording like "if the API server has to terminate subscription (e.g. when the corresponding phone number is not served by the operator anymore)"?

Do we need independent scopes here?
From the end user privacy point of view, allow someone to subscribe to simswap is equal to allow someone to read simswap timestamp. Or, at least a permission to "subscribe" includes permission to read. Like end user revokes permission to read their SimSwap information, this logically also revokes permission to be notified about such events. This is an API specific logic, and it is too risky to completely delegate it to Auth/Consent configuration.

@gregory1g This is a fair comment. Could we consider from a privacy perspective that checking now is same than checking for a coming period of x days?
I tend to agree with you.
@fernandopradocabrillo @DT-DawidWroblewski : could you please provide your view here.

and isn't it possible to have permission to read but not to subscribe to the notification?

permission to read, but not to subscribe is rather questionable, but still could be needed.
however, permission to subscribe without permission to read sounds like an dangerous security inconsistency

as mentioned above "NETWORK_TERMINTAED" covers a server side termination for whatever reason. Two questions here:

1. Is "NETWORK_TERMINTAED" a self-explaining term for a server initiated termination? One can expect that user terminated is different from network terminated.
2. shouldn't we add a possibility for an MNO to provide an optional a human readable text description explaining the reason behind server side termination?

1. Not sure to get it. You want me to add USER_TERMINATED ?
2. Yes make sense - I've add a terminationDescription attribute.

1. I dot think that we need to be introduce "user terminated" here. But NETWORK_TERMINTAED sounds too narrow. I suggest to consider a more generic term which covers everything which is initiated by the server side, either it is network as such, or user his/her self, or contract between application and MNO or even security conserns.

What about subscription ID, shouldn't it be included in the event as well?

Yes - It should be part of the Data structure - I add it.

Yes - It should be part of the Data structure - I add it.

1. Not sure to get it. You want me to add USER_TERMINATED ?
2. Yes make sense - I've add a terminationDescription attribute.

Hello @gregory1g
For me the simswap and the subscription are 2 different entities. As subscription is a distinct entity it makes sense to have distinct scope to manage it but worth to be discussed.
As we should have same discussion in subscription for device location and device status probably better to bring this discussion to commonalities.

If a user revokes their "read my SimSwap info" for app XYZ, it is Telco commitment to terminate app XYZ subscription (if any) and prevent any sim swap data sharing with XYZ.

@bigludo7
One doubt here, in case I've missed something, why do we have the phoneNumber as optional in the request body?

And, even if we have it optional in the request, shouldn't it be required in the response? I think the response must give the complete information of the subscription. Applies the same for the GET endpoints

Yes make sense for POST & GET answers --> I've updated.

For POST request, the phoneNumber could be optional as we can have it by the network thru Authorization code flow or CIBA flow.

Typo:

is:
org.camaraproject.sim-swa.v0.subscription-ends

should be:
org.camaraproject.sim-swap.v0.subscription-ends

Grammar issue:

is:

This notification did not requires dedicated subscription.

should be:
This notification does not require a dedicated subscription.

should we have an explicit email to sub-project owner here?

Not sure - I followed here what we have in other API but this is a fair question.
My suggestion is to have an issue in Commonalities to have a common rule.

I think here we should use the following URL:
https://github.com/camaraproject/SimSwap

is there a dedicated security scheme for notifications? or are we following CIBA and use push mode see CIBA spec for reference?

Not sure - I've replicated same thing than in other Subscription API. If we want to provide more we should probably propose someting here: https://github.com/camaraproject/Commonalities/blob/main/documentation/API-design-guidelines.md#security-considerations

Roaming notification in sim swap API? is it a new enhancement coming with sim swap notification?

ah ah ah ... no :) good catch Dawid. I've wrongly name this class and forget to use it (2 errors on a same line). I fix it.