Bump: Nobody else tries to establish a TLS 1.3 only server? Am I the only one picking up the best and most secure standards protocol version?

Hi @Boulzz, sorry for the late reply but my problem still persists. No response from Apple support.

@paweldd Thanx for the response, but that blog is unusable, no tags or other mechanisms to filter posts for server notifications and I am not going to scroll through everything. The specific post you've linked goes into the content, but I have the issue that I am not getting any notification at all, no matter which version I select. I somehow think that this might be due to my server accepting TLS 1.3 only, although Apple says everywhere that it supports TLS 1.2 and later.

We are also facing the same issues while trying to integrate. The documentation leaves out too many questions unanswered and we have to rely on the community and third-party information in order to implement anything to start with and yet, a lot of try-n-error will be coming up most likely. Simply the fact that we have to search for answers outside of Apple's documentation has already made us 3 times the time we originally had planned for this integration. The following is a review of the current documentation at Processing Changes for Sign in with Apple Accounts, respecting all pages it links to. Overview These notifications are JSON Web Tokens (JWTs) ... This is wrong. The content seems to be a JSON object with only one field named payload which contains the actual JWT. Set Up the Endpoint URL All JWTs arrive at the same endpoint URL. What exactly is meant by "all" here? The following information from Enabling Server to Server Notifications may have an impact here: A Server to Server endpoint URL can only be registered on a primary App ID. Combining those two, my interpretation of the sentence would be: Notifications for all apps within the same App Group, identified by the primary App ID, arrive at the same endpoint URL. That would clarify it a lot from the beginning, including resulting limitations. Also: Your server examines the JWT and performs work according to the type in the events array in the token. What do you mean by "examine"? I am pretty sure you're talking about Validating a JWT, but it would be really helpful to use industry standards terminology to avoid uncertainty at the readers side. Additionally, the events is not an array, so that is misleading information here. Open Questions: Which HTTP method will be used by Apple? Community says it is POST. Which concrete structure does the request body have? How stable is the request body structure? Which values will request header Content-Type have? Will request header Content-Length be correctly set? How large can the request body get? Is there a list of IPv4/v6 addresses or CIDRs available for allow-listing Apple servers as valid clients to this endpoint? Can Apples clients be reliably reverse-resolved via DNS to allow maintaining a dynamic allow-list? Which requirements need to be met by the endpoint response? Which HTTP status codes are respected by Apple? How does it behave in case of a 503 or other 5xx status codes? Does it follow redirects? What is the timeout for a request and how does Apple react in case of exceeding it? Is there any chance that Apple will refuse to send notifications to a specific endpoint URL and what are possible reasons? From where to get public keys for signature validation? Would also be nice if there was some reference to the fact that AppleID (at least at the moment) conforms to the OpenID Provider Configuration (see https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig - fun fact: this forum blocks URL's for openid.net, maybe because of previous debates) by providing the following well-known location: https://appleid.apple.com/.well-known/openid-configuration That tells us the location of the JWK Set for getting the public keys as well. Examples In section Process a User’s Email Forwarding Change we can see the following example (note the JSON syntax bug - I hope we won't see such things in real life): { "iss": "https://appleid.apple.com", "aud": "com.mytest.app", "iat": 1508184845, "jti": "abede...67890", "events": [ { "type": "email-enabled", "sub": "820417.faa325acbc78e1be1668ba852d492d8a.0219", "email": "ep9ks2tnph@privaterelay.appleid.com", "is_private_email": "true" "event_time": 1508184845 } ] } Now, according to the example that @MikeNV provided and from other community sources that is simply wrong, since the events claim is a string and not a JSON array. Open Questions: Will claim iss always be https://appleid.apple.com? Is claim aud an App ID? If so: Will it contain the concrete App ID? Will it contain the primary App ID? If so: How do we determine the specific app related to the notification? If events is a string, how to parse it correctly? Is it just plain serialized JSON? Is it base64 (URL-safe) encoded JSON? Is the decoded JSON guaranteed to be a single object? Which fields will events contain and what do they mean (apart from the incomplete examples provided)? Which values can the event type have and what do they refer to?