-
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
SigFormat: Clarification of assertion delivery in platform specific manner #23
Labels
Milestone
Comments
equalsJeffH
added
spec:fido-2:signature-format
stat:OKtoDo
and removed
type:SpecIssue
labels
Mar 13, 2016
vijaybh
added a commit
that referenced
this issue
May 7, 2016
Fixes #58 by adding verbiage in the API section about the two layers in the WebAuthn security model. This discussion is ongoing with the TAG, so we will open a new issue if there are follow-ups. Fixes #20, #21, #23 by removing mentions of native apps and APIs, as these are out of scope for this specification.
In case of non-web applications, if the assertion is delivered to the RP in a platform specific manner it will imply that the RP will have to support multiple platform-specific encodings/formats and perhaps protocol? Is this the intention? Nope -- the text is in regards to APIs, not the signed objects. |
vijaybh
added a commit
that referenced
this issue
May 11, 2016
* Clarify that RP ID is globally unique Fixes #38, #16. * Clarify that extensions are optional Fixes #74 * Clarify credential type Fixes #15 * Make method parameters consistent between API and authenticator model sections Fixes #30 * Clarify attestation model vs. attestation type Fixes #27, #28 * Use case: user can use WebAuthn credential when creating account, avoiding passwords entirely Fixes #10 * Clarify security model and remove vestiges of "native API" language Fixes #58 by adding verbiage in the API section about the two layers in the WebAuthn security model. This discussion is ongoing with the TAG, so we will open a new issue if there are follow-ups. Fixes #20, #21, #23 by removing mentions of native apps and APIs, as these are out of scope for this specification. * JsonWebKey is a dictionary not an interface Fixed sloppy terminology usage * Remove unnecessary ref WebCrypto is not a reference for byte arrays
vijaybh
pushed a commit
that referenced
this issue
Jun 1, 2016
) * Clarify that RP ID is globally unique Fixes #38, #16. * Clarify that extensions are optional Fixes #74 * Clarify credential type Fixes #15 * Make method parameters consistent between API and authenticator model sections Fixes #30 * Clarify attestation model vs. attestation type Fixes #27, #28 * Use case: user can use WebAuthn credential when creating account, avoiding passwords entirely Fixes #10 * Clarify security model and remove vestiges of "native API" language Fixes #58 by adding verbiage in the API section about the two layers in the WebAuthn security model. This discussion is ongoing with the TAG, so we will open a new issue if there are follow-ups. Fixes #20, #21, #23 by removing mentions of native apps and APIs, as these are out of scope for this specification. * JsonWebKey is a dictionary not an interface Fixed sloppy terminology usage * Remove unnecessary ref WebCrypto is not a reference for byte arrays * abstract clarifications/polishing * abstract edits * polish abstract,intro,terminology sections, and move terminology to front of spec * publishing diff * remove Makefile dependency on biblio.json travis CI was failing... * address Vijay's comments * addresses Vijay's comments other than wrt credential definition * address vijay's comments #3 - minor tweaks * address vijay's comments #4 - fix bikeshed errors * fix UAF spec link * fix spelling and reference * refine 'scoped credential' definition
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Originally submitted by: smachani1, on: Monday Oct 05, 2015 at 01:45 GMT
Section 6.1 Attributes
Last paragraph reads “This assertion is delivered to the RP in either a platform specific manner, or in the case of web applications, according to the FIDO Web API [FIDOWebApi]. It contains all the…”. In case of non-web applications, if the assertion is delivered to the RP in a platform specific manner it will imply that the RP will have to support multiple platform-specific encodings/formats and perhaps protocol? Is this the intention?
The text was updated successfully, but these errors were encountered: