Bug description
Issue 1:
The workflow given in the spec mentions
Step 10 : Opportunity for user to approve or reject client onboarding
This not possible as user approval has no guaranteed timeframe whereas the HTTP requests are bound with a timeout.
Issue 2:
The Step 8 in this workflow doesn't seem inclusive:
Step 8 : Opportunity for user to manually upload client certificate
This wording implies only client certificate-based trust/whitelisting, excluding CA-based authentication. In setups where devices have unique keys but derived from a shared CA (common in PKI/IoT), manually uploading every certificate is inefficient and unscalable, yet CA-based validation could be a valid, preferred alternative.
Issue 3:
There is no way to verify that the public key is actually owned by that device.
Proposed fix
Issue 1:
Either:
Change the wording to: "Opportunity for system to approve or reject client onboarding based on trusted device lists etc.." (Aligns with synchronous, automated approval)
Or, implement async onboarding with polling: Server returns 202 Accepted on POST /onboarding, clients poll GET /onboarding/{clientId}/status for updates, and admins use POST /onboarding/{clientId}/approve to decide. Bind onboarding status (e.g., pending_approval, approved, rejected) to the Device resource for tracking.
Issue 2:
Rephrase to: "Opportunity for user to configure trust (e.g., manually upload client certificates, configure trusted CAs)". This broadens support for CA-based and other authentication methods, making the spec more inclusive.
Issue 3:
Need to add a challenge in the onboarding workflow to verify the PoP of the key. The PKI infrastructure generally has this.
Anything else (optional)
No response
Bug description
Issue 1:
The workflow given in the spec mentions
This not possible as user approval has no guaranteed timeframe whereas the HTTP requests are bound with a timeout.
Issue 2:
The Step 8 in this workflow doesn't seem inclusive:
This wording implies only client certificate-based trust/whitelisting, excluding CA-based authentication. In setups where devices have unique keys but derived from a shared CA (common in PKI/IoT), manually uploading every certificate is inefficient and unscalable, yet CA-based validation could be a valid, preferred alternative.
Issue 3:
There is no way to verify that the public key is actually owned by that device.
Proposed fix
Issue 1:
Either:
Change the wording to: "Opportunity for system to approve or reject client onboarding based on trusted device lists etc.." (Aligns with synchronous, automated approval)
Or, implement async onboarding with polling: Server returns 202 Accepted on POST /onboarding, clients poll GET /onboarding/{clientId}/status for updates, and admins use POST /onboarding/{clientId}/approve to decide. Bind onboarding status (e.g., pending_approval, approved, rejected) to the Device resource for tracking.
Issue 2:
Rephrase to: "Opportunity for user to configure trust (e.g., manually upload client certificates, configure trusted CAs)". This broadens support for CA-based and other authentication methods, making the spec more inclusive.
Issue 3:
Need to add a challenge in the onboarding workflow to verify the PoP of the key. The PKI infrastructure generally has this.
Anything else (optional)
No response