Question on authenticatorGetInfo and UV

[Eldan Ben Haim]

Hello,

The CTAP2 standard states that authenticatorGetInfo should return in the options member of the response the flag uv to -- "indicate[s] that the device is capable of verifying the user as part of the authenticatorGetAssertion request".

A couple of  questions here:

1. Can we assume that this relates to authenticatorGetAssertion and authenticatorMakeCredential?

2. In authenticatorMakeCredential's and authenticatorGetAssertion's the options parameter  is stated to include uv to "instruct[s] the authenticator to require a gesture that verifies the user to complete the request. Examples of such gestures are fingerprint scan or a PIN" (underline mine -EBH). Should an authenticator that supports external PIN authentication (as reported by authenticatorGetInfo) accept the uv parameter as true? The underline above suggests that it should, since PIN is counted as a UV gesture...?

[nuno sung]

Hi 

The uv option id in getInfo response means the authenticator has any Built-in User Verification method - The authenticator supports a built-in on-device user verification method like fingerprint or has a input UI with secure communication to the authenticator.

The uv option key in makeCred and getAssert commands means the platform/client/browser send this command to authenticator with requesting Some form of User Verification. The authenticator must do this before returning any positive responses. Some form of User Verification can be either clientPIN or above Built-in User Verification method .

ClinetPIN here means the one of using authenticatorClientPIN (0x06)  relative sub-commands ,  I don't know what external PIN you mean exactly.

el...@transmitsecurity.com 在 2020年11月30日 星期一上午1:13:27 [UTC+8] 的信中寫道：

[Eldan Ben Haim]

So to confirm, if an authenticator didn't return the UV flag in getInfo, but does support PIN, it's OK to pass the uv option in makeCred or getAssert to require client PIN? 

[Ackermann Yuriy]

There are two versions of UV in specs: Internal Capability and indication.

UV Internal Capability means that authenticator supports some form of the internal user verification method, hence UV in the GetInfo.options. If you set UV option in the makeCredential/getAssertion you will indicate to the authenticator that you want it to perform some form of the internal user verification.

Now there are other types of user verification, such as external ClientPin1 protocol. Those methods are managed via their own interface, such as PinAuth interface, and are indicated in the GetInfo their own way, such as getInfo.pinProtocols.

The Indication UV is just a flag in the authenticatorData.flags that Indicates if ANY UV was performed, Internal or External.

Regards. Yuriy

Yuriy Ackermann

FIDO, Identity, Standards

skype: ackermann.yuriy

github: @herrjemand

twitter: @herrjemand

medium: @herrjemand

--
You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/CAKK0n3uUHcbDQ%2B7CmDOt0j8QD8917U23XPwoC3dE%3D5egjuAK0Q%40mail.gmail.com.

[Eldan Ben Haim]

Thank you, this is what I understand from the spec. So based on what you're saying, the answer to my very specific question is -- if an authenticator doesn't return UV in getInfo, but does return indication of support for clientPIN, it is perfectly fine to require UV on e.g getAssertion. That's how I understand this based on the answers here, however it seems we've run into different behavior with Yubikey firmware 5.2.7; I'm trying to understand if the issue is with the firmware or our understanding.

[John Bradley]

NO!!!

In CTAP2.0 if the authenticator dosen't support uv in the getInfo options member and the uv options key is present (True or False) in a getAssertion/makeCredential the Authnenticator MUST return a CTAP2_ERR_UNSUPPORTED_OPTION error.

From the spec

"If the options parameter is present, process all the options. If the option is known but not supported, terminate this procedure and return CTAP2_ERR_UNSUPPORTED_OPTION"

Not all authenticators correctly impliment the error.  Safari had this bug for a while and only worked bio authenticators for a while if the RP sent UV required in WebAuthn.

Please don't repeat that bug.

Regards

John B.

[Ackermann Yuriy]

No no.

If GetInfo.option.uv is False, then authenticator does not support Internal UV, so you can't call UV flag in the GetAssertion/MakeCredential. However you can achieve UV by calling it with PinAuth. So Yubikey behaviour is correct.

Yuriy Ackermann

FIDO, Identity, Standards

skype: ackermann.yuriy

github: @herrjemand

twitter: @herrjemand

medium: @herrjemand

[Ackermann Yuriy]

Yeah, what John said *)

Yuriy Ackermann

FIDO, Identity, Standards

skype: ackermann.yuriy

github: @herrjemand

twitter: @herrjemand

medium: @herrjemand

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/67e3d533-17d6-f86d-2203-0ea11caa516b%40ve7jtb.com.

[Eldan Ben Haim]

At least based on the answers in this thread, I think it would be prudent to clarify the spec on this. 

Eg “if the option is is known but not supported (as reported by getInfo), ....”

Also it creates a bit of asymmetry between the fact that you’re not allowed to request UV but will get UV in the response... (assuming that’s the case) 

AND I would clarify in the example for the UV field in the request description (which explicitly talks about PIN) that the reference to PIN is made to an authenticator built in PIN capability (Eg input device). 

Makes sense?

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/67e3d533-17d6-f86d-2203-0ea11caa516b%40ve7jtb.com.

[John Bradley]

The Yubikey is spec compliant.

It is required to return a error by the spec. 

Platforms MUST not send the uv option key if uv is not present and true in get Info.

In CTAP2.0 if clientPin is present and true in getInfo Options then the platform should use getPINToken to get a token and use that for makeCredenital/GetAssertion.

If both uv and clientPin are true in getInfo, the platform first tries with the uv option key, then if it receves a pin_required error it falls back to getPinToken because internal UV has failed.

I admit it is underspecified in CTAP2.0, but we hope to improve it in CTAP2.1 coming soon in RD02.

Regards

John B.

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/CAKK0n3s4Js7KcJcO0VWSBZvmQ7Vz%3DbKzJqcHppf5p%2BNVoD-xrw%40mail.gmail.com.

[John Bradley]

All coming in CTAP2.1 RD02.  If you are a Fido member look at the working draft.  The Review draft should be ready in the next week but needs appoval for publication.

[Ackermann Yuriy]

The specs are actually clear on that https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-client-to-authenticator-protocol-v2.0-ps-20190130.html#authenticatorMakeCredential

Here is a diagram as well: 

Yuriy Ackermann

FIDO, Identity, Standards

skype: ackermann.yuriy

github: @herrjemand

twitter: @herrjemand

medium: @herrjemand

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/102f3ff6-e47d-15ce-410f-3281eb4b9902%40ve7jtb.com.

[Eldan Ben Haim]

Yes. the diagram describes this clearly. Perhaps you can consider adding it to the spec and removing some specific parts I highlighted that could be (and were, obviously by more than one party) easily interpreted otherwise.