- From: Martin Kreichgauer via GitHub <sysbot+gh@w3.org>
- Date: Mon, 22 Nov 2021 21:29:51 +0000
- To: public-webauthn@w3.org
> While `toJSON()` in WebIDL may be convention, I don't believe we could use the `default` implementation without changes to WebIDL or ECMAScript. > > In particular, the ask has been for this value to be Base64 (or I presume Base64URL) encoded, but such an encoding would need to be defined upstream by one of these two specifications for us to leverage a `Default` toJSON() implementation from WebIDL. I don't think there's a requirement that if you define a `toJSON` operation, it has to use the default operation. For example: https://w3c.github.io/push-api/#dom-pushsubscription-tojson > > We would probably want guidance from WebIDL that our declaration of a `fromJSON()` would not conflict with WebIDL in the future. > > This would decrease the duplication of description languages, although WebIDL would expect us to define the dictionary formats of the current interface types. > > Either way (WebIDL or CDDL), we have to resolve issue that `CredentialCreationOptions`/`CredentialRequestOptions` can not host static methods like `fromJSON()` - they are dictionaries, not interfaces. My suggestion is to hang them off of `PublicKeyCredential`, the same way we do with `isUserVerifyingPlatformAuthenticatorAvailable()`. That way they also won't be generic `fromJSON()`, but rather `publicKeyCredentialCreationCreationOptionsFromJSON()` for example, so there is little risk of them conflicting with anything Web IDL might do in the future IMHO. -- GitHub Notification of comment by kreichgauer Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1683#issuecomment-975935853 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 22 November 2021 21:29:52 UTC