-
Notifications
You must be signed in to change notification settings - Fork 166
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
remove "required" on ScopedCredentialDescriptor.id #245
Comments
Making I think the language updates around usage are already handled. For example, using a credential right now says (emphasis mine):
(ExcludeList looks fine as it's written now, too) So I'd support a PR that marks |
@jcjones wrote:
I'm confused -- which note? By "the note", perhaps you are referring to something said in conversation (eg on the webauthn call last week?) ? Where you say "PublicKeyCredentialType" above, did you actually mean "PublicKeyCredentialDescriptor" ?
So what you are suggesting here is that if the RP does have a credential ID for a cred of type "public-key", it must supply it in the PublicKeyCredentialDescriptor.id, regardless of authnr capabilities ? Is this because some authnrs supporting "public-key" creds must be presented with the credential ID to do anything (eg U2F authnrs) ? This is not the case for all authnrs supporting "public-key" creds, yes? also, "key handle" is confusing -- that term only occurs in S 7.6. FIDO U2F Attestation Statement Format -- did you intend to say "credential ID" ? |
My original post proposes two changes to the spec:
Reading from J.C.'s comment, I believe he's supportive of the first change and the second change is not necessary. In addition, he proposes another change based upon the previous two:
If we go with what J.C. proposes, there won't be any real API behavioral change except that we keep a door open for future credential types. Of course, this is @jcjones's comment and my interpretation could be off. |
Attempted to be addressed by #500 |
@AngeloKai wrote
agreed.
Actually, @jcjones says "I could go either way" about the above. Though, in reviewing PR #500, I am wondering whether the change proposed by this issue is actually necessary. You wrote:
..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 And so in subsequent calls to The purpose of the Additionally, I do not understand why we would stipulate that 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? |
we moved the relevant PR #500 to milestone CR on the webauthn call today 28-Jun-2017, so doing same with this issue. |
Given that we can always remove 'require' (go from more restrictive to less restrictive) and the goal of the issue is to address other flavors of public key credentials (not in scope for v1), I am moving the issue to v2. @equalsJeffH @jcjones please let me know if you disagree. |
@equalsJeffH Can we close this as it looks like its obsolete |
As @AngeloKai said, you can always remove "required" later when you encounter a credential type that doesn't want to require the id field. Until then, it seems confusing to remove it from the dictionary but still require the field from prose. So +1 for closing this issue and #500. |
Closing this given #245 (comment), #245 (comment), #245 (comment) |
Although our current spec only has one credential type: “ScopedCred”, we may add more types to the spec in the future. 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. Developer has to provide both credential type and credential id in allowList and excludeList to specify what credentials they find acceptable.
To provide more flexibility to the developer to search, I propose we remove the “required” keyword from the id parameter in ScopedCredentialDescriptor and revise the language in the spec about allowList and excludeList being lists of acceptable credentials. Instead, let’s change the language to a “list of search criteria to find credentials acceptable to the callers.”
The text was updated successfully, but these errors were encountered: