Describe how to determine authenticator attachment from transports #1670
Conversation
* add transport docs * Update index.bs Co-authored-by: Nina Satragno <[email protected]> * Update index.bs Co-authored-by: Nina Satragno <[email protected]> * Update index.bs Co-authored-by: Nina Satragno <[email protected]> * Update index.bs Co-authored-by: Nina Satragno <[email protected]> Co-authored-by: zakaria ridouh <[email protected]> Co-authored-by: Nina Satragno <[email protected]>
emlun
added
type:editorial
process:meta-pr
index.bs
Outdated
| @@ -2739,7 +2773,7 @@ attributes. | |||
|
|
|||
| The [=[RP]=] can determine the resulting [=authenticator attachment modality|attachment=] for the created credential | |||
| using the {{AuthenticatorAttestationResponse/getTransports()}} method of the resulting {{AuthenticatorAttestationResponse}}. | |||
| See [[#enum-transport]] for details. | |||
| See [[#sctn-attachments-from-transports]] for details. | |||
There was a problem hiding this comment.
I like the new section, but as stated in the review of #1621 I am not sure if it's deterministically possible to derive the authenticator attachment modality that was used purely from the result of getTransports(), specifically in the case where getTransports() returns more than one value, and one of the values is internal. The RP cannot determine which was actually used, and therefore cannot determine whether or not it is useful to prompt the end user to register the platform authenticator if one exists. Let's discuss in the WebAuthn WG call, but I'm thinking the proposal in #1668 would satisfy this goal deterministically.
There was a problem hiding this comment.
and delete this sentence
| See [[#sctn-attachments-from-transports]] for details. |
* transport to platform attachment * pt2 * add section * move authenticator attachment to public key credential * slight changes * slight changes Co-authored-by: zakaria ridouh <[email protected]>
Co-authored-by: Nina Satragno <[email protected]> Co-authored-by: Emil Lundberg <[email protected]>
Co-authored-by: Nina Satragno <[email protected]>
There was a problem hiding this comment.
As @emlun notes in the original post, there is not "...a description of how to determine authenticator/credential attachment from transports...", plus, PR #1668 obviates the need for RPs to do this determination theirselves. However, the spec could be clearer regarding how client platforms ought to determine attachment from the transport used in a request.
NOTE: The latest language in PR #1668 now links to the section [[#sctn-attachments-from-transports]] and tacitly assumes the changes I've suggested here have been made.
Here's a rough suggestion wrt how to spec the latter, HTH....
index.bs
Outdated
| @@ -2739,7 +2773,7 @@ attributes. | |||
|
|
|||
| The [=[RP]=] can determine the resulting [=authenticator attachment modality|attachment=] for the created credential | |||
| using the {{AuthenticatorAttestationResponse/getTransports()}} method of the resulting {{AuthenticatorAttestationResponse}}. | |||
| See [[#enum-transport]] for details. | |||
| See [[#sctn-attachments-from-transports]] for details. | |||
There was a problem hiding this comment.
and delete this sentence
| See [[#sctn-attachments-from-transports]] for details. |
Co-authored-by: =JeffH <[email protected]>
Co-authored-by: =JeffH <[email protected]>
|
@equalsJeffH This all seems fair I think, but also at this point it probably makes more sense to merge this into PR #1668 instead of into #1621, given the now mutual dependency between this and #1668. I'll rebase this onto #1668 and reconfigure the PR. |
emlun
force-pushed
the
issue-1618-review-sbweeden-attachment-transport
branch
from
e1ab848 to
183d059
Compare
|
Hm... looks like I can't do that, because #1668 is a branch in a different repository clone. Maybe just close this and migrate it over to https://github.com/z11h/webauthn instead. |
|
Migrated to z11h#3. |
This would merge into PR #1621.
Addresses #1621 (comment) . Since there wasn't a description of how to determine authenticator/credential attachment from transports, this adds that as a new section similar to §5.2.1.1. Easily accessing credential data.
I'm submitting this as a separate (meta-) PR for visibility, because of the new section.
Preview | Diff