Seamless Wi-Fi: Creating On-Demand Passpoint Profiles and the Challenge of Frictionless Connectivity

Imagine downloading a mobile app that promises to connect you to Wi-Fi networks automatically, only to find yourself manually entering credentials at every hotspot. This common frustration highlights why Passpoint technology has become increasingly important.

Passpoint (also known as Hotspot 2.0) allows devices to connect to trusted Wi-Fi networks seamlessly without those tiresome login screens. However, implementing this technology presents several technical challenges, particularly when deploying it at scale.

The Technical Puzzle

The core challenge involves generating cryptographically signed configuration files that mobile devices trust. These files need to:

• Be explicitly tailored for different operating systems (iOS and Android)
• Include proper security certificates that validate the connection
• Be delivered efficiently to users without requiring ongoing server resources

What makes this particularly tricky is that each platform has strict requirements. Apple devices expect a properly signed .mobileconfig file with specific XML formatting, while Android requires a Base64-encoded multipart container with certificates bundled in precisely the right way.

Architecting a Lightweight Solution

A serverless architecture makes perfect sense for approaching this problem. Since each user only needs to download their profile once, maintaining a constantly running infrastructure would be wasteful.

Azure Functions with HTTP triggers provide an elegant solution:

[Function("GetPasspointApple")]
public async Task<HttpResponseData> RunApple(
    [HttpTrigger(AuthorizationLevel.Anonymous, "get", Route = "apple")] HttpRequestData req)
{
    var profileXml = _service.GenerateApplePasspointProfile(_config.ProfileContent);
    var signedBytes = EncodeAndSign(Encoding.UTF8.GetBytes(profileXml), _cert);

    var response = req.CreateResponse(HttpStatusCode.OK);
    response.Headers.Add("Content-Disposition", "attachment; filename=Passpoint.mobileconfig");
    response.Headers.Add("Content-Type", "application/x-apple-aspen-config");
    await response.WriteBytesAsync(signedBytes);
    return response;
}

This approach creates distinct endpoints for each platform, allowing for precise handling of the formatting requirements without maintaining persistent servers.

Platform-Specific Wrangling

The Apple Challenge

Apple's implementation requires a specially formatted XML document (a property list or "plist") that must be cryptographically signed. This involves carefully structuring the XML with particular UUIDs and Base64-encoded certificates:

<key>PayloadContent</key>
<array>
    <dict>
        <key>Password</key>
        <string>[REDACTED]</string>
        <key>PayloadCertificateFileName</key>
        <string>client.p12</string>
        <key>PayloadContent</key>
        <data>
        [BASE64-ENCODED-CERTIFICATE]
        </data>
        <!-- Additional configuration omitted -->
    </dict>
</array>

The tricky part is properly signing this document using a trusted certificate:

var cmsSigner = new CmsSigner(SubjectIdentifierType.IssuerAndSerialNumber, signerCertificate)
{
    IncludeOption = X509IncludeOption.WholeChain
};
var contentInfo = new ContentInfo(content);
var signedCms = new SignedCms(contentInfo, false);
signedCms.ComputeSignature(cmsSigner);

The Android Puzzle

Android's approach differs significantly, requiring a multipart MIME file that bundles together the profile XML, certificate authority, and PKCS#12 key:

builder.AppendLine($"--{boundary}");
builder.AppendLine("Content-Type: application/x-passpoint-profile");
builder.AppendLine("Content-Transfer-Encoding: base64");
builder.AppendLine();
builder.AppendLine(Convert.ToBase64String(Encoding.UTF8.GetBytes(profileXml)));

// Additional parts omitted for brevity

Domain Modelling for Clarity

A domain-driven design approach to manage this complexity helps tremendously. By abstracting the profile generation behind a clear interface:

public interface IPasspointProfileService
{
    string GeneratePasspointProfileXml(PasspointProfile profile);
}

This allows for platform-specific implementations while keeping the core business logic clean and maintainable.

Lessons Learned

Building this system revealed several key insights:

1. Understand the standards deeply: Both Apple and Android document their Passpoint implementations, but the nuances of correctly formatting and signing profiles require careful attention to detail.
2. Pay-per-use is perfect for one-time operations: When users only need a resource once, serverless architectures eliminate waste and reduce operational costs.
3. Abstract platform differences away from core logic: The solution remains clean and extendable by clearly separating the profile generation from platform-specific packaging.
4. Headers matter as much as content: Setting the correct Content-Type and Content-Disposition headers ensures that mobile devices handle the files properly.

What's Next?

This approach to Passpoint profile generation demonstrates how complex connectivity problems can be solved with lightweight, scalable architectures. As public Wi-Fi becomes increasingly important for IoT devices, transportation systems, and urban infrastructure, friction-free authentication methods like Passpoint will continue to grow in importance.

For developers working on similar connectivity challenges, this pattern can be adapted for various certificate-based authentication systems, not just Wi-Fi connectivity.

Would you like to see a follow-up exploring how this approach could be extended to support Windows devices or integrated with identity providers for personalised Wi-Fi experiences? Let us know in the comments.