Re: [webauthn] client extension results field name is unclear (#2275)

I suppose the way I look at the spec here is the interoperability of the frontend/backend is a concern for the authors of the relevant libraries/applications. 

If I'm understanding you correctly, getTransports() is in a very similar boat here since it's effectively documented in the same way where how it makes it to the backend is only documented by means of the toJSON method and the internal slot accessed via getTransports(). 

The process I've _personally_ followed in library data structures is to follow the format of the output of toJSON exactly, because to my way of thinking that is effectively the most logical way to guarantee high interoperability (i.e. in this instance the field name is communicated as `clientExtensionResults` in several places). Though that being said I've been working off the editors draft for a while with the increase in requests for level 3 related features, and anticipation that level 3 will be recommended in the near future anyway; which may have an impact.

However this would not lead me to believe that all API's **_must_** follow this convention, and interoperability layers could very well exist for this purpose as well. The data may in fact be communicated by a means that's more efficient to use something other than JSON entirely. 

I cannot say I have not been frustrated by similar in the past, and I cannot say my interpretation is necessarily the correct one, but I guess at some stage it clicked for me (either correctly or incorrectly) that this doesn't need to be and potentially shouldn't be articulated because of design choices developers may want to make.

-- 
GitHub Notification of comment by james-d-elliott
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/2275#issuecomment-2753102754 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 26 March 2025 02:47:50 UTC