We are trying out Account Driven User Enrollment feature. Device is expected to send the device info(plist) (snippet below) during User enrolment in new flow as part of profile download request. Device is sending with HTTP request content type as "application/x-www-form-urlencoded", because of this HTTP request content type, we are not able to read the body as stream of bytes and parse the xml. In comparison to usual device enrolment workflow device info gets posted with the http request content-type  as "application/pkcs7-signature" which has been working fine without any issues. <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>LANGUAGE</key> <string>en-US</string> <key>PRODUCT</key> <string>iPhone10,2</string> <key>VERSION</key> <string>19A222</string> </dict> </plist> Can you please confirm if this is an issue from Apple side? Any suggestions around this?

In new Userenrollment flow (Account driven User enrollment), we are challenging the authentication by sending authentication URL which has a query parameter source=NATIVE as below : WWW-Authenticate: Bearer method="apple-as-web", url="https://ourauthserverdomain.com/ireg/index.html?source=NATIVE but when device makes the request to this url when it opens the webview it is ignoring query parameter sent from server (here, source=NATIVE).

VerifyRecoveryLockResponse - in this response, we do not get a key as VerifyRecoveryLock like its seen in VerifyFirmwarePasswordResponse where we get a key as VerifyFirmwarePassword. So should we rely only on the commanduuid to map to type of response and handle result accordingly for this type? <dict> <key>CommandUUID</key> <string>08b5bfb1-b547-43b4-b453-340a0dadeb7d</string> <key>PasswordVerified</key> <true/> <key>Status</key> <string>Acknowledged</string> <key>UDID</key> <string>B29422F1-756E-5370-966E-3A6E9E969096</string> </dict> . SetRecoveryLockResponse - in this response also we do not get a key to identify acknowledgement as 'SetRecoveryLockResponse' ( but we can identify with the CommandUUID) . we do not have any field as 'PasswordChanged' to confirm if its already changed like we have for SetFirmwarePasswordResponse. <dict> <key>CommandUUID</key> <string>d19f5ac9-31be-4cd9-9e20-0b034108855a</string> <key>Status</key> <string>Acknowledged</string> <key>UDID</key> <string>B29422F1-756E-5370-966E-3A6E9E969096</string> </dict> even though we could compare commanduuid, it would have been better if we also get the

This is in reference to the feedback ticket : https://feedbackassistant.apple.com/draft/57929340, we would like to know if there are any test enterprise websites that Apple can suggest to test passkeys declaration.