- From: =JeffH via GitHub <sysbot+gh@w3.org>
- Date: Sat, 15 Apr 2017 00:00:08 +0000
- To: public-webauthn@w3.org
shucks @jyasskin this was next on my list to submit :) One of the side effects of integrating with [Credential Management](https://w3c.github.io/webappsec-credential-management) (CredMan) is that we have to acknowledge that there are other types of "scoped credentials" (e.g.: password, federated), and thus the "ScopedCredential" name is not particular to WebAuthn. In CredMan, the "scoped-to-an-RP" notion is termed "[origin bound](https://w3c.github.io/webappsec-credential-management/#credential-origin-bound)": >Some Credential objects are origin bound: these contain an internal slot named [[origin]], which stores the origin for which the Credential is valid. ..and both "password" and "federated" credentials are also origin bound. Keeping with the cred type naming theme in CredMan, perhaps we should rename "ScopedCredential" to "PublicKeyCredential" ? And have it's value of [[type]] be set to "publickey" ? Would this be too generic name-wise? I'm not sure wrt to PublicKeyCredentials -- are there types of "public keys" whose generation and signature algorithms /would not/ fit into our algorithmic model? I.e., are there types of "asymmetric keys and their algorithms" that we may wish to utilize in the future, yet need to be differentiated from "conventional" RSA and ECC, and would it be reasonable to have a type name for them that is different than "publickey" ? One possible case are the keys and algs used in so-called "selective disclosure systems" (u-prove and idemix). Perhaps it would be ok to term these as "selectiveDisclosureCreds" if we ever have to cross that bridge...? -- GitHub Notification of comment by equalsJeffH Please view or discuss this issue at https://github.com/w3c/webauthn/issues/406#issuecomment-294258206 using your GitHub account
Received on Saturday, 15 April 2017 00:00:14 UTC