@DTS Engineer Thanks for the answer, will it be the same case for URL Filter Network Extension as well. As we also want to collect stats data for the URL Filter Network Extension about how many URLs are blocked by the filter.

Yes, I have added apple.com/url-filter-test this entry in the PIR DB but as you can see prefix www was missing previously so is it the reason that they were not able to find it. We have validated this using our iOS app, by hitting the URL in the browser as well as we checked the input.txtpb file contents for the running PIR server.

@DTS Engineer Good thing I resubmitted the request yesterday by fixing above issues and we got another feedback from apple side for our new request PIR server responded, but the canary value is not in the dataset. "www.apple.com/url-filter-test" should be set to 1 So we have validated this using our iOS app pointing to same environment and it is blocking this URL as per expectation as well as we have validated this using below curl docker exec pir-server sh -lc 'grep -n "www.apple.com/url-filter-test" /pir/data/input.txtpb; ls -l /pir/data/input.txtpb /pir/data/url-0.bin /pir/data/url-0.params.txtpb'; curl -sS -i https://ohttp.protectuswebfilter.com/.well-known/private-token-issuer-directory | sed -n '1,40p' Please help us, how they are validating this entry is available or not

Thanks for the answer @DTS Engineer, just to confirm for issue number 1, When I try to hit below curl on my machine curl -v https://pir.protectuswebfilter.com/.well-known/private-token-issuer-directory I am getting below response racit@RACITs-MacBook-Pro ~ % curl -v https://pir.protectuswebfilter.com/.well-known/private-token-issuer-directory Host pir.protectuswebfilter.com:443 was resolved. IPv6: (none) IPv4: 13.74.252.44 Trying 13.74.252.44:443... Connected to pir.protectuswebfilter.com (13.74.252.44) port 443 ALPN: curl offers h2,http/1.1 (304) (OUT), TLS handshake, Client hello (1): CAfile: /etc/ssl/cert.pem CApath: none (304) (IN), TLS handshake, Server hello (2): (304) (OUT), TLS handshake, Client hello (1): (304) (IN), TLS handshake, Server hello (2): (304) (IN), TLS handshake, Unknown (8): (304) (IN), TLS handshake, Certificate (11): (304) (IN), TLS handshake, CERT verify (15): (304) (IN), TLS handshake, Finished (20): (304) (OUT), TLS handshake, Finished (20): SSL connection using TLSv1.3 / AEAD-AES256-GCM-SHA384 / [blank] / UNDEF ALPN: server accepted h2 Server certificate: subject: CN=*.protectuswebfilter.com start date: May 14 00:00:00 2026 GMT expire date: Nov 28 23:59:59 2026 GMT subjectAltName: host "pir.protectuswebfilter.com" matched cert's "*.protectuswebfilter.com" issuer: C=FR; O=Gandi SAS; CN=GandiCert SSL certificate verify ok. using HTTP/2 [HTTP/2] [1] OPENED stream for https://pir.protectuswebfilter.com/.well-known/private-token-issuer-directory [HTTP/2] [1] [:method: GET] [HTTP/2] [1] [:scheme: https] [HTTP/2] [1] [:authority: pir.protectuswebfilter.com] [HTTP/2] [1] [:path: /.well-known/private-token-issuer-directory] [HTTP/2] [1] [user-agent: curl/8.7.1] [HTTP/2] [1] [accept: /] GET /.well-known/private-token-issuer-directory HTTP/2 Host: pir.protectuswebfilter.com User-Agent: curl/8.7.1 Accept: / Request completely sent off < HTTP/2 200 < content-type: application/json; charset=utf-8 < date: Wed, 24 Jun 2026 12:48:36 GMT < server: nginx/1.24.0 (Ubuntu) < content-length: 1511 < Connection #0 to host pir.protectuswebfilter.com left intact {"issuer-request-uri":"/issue","token-keys":[{"token-key":"MIIBUjA9BgkqhkiG9w0BAQowMKANMAsGCWCGSAFlAwQCAqEaMBgGCSqGSIb3DQEBCDALBglghkgBZQMEAgKiAwIBMAOCAQ8AMIIBCgKCAQEAtX6p_XKIg8xY-EDlD4y06FeZZLPJShlRRH_vJYPGunXpYceKU5g61FSFhMGkrOdYfPCvlWCfSkw7oQxP8lWVXfkudyfhXfXEfcathI0K11kukG3SRao6thT25WJQHTyYA3qCOHTwDFKxPZKovhJPEm4Vh4Z2N79czb_FnJ38nUc08j9xZvU5A95rPhwRxhgjUJbEVXu30N18q_U9NbaqT7n5aQsIuXd8FJnOS4jxqDk6Bz3Rc2sWEYnOGFEDTkeBZUmpyESjzzAr6uqkGRsPEikwfDkfYhc7JAeTgGYIxzf6POWvkwqWq0BKGRSjzXyD2tXOj3DM1jlnmGuipkANVQIDAQAB","token-type":2},{"token-key":"MIIBUjA9BgkqhkiG9w0BAQowMKANMAsGCWCGSAFlAwQCAqEaMBgGCSqGSIb3DQEBCDALBglghkgBZQMEAgKiAwIBMAOCAQ8AMIIBCgKCAQEApx-w6NSCZYwjdGe-aYlyn7mAeeIi6VvwmS1C5ACdQciSA2fscOxv5YWBmPbYXAJSZ9ZnI_1OhrBS5l-45dugDSa4Ecoo7xntfUp72WC62MrLhJ-XcqwF8zjiso6DFYBNW8kfXjZNIHvg1Q91b8Rci4_2Lo95ULe_5mf3CmdsqeE8dY4quMM0e_nlXjxMgSWEaDmWDIiBGVHKTAhZxwEuGIkSfL6XjbVumcM5iapXr180dtna6Squi-vLcocOXal-G9zqw7JeOLDiQaRacF0IfxG-SptdfuwlyEUyhB8-drkbpvdZsodnAl3PbFoWTdOSoEi3N2gYkDcw87mX9KUyCQIDAQAB","token-type":2},{"token-key":"MIIBUjA9BgkqhkiG9w0BAQowMKANMAsGCWCGSAFlAwQCAqEaMBgGCSqGSIb3DQEBCDALBglghkgBZQMEAgKiAwIBMAOCAQ8AMIIBCgKCAQEA5XCgFDOQJwyvM_9DB4BBjlkphYvT1-2q0ZN45fUP3kVGQPTSUa40cL588u_QTG55HKc3BtLkk_n6BhjFIaKRnk8M-muh-_ytyi7lyp2g7L5rHXa-O6UqfY-6Nt-31l9RkQk1bP7Ccu-AtUUeuTnYoRThrJ_022OLwktnZfWetkwoMw9QaiM2NcAFb7pVTdvJ573S4AAN9hmoI82C49H1Cgjo3l9REDUrMougci_6ul3efFVsVf2dYKsxvddgw7Rp60p80tTKXhrVxyfSJvPgAYWbwfK-8mLEX72sLwIYhmx_D-imdWFE7KsQxTwpmYZCi6tF-yungRC3AxLXzgLDNQIDAQAB","token-type":2}]}% So that is what review team is expecting correct ? where as in previous request I provided privacy pass issuer token url protectuswebfilter.com and it was responding 302 response code.

