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.

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

Add registration/authentication extensions for cloud-assisted BLE #909

Closed
wants to merge 10 commits into from

Conversation

@kpaulh
Copy link
Contributor

@kpaulh kpaulh commented May 15, 2018

This is a counterpart to https://github.com/fido-alliance/fido-2-specs/pull/529/, the FIDO2 cloud-assisted BLE PR. We're not quite sure where the extension should live - FIDO2 or WebAuthN. We're leaning towards WebAuthN, since it is relevant to RPs, but hoping others have some thoughts.

Also, this PR currently has references to sections in the FIDO2 spec that I can either replace with complete explanations or update links to once they're available in the FIDO spec. We figured we would get eyes on it now and clean up along the way.

Note that since this is the first registration extension, this PR also adds RegistrationExtensionsClientInputs/Outputs.


Preview | Diff

@equalsJeffH equalsJeffH self-requested a review May 16, 2018
@nadalin
Copy link
Contributor

@nadalin nadalin commented May 16, 2018

@kpaulh Will review @ the FIDO Plenary

Copy link
Contributor

@selfissued selfissued left a comment

I believe that this extension does belong in WebAuthn, although it would be OK for it to be in CTAP instead. In either case, it will end up in the IANA "Extension Identifiers" registry - so the result would be the same.

The creation of the "RegistrationExtensions..." identifiers reflects a misunderstanding. The word "Authentication" in the "AuthenticationExtensions..." identifiers refers to "Web Authentication" - not a particular method. The existing identifiers apply and should be used.

index.bs Outdated
};
</xmp>

This is a dictionary containing the [=client extension output=] values for zero or more WebAuthn extensions, as defined in [[#extensions]].

This comment has been minimized.

@selfissued

selfissued May 23, 2018
Contributor

Delete RegistrationExtensionsClientOutputs. Use AuthenticationExtensionsClientOutputs instead.

This comment has been minimized.

@kpaulh

kpaulh May 23, 2018
Author Contributor

Done! sorry for the confusion.

index.bs Outdated
};
</xmp>

This is a dictionary containing the [=client extension input=] values for zero or more WebAuthn extensions, as defined in [[#extensions]].

This comment has been minimized.

@selfissued

selfissued May 23, 2018
Contributor

Delete RegistrationExtensionsClientInputs. Use AuthenticationExtensionsClientInputs instead.

This comment has been minimized.

@kpaulh

kpaulh May 23, 2018
Author Contributor

Done

index.bs Outdated
typedef record<DOMString, DOMString> RegistrationExtensionsAuthenticatorInputs;
</xmp>

This is a dictionary containing the [=authenticator extension input=] values for zero or more WebAuthn extensions, as defined in [[#extensions]].

This comment has been minimized.

@selfissued

selfissued May 23, 2018
Contributor

Delete RegistrationExtensionsAuthenticatorOutputs. Use AuthenticationExtensionsAuthenticatorOutputs instead.

This comment has been minimized.

@kpaulh

kpaulh May 23, 2018
Author Contributor

Done

index.bs Outdated
required BufferSource rpPublicKey;
};

partial dictionary RegistrationExtensionsClientInputs {

This comment has been minimized.

@selfissued

selfissued May 23, 2018
Contributor

Registration -> Authentication

This comment has been minimized.

@kpaulh

kpaulh May 23, 2018
Author Contributor

and Done

@nadalin
Copy link
Contributor

@nadalin nadalin commented Feb 13, 2019

@equalsJeffH
Copy link
Contributor

@equalsJeffH equalsJeffH commented Mar 6, 2019

Just to note wrt

We're not quite sure where the[se] extension[s] should live - FIDO2 or WebAuthN

Just to note, presently these extension definitions are also contained in fido-alliance/fido-2-specs#529 [ which is for the CTAP spec ]. If we decide to land them here in the WebAuthn spec, we will need to update fido-alliance/fido-2-specs#529 such that they (specifically only the extension definitions) are elided (from the latter CTAP-specific PR).


During <code>authenticatorGetAssertion()</code>, the RP provides the
client with the necessary session data via the following extension.
For details refer to Sections [#cable-eid] and [#cable-encryption].

This comment has been minimized.

@jcjones

jcjones Mar 7, 2019
Contributor

I don't think these anchors exist?

Copy link
Contributor

@equalsJeffH equalsJeffH left a comment

LGTM, thanks Kim!!

@nadalin
Copy link
Contributor

@nadalin nadalin commented Mar 13, 2019

We will leave open until the CTAP work is implemented and make sure this works with passwordless world

};
</xmp>

Versions is a list of protocol versions supported by the relying party.

This comment has been minimized.

@ynojima

ynojima Apr 13, 2019
Contributor

Could you elaborate the version ? What value is supported here?

This comment has been minimized.

@arnar

arnar Jun 19, 2019
Contributor

For now only "1", but the field exists so that we can make changes/fixes to the protocol if needed.


Versions is a list of protocol versions supported by the relying party.

The rpPublicKey is an ECDH P-256 public key.

This comment has been minimized.

@ynojima

ynojima Apr 13, 2019
Contributor

What format is used for encoding rpPublicKey?


The clientEid is a 16-byte EID advertised by the Client.

The authenticatorEid is a 16-byte EID advertised by the Authenticator.

This comment has been minimized.

@ynojima

ynojima Apr 13, 2019
Contributor

How does the RP retrieve the EID advertised by the Authenticator?

@nadalin nadalin removed this from the L2-WD-01 milestone Apr 24, 2019
@nadalin nadalin added this to the L2-WD-02 milestone Apr 24, 2019
@ynojima
Copy link
Contributor

@ynojima ynojima commented May 25, 2019

@equalsJeffH
Copy link
Contributor

@equalsJeffH equalsJeffH commented Jan 8, 2020

we are closing this because we are hoping it will not be needed.

@equalsJeffH
Copy link
Contributor

@equalsJeffH equalsJeffH commented Feb 26, 2020

at 2020-02-26 meeting, we decided to close this because we are sure it wont be needed.

@zbot473
Copy link

@zbot473 zbot473 commented May 22, 2020

@equalsJeffH What is the standard for this then?
How will smartphone auth be done, or is that not the spec's job?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

9 participants