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

Changing a note on attestation #23

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open

Changing a note on attestation #23

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
8d1bc72
Changing a note on attestation
maxhata Nov 1, 2020
72a19fe
Update HowToFIDO.md
maxhata Nov 1, 2020
f05b4a3
Update HowToFIDO.md
maxhata Nov 1, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
59 changes: 30 additions & 29 deletions HowToFIDO.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -243,13 +243,8 @@ navigator.credentials.create({
})
```

> A note on attestation: We recommend that most relying parties operating in the
> consumer (as opposed to enterprise) space not specify the attestation conveyance
> parameter `attestation` (thus defaulting to none), or instead explicitly use the value
> `indirect`. This guarantees the most streamlined user experience (platforms are likely
> to obtain consent from the user for other types of attestation conveyances, which
> likely results in a larger fraction of unsuccessful credential creations due to users
> canceling the creation).
> A note on attestation: Please see [16].


Associate the returned public key and credential id with the user
account. Also, make sure you associate the credential id **with the
Expand Down Expand Up @@ -449,11 +444,7 @@ navigator.credentials.create({
})
```

> A note on attestation: We recommend that most relying parties not specify the attestation
> conveyance parameter attestation (thus defaulting to none), or instead explicitly use the value
> indirect. This guarantees the most streamlined user experience (platforms are likely to obtain
> consent from the user for other types of attestation conveyances, which likely results in a
> larger fraction of unsuccessful credential creations due to users canceling the creation).
> A note on attestation: Please see [16].

It is common practice to let the user name the authenticator (either
before or after you call `create()`), and to show the user a list of
Expand Down Expand Up @@ -603,12 +594,8 @@ navigator.credentials.create({
})
```

> A note on attestation: We recommend that most relying parties not specify the attestation
> conveyance parameter `attestation` (thus defaulting to none), or instead explicitly use
> the value `indirect`. This guarantees the most streamlined user experience (platforms are
> likely to obtain consent from the user for other types of attestation conveyances, which
> likely results in a larger fraction of unsuccessful credential creations due to users
> canceling the creation).
> A note on attestation: Please see [16].


You should let the user name the authenticator (either before or after
you call create()), and show the user a list of UVRAs that they have
Expand Down Expand Up @@ -683,12 +670,7 @@ navigator.credentials.create({
})
```

> A note on attestation: We recommend that most relying parties not specify the attestation
> conveyance parameter `attestation` (thus defaulting to none), or instead explicitly use the
> value `indirect`. This guarantees the most streamlined user experience (platforms are likely
> to obtain consent from the user for other types of attestation conveyances, which likely
> results in a larger fraction of unsuccessful credential creations due to users canceling the
> creation).
> A note on attestation: Please see [16].

If the transports indicated in the response include "ble" and/or
"cable", you know that the present device can be used as a UVRA.
Expand Down Expand Up @@ -885,11 +867,7 @@ navigator.credentials.create({
})
```

> A note on attestation: We recommend that most relying parties not specify the attestation
> conveyance parameter `attestation` ( thus defaulting to none), or instead explicitly use the
> value `indirect`. This guarantees the most streamlined user experience (platforms are likely to
> obtain consent from the user for other types of attestation conveyances, which likely results in
> a larger fraction of unsuccessful credential creations due to users canceling the creation).
> A note on attestation: Please see [16].

Depending on whether a resident/discoverable credential was in fact
created, and whether the authenticator response indicates support for
Expand Down Expand Up @@ -977,3 +955,26 @@ a UVRA</span>](#signing-in-with-a-uvra).
15. Historically, we used the term "resident key" to refer to what will
be known as "discoverable credentials" in the upcoming WebAuthn L2
and CTAP2.1 specs.


16. A note on attestation: Whether or not to specify the attestation
conveyance parameter `attestation`depends on your business priorities.
If attestation is not specified, you will not get the AAGUID
(Authenticator Attestation GUID) of the authenticator and you will not
know anything about the authenticator you are about to accept for
registration with your services. Knowing AAGUID enables you to find
out the provenance and supported features of the authenticator as well
as if the authenticator is certified by FIDO Alliance from such a source
like [FIDO Metadata Service] (https://fidoalliance.org/metadata/).
FIDO Certification assures interoperability as well as levels of security
of authenticators. This will be useful information especially for security
conscious RPs and applications.
If you are not interested in such information of the authenticators at all,
your choice will be not to specify the attestation conveyance parameter
`attestation` (thus defaulting to none), or instead explicitly use the value
`indirect`. This guarantees the most streamlined user experience (platforms
are likely to obtain consent from the user for other types of attestation
conveyances, which likely results in a larger fraction of unsuccessful
credential creations due to users canceling the creation).

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it makes sense to also note that when asking for attestation there may be some UX concerns (I believe some browsers, at least in some versions, display specific warning when attestation is requested by the browser...?)
And that if using attestations the RP should be prepared to a case where an authenticator is being used that's not listed in MDS or otherwise known to the RP.