Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Adopt changes from level 3 of spec #48

Open
3 of 7 tasks
Firehed opened this issue Nov 18, 2023 · 2 comments
Open
3 of 7 tasks

Adopt changes from level 3 of spec #48

Firehed opened this issue Nov 18, 2023 · 2 comments

Comments

@Firehed
Copy link
Owner

Firehed commented Nov 18, 2023 •
edited
Loading

https://www.w3.org/TR/webauthn-3/

So far, I've found the following (non-comprehensive) list of changes:

  • JSON format handling, as noted in Add/improve support for native JSON APIs #41
  • Improved documentation of conditional mediation
  • Flags for credential backup eligibility and state in authenticator data
  • Explicit recommendation about the credential record to be associated with the user
    • type
    • id
    • publicKey
    • signCount
    • uvInitialized
    • transports[] (note: this doesn't appear to be part of the signed, trusted data)
    • backupEligible
    • backupState
    • ?attestationObject
    • ?attestationClientDataJSON
  • Explicit recommendation of the max length of a credential (<= 1023 bytes; §7.1¶25)
  • Addition of optional topOrigin and crossOrigin fields to ClientDataJSON
  • Signing (authn) response can include an AttestationObject; additional parsing described §7.2¶25
@Firehed
Copy link
Owner Author

Firehed commented Nov 18, 2023

Note: I think the credential record changes specifically are going to necessitate some large modifications to the codec logic, and could result in a fairly major BC break.

@Firehed Firehed mentioned this issue Dec 2, 2023
Closed
@Firehed
Copy link
Owner Author

Firehed commented Dec 2, 2023

A couple additional notes:

  • The CredentialInterface name has always been somewhat conflicting with how RP apps want to name the storage value. The new spec seems to lean towards credential record as suggested terminology.
  • Handling the "only treat this as MFA if uvInitialized was already set" is difficult to navigate (§7.2¶26#3)

@Firehed Firehed mentioned this issue Dec 3, 2023
Merged
Firehed added a commit that referenced this issue Dec 3, 2023
@Firehed
Support base64url access for challenges; adjust legacy credential for…
2638034 
…mat (#61)

This reduces the need for RP servers to use internal methods by directly
exposing the challenge as base64url, which is used by the (limited
support) native formats as noted in #48 (a tool to produce the entire
format will come as well!).

Additionally, this matches up the storage id formats for both credential
formats, which as-is would not function as expected (new authorizations
would return a v2, and subsequently could fail to find an existing
matching v1 format depending on the lookup approach)

> [!WARNING]
> BC BREAK: this changes the storage identifier for the older credential
format. This was noted in tests as a pre-1.0 possibility.

Fixes #59
@Firehed Firehed mentioned this issue Jan 3, 2024
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@Firehed