Hello @DTS Engineer, As I submitted my onboarding request last week and it gets reviewed and declined yesterday. Below are the main reasons of rejection https://protectuswebfilter.com/.well-known/private-token-issuer-directory seems to redirect, it should contain a privacy pass issuer directory. https://ohttp.protectuswebfilter.com/.well-known/ohttp-gateway is in json, that is not the correct format. See https://www.ietf.org/rfc/rfc9458.html#name-key-configuration my configurations are Provide your PIR server domain name pir.protectuswebfilter.com Provide your Privacy Pass Token Issuer URL protectuswebfilter.com Provide your Oblivious HTTP Gateway configuration resource https://ohttp.protectuswebfilter.com/.well-known/ohttp-gateway Provide your Oblivious HTTP Gateway resource https://ohttp.protectuswebfilter.com I understood the root cause of point number 1 as I need to use pir.protectuswebfilter.com as my privacy pass issuer is pointing to same pir service. Can you please help me with, what exactly apple is expecting for point number 2

is it customisable with third party apps ?

We do respect privacy of every user and we are trying to make our solution GDPR compliant. Because we are trying to protect customers from getting scammed by the calls.

[quote='894518022, DTS Engineer, /thread/827166?answerId=894518022#894518022'] You still need to implement the authentication service, which is that that URL is "for". See "Anonymous Authentication" for an overview of that's involved. [/quote] @DTS Engineer This link is not working, do we have any sample service or documentation. So that we can refer it for an implementation purpose,

Thanks for your answer. [quote='894297022, DTS Engineer, /thread/827166?answerId=894297022#894297022'] I'm not sure I understand this. Are you not planning to use any sort of authentication for your user(s)? I'm not sure the protocol can function without this. [/quote] No we are having PIR issuer token, currently passing directly to the framework. I am asking about field in the form for Privacy Pass Token Issuer URL. Because we reusing example PIR server from apple and not sure whether it has implementation for token URL or not to mention this in the form.

Can we keep Privacy Pass Token Issuer URL empty as we have not implemented anything for this ?

Hello @RomainDropB, Nice to hear that you managed to run the filter. One thing I wanted to confirm about pirPrivacyPassIssuerURL. What is required to be passed for this parameter, did you implement any infrastructure for this ?

@DTS Engineer I see there is a change in then entitlement request for NEURLFilter https://icloud.developer.apple.com/dashboard/identity/teams/9N738HVC7M/neurl-filter-form. I see previously Validation Test DNS Record section was asking for Update your domain DNS records. Add apple-url-filter=<bundle_identifier>, where <bundle_identifier> is replaced with your app bundle ID but in new flow they are asking where <bundle_identifier> is replaced with your extension's bundle identifier. Please confirm If we need extension's bundle ID or only app's bundle ID

@DTS Engineer So is it a restriction from apple side that is gone block/reject this entitlement request or is it a suggestion from your end in order to reduce the complexity and inter dependency.

any update @DTS Engineer

One thing I wanted to confirm, suppose i submit one request to onboard OHTTP relay for our organisation app and it gets approved, so can I re submit the request with different bundle ID and same PIR server, OHTTP server ?