- From: =JeffH via GitHub <sysbot+gh@w3.org>
- Date: Mon, 26 Jun 2017 22:44:52 +0000
- To: public-webauthn@w3.org
@AngeloKai wrote > Reading from J.C.'s comment, I believe he's supportive of the first change and the second change is not necessary agreed. > In addition, [@jcjones] proposes another change based upon the previous two: > 3. Add requirements to the algorithm that "if the credential type is 'PublicKeyCredential', the id is required." Actually, @jcjones [says "I could go either way" about the above](https://github.com/w3c/webauthn/issues/245#issuecomment-302277978). Though, in reviewing PR #500, I am wondering whether the change proposed by this issue is actually necessary. You wrote: > In case more types were added in the future and developer hasn’t done works to adopt their server to accept newer types, they would want to only accept credentials of a certain type. However, our current design doesn’t provide a way for them to just search by type ..but an RP would in the above case restrict credential creation & registration to the cred type(s) it understands, yes? That can be accomplished today in the call to `navigator.credentials.create()` (which invokes the [#createCredential](https://w3c.github.io/webauthn/#createCredential) alg) via appropriately setting the `type` value(s) in element(s) of the `options.publicKey.parameters[]` sequence, yes? And so in subsequent calls to `navigator.credentials.get()` (which invoke the [#getAssertion](https://w3c.github.io/webauthn/#getAssertion) alg), a user's creds for this RP, on their authenticator(s), will already be of the type stipulated by the RP (unless the RP has altered which PK cred types it supports, and deprecated registered credentials, which is yet another use case, yes?). The purpose of the `options.allowCredentials[]` parameter to [#getAssertion](https://w3c.github.io/webauthn/#getAssertion), [AIUI](http://acronyms.thefreedictionary.com/AIUI), is to identify _specific_ creds "acceptable to the caller". Making `options.allowCredentials[].id` optional alters the semantics to be "any cred of this type, mapped to this RP ID, is 'acceptable'", if `options.allowCredentials[].id` is not present. Is that the desired behavior? What effect might it have on the user experience? Additionally, I do not understand why we would stipulate that `options.allowCredentials[n].id` must be present only if `options.allowCredentials[n].type`'s value is "public-key", and that not be the case if `options.allowCredentials[n].type`'s value is something other than the latter. Is this issue premised on an expectation that some new, different cred type may not have a notion of a "credential ID" ? Can you cite example(s) if so? fwiw, I'm supportive of the overall theme of this issue -- facilitating other flavors of public key creds. Where "other flavors" consists of differences in assertion signature formats and differences in authenticator data formats, etc (eg webauthn as compared to UAF). However, all cred types supported by this spec are public key-based, and I tend to think that all types will have a notion of "credential ID" (webauthn, U2F, and UAF all do). Perhaps I do not understand the problem you are trying to address? -- GitHub Notification of comment by equalsJeffH Please view or discuss this issue at https://github.com/w3c/webauthn/issues/245#issuecomment-311202758 using your GitHub account
Received on Monday, 26 June 2017 22:44:58 UTC