- From: Hodges, Jeff <jehodges@paypal.com>
- Date: Thu, 2 Jun 2016 10:11:35 -0700
- To: Adam Powers <adam@fidoalliance.org>
- CC: W3C Web Authn WG <public-webauthn@w3.org>
Hi AdamP, thanks for your spec review & comments. Replies and refs to
resultant submitted issues are inline.
Note that, in the below, I indicate the text you highlighted in your
original PDF spec rendering like so..
<<<< ...highlighted text... >>>>
HTH,
=JeffH
>> Web Authentication: A Web API
>> for accessing scoped credentials
>> Editor's Draft, 13 May 2016
>>
>> [...]
>>
>>
>>
>> Abstract
>
> This jumps right into using jargon --
> given the potential audience, do we want
> to ease them into he jargon?
We have refined the language and terminology somewhat in
https://github.com/w3c/webauthn/pull/109, which is now merged to master
and available as https://w3c.github.io/webauthn/ - please check that out
but that said, this is a web api spec and is assuming relatively
sophisticated readers. We can do really soft hand-holding in an
"explainer doc" as has been discussed (volunteers? :)
also, i expect this spec to go thru further editorial evolution which
ought to improve its understandability.
>> [...]
>>
>>
>> §1. Use Cases
> Safe to assume that readers are familiar
> with scoped credentials?
see above.
>> This specification defines an API for web pages to access scoped
>> credentials through JavaScript, for the purpose of strongly
>> authenticating a user.
>>
>> [...]
>>
>> § 1.1. Registration (embedded authenticator mode)
>
> Diagrams?
do you mean diagrams of some person messing with their phone+laptop or
do you mean protocol flow diagrams ?
if the latter, I'm working on some and will offer them up, tho it will
be up to the group whether we bake them directly into the spec...
WebAuthn-Figures-00
<https://docs.google.com/presentation/d/1om__oSew4n48MK_Qcc8deq6hCZ6720-Zvv1PdK0CrjA>
>> On the phone:
>>
>> User goes to example.com in the browser and signs in to an existing
>> account using whatever method they have been using (possibly a
>> legacy method such as a password), or creates a new account. The
>> phone prompts, "Do you want to register this device with
>> example.com?"
>>
>> [...]
>>
>> §2. Conformance
>> [...]
>>
>> § 2.1. Dependencies
>>
>> This specification relies on several other underlying specifications.
>>
>> [...]
>>
>> §3. Web Authentication API
>>
>> [...]
>>
>> The API is defined by the following Web IDL fragment
>>
>> partial interface Window {
>>
>> readonly attribute WebAuthentication webauthn;
>>
>> };
>
> Is there any rhyme or reason to
> the order of this WebIDL?
somewhat, though 'rhyme or reason' is in the eye of the beholder :)
tho, now that we are using bikeshed which automagically produces a
consolidated webidl at the end of the spec
<https://w3c.github.io/webauthn/#idl-index> we could perhaps move
individual IDL fragements to appropriate spots in the spec...see..
https://github.com/w3c/webauthn/issues/112
>> [...]
>>
>> interface ScopedCredentialInfo {
>> readonly attribute Credential credential;
>> readonly attribute any publicKey;
>> readonly attribute WebAuthnAttestation <<<<attestation;>>>>
>> };
>
> If attestation is null, there would
> be no clientDataHash. Negative
> security ramifications?
yes, there would be negative security ramifications if there is no
supplied attestation (i.e., attestation == null), and the RP were to to
ahead and store the credential and the publicKey for later use.
However, per web IDL, the attribute members declared within
ScopedCredentialInfo are *not* "nullable", so your concern is being
implicitly addressed. And it is also nominally addressed in the
registration operation processing rules I believe.
>> [...]
>>
>> interface WebAuthnAttestation {
>> readonly attribute DOMString <<<<type;>>>> enum?
>> readonly attribute ArrayBuffer clientData;
>> readonly attribute any statement;
>> };
>>
>> [...]
yes, attestation "type" identifiers ought to be more fully defined, eg
so they do not collide. I've been thinking that it is another IANA
registry we would establish, to go along with the registry for extension
identifiers.
>> § 3.1. WebAuthentication Interface
>>
>>
>> This interface has two methods, which are described in the following
>> subsections.
>>
>> § 3.1.1. Create a new credential (makeCredential() method)
>>
>>
>> With this method, a script can request the User Agent to create a
>> new credential of a given type and persist it to the underlying
>> platform, <<<< which may involve data storage managed by the
>> browser or the OS. The user agent will prompt the user to approve
>> this operation. >>>>
It is not clear why you highlighted these two sentences -- explain?
>> On success, the promise will be resolved with a
>> ScopedCredentialInfoobject describing the newly created
>> credential.
>>
>> This method takes the following parameters:
>> [...]
>>
>> When this method is invoked, the user agent MUST execute the
>> following algorithm:
>>
>> 1. If credentialTimeoutSeconds was specified, check if its value
>> lies within a reasonable range as defined by the platform and if
>> not, correct it to the closest value lying within that range. Set
>> adjustedTimeout to this adjusted value. If
>> credentialTimeoutSeconds was not specified then set adjustedTimeout
>> to a platform-specific default.
>> 2. Let promise be a new Promise. Return promise and start a timer
>> for adjustedTimeout seconds. Then asynchronously continue executing
>> the following steps. 3. Set callerOrigin to the origin of the
>> caller. Derive the RP ID from callerOrigin by computing the "public
>> suffix + 1" or "PS+1" (which is also referred to as the "Effective
>> Top-Level Domain plus One" or "eTLD+1") part of callerOrigin [PSL].
>> Set rpId to the RP ID.
>> 4. Initialize issuedRequests to an empty list.
>> 5. Process each element of cryptoParameters using the following
>> steps, to produce a new sequence normalizedParameters:
>
> Additional description of what
> normalization is trying to
> accomplish would be helpful
see https://www.w3.org/TR/WebCryptoAPI/#algorithm-concepts-normalization
that said, webcrypto normalization is fairly gnarly, tho I spent some
time figuring it out a while back and have info to send to this mailing
list about it.
>> Let current be the currently selected element of cryptoParameters.
>> [...]
>>
>> 6. If blacklist is undefined, set it to the empty list.
>> 7. If credentialExtensions was specified, process any extensions
>> supported by this client platform, to produce the extension data
>> that needs to be sent to the authenticator. Call this data
>> clientExtensions.
>> 8. For each embedded or external authenticator currently available on
>> this platform: asynchronously invoke the authenticatorMakeCredential
>> operation on that authenticator with callerOrigin, rpId,
>> accountInformation, normalizedParameters, blacklist,
>> attestationChallenge and clientExtensions as parameters. Add a
>> corresponding entry to issuedRequests.
>>
>> 9. While issuedRequests is not empty, perform the following actions
>> depending upon the adjustedTimeout timer and responses from the
>> authenticators:
>>
>> If the adjustedTimeout timer expires, then for each entry in
>> issuedRequests invoke the authenticatorCancel operation on that
>> authenticator and remove its entry from the list.
>>
>> If any authenticator returns a status indicating that the user
>> cancelled the operation, delete that authenticator's entry from
>> issuedRequests. <<<< For each remaining entry in issuedRequests
>> invoke the authenticatorCancel operation on that authenticator
>> and remove its entry from the list. >>>> <=== The intent is that
> cancel on one
> results in cancelling all?
what you mean "cancel on one" is perhaps mistaken. The intent is that
the user has canceled *the entire registration operation*.
>> If any authenticator returns an error status, delete the
>> corresponding entry from issuedRequests. If any authenticator
>> indicates success, create a new ScopedCredentialInfoobject named
>> value and populate its fields with the values returned from the
>> authenticator. Resolve promise with value and terminate this
>> algorithm.
>>
>> 10. Resolve promise with a DOMException whose name is
>> "NotFoundError", and terminate this algorithm.
>>
>> During the above process, the user agent SHOULD show some UI to the
>> user to guide them in the process of selecting and authorizing an
>> authenticator.
>
> ...but requests are sent to all
> authenticators in #8 above?
yes, authenticatorMakeCredential() is invoked asynchronously on each
authnr, however this is a protocol spec and we are not specifying
particular UI/UX. the parag you are referring to is simply
implementation guidance. each user agent will do their best to craft a
worthwhile UX (user experience).
>> 3.1.2. Use an existing credential (getAssertion() method)§
>>
>>
>> This method is used to discover and use an existing scoped
>> credential, with the user's consent.
>>
>> [...]
>>
>>
>> When this method is invoked, the user agent MUST execute the
>> following algorithm:
>>
>> 1. If assertionTimeoutSeconds was specified, check if its value
>> lies within a reasonable range as defined by the platform and if
>> not, correct it to the closest value lying within that range. Set
>> adjustedTimeout to this adjusted value. If assertionTimeoutSeconds
>> was not specified then set adjustedTimeout to a platform-specific
>> default.
>>
>> 2. Let promise be a new Promise. Return promise and start a timer
>> for adjustedTimeout seconds. Then asynchronously continue
>> executing the following steps.
>>
>> 3. Set callerOrigin to the origin of the caller. Derive the RP ID
>> from callerOrigin by computing the "public suffix + 1" or "PS+1"
>> (which is also referred to as the "Effective Top-Level Domain plus
>> One" or "eTLD+1") part of callerOrigin [PSL]. Set rpId to the RP
>> ID.
>>
>> 4. Initialize issuedRequests to an empty list
>>
>> 5. If assertionExtensions was specified, process any extensions
>> supported by this client platform, to produce the extension data
>> that needs to be sent to the authenticator. Call this data
>> clientExtensions.
>>
>> 6. For each embedded or external authenticator currently available
>> on this platform, perform the following steps:
>>
>> * If whitelist is undefined or empty, let credentialList be a
>> list containing a <<<< single wildcard entry.>>>>
>
> First mention of wildcards?
> Where are they defined?
here, the term "wildcard" is being used generically, in order to signify
an entry in credentialList meaning "any authnr". Thus credentialList is
"defined and non-empty" and the next processing rule has the platform
reach out to any and all authnrs on the system.
However, I think there is a bug here in that "credentialList" should be
"whitelist" in the above step. See..
https://github.com/w3c/webauthn/issues/111
>> * If whitelist is defined and non-empty, <<<< optionally
>> execute a
>> platform-specific procedure to determine which of these
>> credentials can possibly be present on this
>> authenticator.>>>>
>
> Implies cred id was stored in makeCred?
> Maybe some hint in makeCred?
yes, the authnr generates and stores a tuple of { private key, cred id,
cred type, RP ID } -- this is stated in "The authenticatorMakeCredential
operation" <https://w3c.github.io/webauthn/#op-make-cred>, though it
could perhaps be stated more rigorously.
>> Set credentialList to this filtered list. If
>> credentialList is empty, ignore this authenticator and do
>> not perform any of the following per-authenticator steps.
>>
>>
>> * Asynchronously invoke the authenticatorGetAssertion operation
>> on this authenticator with callerOrigin, rpId,
>> assertionChallenge, credentialList, and clientExtensions
>> as parameters.
>>
>> * Add an entry to issuedRequests, corresponding to this
>> request.
>>
>>
>> 7. While issuedRequests is not empty, perform the following
>> actions depending upon the...
>>
>> [...]
>>
>>
>> § 3.2. ScopedCredentialInfo Interface
>>
>> This interface represents a newly-created scoped credential. It
>> contains information about the credential that can be used to
>> locate it later for use, and also contains metadata that can be
>> used by the WebAuthn Relying Party to assess the strength of the
>> credential during registration.
>>
>> The credential attribute contains a unique identifier for the
>> credential represented by this object.
>>
>> The publicKey attribute contains the public key associated with
>> the credential, represented as a JsonWebKey structure as defined in
>> Web Cryptography API §JsonWebKey-dictionary.
>>
>> The attestation attribute contains a key attestation statement
>> returned by the authenticator. This provides information about the
>> credential and the authenticator it is held in, such as the level
>> of security assurance provided by the authenticator.
>
> Described in section ###?
Ah, yes, a x-ref to {#attestation} should be added here, thx.
>> § 3.3. User Account Information (dictionary Account)
>>
>> This dictionary is used by the caller to specify information about
>> the user account and WebAuthn Relying Party with which a credential
>> is to be associated. It is intended to help the authenticator in
>> providing a friendly credential selection interface for the user.
>>
>> The rpDisplayName member contains the friendly name of the
>> WebAuthn Relying Party, such as "Acme Corporation", "Widgets Inc"
>> or "Awesome Site".
>>
>> The displayName member contains the friendly name associated with
>> the user account by the WebAuthn Relying Party, such as "John P.
>> Smith".
>>
>> The name member contains a detailed name for the account, such as
>> "john.p.smith@example.com".
>>
>> The id member contains an identifier for the account, stored for
>> the use of the WebAuthn Relying Party. This is not meant to be
>> displayed to the user.
>>
>> The imageURL member contains a URL that resolves to the user's
>> account image. This may be a URL that can be used to retrieve an
>> image containing the user's current avatar, or a data URI that
>> contains the image data.
>
> Other fields okay?
I am unsure what you are asking here.
>> § 3.4. Parameters for Credential Generation (dictionary
>> ScopedCredentialParameters)
>>
>> This dictionary is used to supply additional parameters when
>> creating a new credential.
>>
>> The type member specifies the type of credential to be created.
>>
>> The algorithm member specifies the cryptographic algorithm with
>> which the newly generated credential will be used.
>
>
> will = should?
hm, so, yeah, this language is less than rigorous. I would rewrite as..
The algorithm member specifies the cryptographic key generation
algorithm parameters with which the credential key pair MUST be
generated.
see..
https://github.com/w3c/webauthn/issues/113
>> § 3.5. WebAuthn Assertion (interface WebAuthnAssertion)
>>
>> [...]
>>
>>
>> § 3.7. Credential Attestation Statement (interface WebAuthnAttestation)
>>
> may?
>> Authenticators <<<< also provide >>>> some form of attestation. The
>> basic requirement is that the authenticator can produce, for each
It should perhaps be "..MUST also provide..", and have a link to the
{#attestation-models} section.
https://github.com/w3c/webauthn/issues/115
>> credential public key, attestation information that can be verified
>> by a WebAuthn Relying Party. Typically, this information contains a
>> signature by an attesting key over the attested public key and a
>> challenge, as well as a certificate or similar information providing
>> provenance information for the attesting key, enabling a trust
>> decision to be made.
>>
>> [...]
>>
>> § 4. WebAuthn Authenticator model
>>
>> [...]
>>
>> § 4.1. Authenticator operations
>>
>> A client must connect to an authenticator in order to invoke any of
>> the operations of that authenticator. This connection defines an
>> authenticator session. An authenticator must maintain isolation
>> between sessions. It may do this by only allowing one session to
>> exist at any particular time, or by providing more complicated
>> session management.
>>
>> The following operations can be invoked by the client in an
>> authenticator session.
>>
>> § 4.1.1. The authenticatorMakeCredential operation
>
> Should clientDataHash be passed
> in, or is this assuming that the
> authn calculates it?
The authenticator marshalls the input params of this operation into the
clientData structure and computes the clientDataHash.
See: https://w3c.github.io/webauthn/#authenticator-signature
>> This operation must be invoked in an authenticator session which
>> has no other operations in progress. It takes the following input
>> parameters:
>>
>> The web origin of the script on whose behalf the operation is
>> being initiated, as determined by the user agent and the client.
>>
>>
>> The RP ID [...]
>>
>> [...]
>>
>> When this operation is invoked, the authenticator obtains user
>> consent for creating a new credential. The prompt for obtaining
>> this consent is shown by the authenticator if it has its own output
>> capability, or by the user agent otherwise. Once user consent is
>> obtained, the authenticator generates the appropriate cryptographic
>> keys and creates a new credential. It also generates an identifier
>> for the credential, such that this identifier is globally unique
>> with high probability across all credentials with the same type
>> across all authenticators. It then associates the credential with
>> the specified RP ID such that it will be able to retrieve the RP ID
>> later, given the credential ID.
>
> Doesn't mention creating an attestation or
> processing extensions?
Yes, it should mention attestation.
https://github.com/w3c/webauthn/issues/114
>> On successful completion of this operation, the authenticator
>> returns the type and unique identifier of this new credential to
>> the user agent.
>>
>> If the user refuses consent, the authenticator returns an
>> appropriate error status to the client.
>
> Really vague. I assume that's okay?
We do not define UI/UX in this spec, only give overall guidance.
>> § 4.1.2. The authenticatorGetAssertion operation
>>
>> [...]
>>
>> § 4.1.3. The authenticatorCancel operation
>>
>>
>> This operation takes no input parameters and returns no result.
>>
>> When this operation is invoked by the client in an authenticator
>> session, it has the effect of terminating any
>> authenticatorMakeCredential or authenticatorGetAssertion operation
>> currently in progress in that authenticator session. The
>> authenticator stops prompting for, or accepting, any use input
>> related to authorizing the canceled operation. The client ignores
>> any further responses from the authenticator for the canceled
>> operation.
>>
>> This operation is ignored if it is invoked in an authenticator
>> session which does not have an authenticatorMakeCredential or
>> authenticatorGetAssertion operation currently in progress.
>
> Any considerations for rolling back
> state? (counters, keys, etc.)
Good question -- perhaps we should add overall general guidance of not
incrementing any counters or storing any keys that may have been gen'd ?
https://github.com/w3c/webauthn/issues/116
>> § 4.2. Signature Format
>>
>> [...]
>>
>> This specification defines the common signature format shared by
>> all the above layers. This includes how the different contextual
>> bindings are encoded, signed over, and delivered to the RP.
>>
>> The goals of this design can be summarized as follows.
>>
>> The scheme for generating signatures should accommodate cases
>> where the link between the client platform and authenticator is
>> very limited, in bandwidth and/or latency. Examples include
>> <<<< Bluetooth Low Energy and Near-Field Communication. >>>>
>
> Refs?
I'm not sure we need refs for such well-known things at the level of
abstraction in that parag. in the future, we may wish to ref the CTAP
spec in that spot and ostensibly it will in turn ref BLE, NFC, USB...
>> [...]
>>
>>
>>
>> 4.2.1. Client data used in WebAuthn signatures (dictionary ClientData)
>>
>>
>> The client data represents the contextual bindings of both the
>> WebAuthn Relying Party and the client platform. It is a key-value
>> mapping with string-valued keys. Values may be any type that has a
>> valid encoding in JSON. Its structure is defined by the following
>> Web IDL.
>>
>> dictionary ClientData {
>> required DOMString challenge;
>> required DOMString facet;
>> required AlgorithmIdentifier hashAlg;
>> JsonWebKey tokenBinding;
>> WebAuthnExtensions extensions;
>> };
>
> ArrayBuffer?
>> The challenge member contains the <<<< base64url encoding >>>> of
>> the challenge provided by the RP.
good catch I think -- I /think/ ArrayBuffer is more appropriate in
ClientData than BufferSource, but I'm not sure, and I'm not sure it
actually matters since ClientData is used internal-to-the-authnr in
order to marshal info before hashing it.
https://github.com/w3c/webauthn/issues/117
>>
>> [...]
>>
>> 4.2.2. Authenticator data§
>>
>>
>> The authenticator data encodes contextual bindings made by the
>> authenticator itself. The authenticator data has a compact but
>> extensible encoding. This is desired since authenticators can be
>> devices with limited capabilities and low power requirements, with
>> much simpler software stacks than the client platform components.
>>
>> The encoding of authenticator data is a byte array of 5 bytes or
>> more, as follows.
>>
>> Byte
>> Description
>> index
>>
>> Flags (bit 0 is the least significant bit):
>>
>> Bit 0: Test of User Presence (TUP) result. Bits 1-6:
>> 0 Reserved for future use (RFU). Bit 7: Extension data
>> included (ED). Indicates if the authenticator data has
>> extensions.
>>
>>
>> 1-4 Signature counter (signCount), 32-bit unsigned big-endian
>> integer.
>>
>>
>> Extension-defined authenticator data. This is a <<<< CBOR
>> 5- [RFC7049] map >>>> with extension identifiers as keys, and
>> extension authenticator data values as values. See §5
>> WebAuthn Extensions for details.
>
> first mention of CBOR. Remove, add
> some clarifying text, or a pointer to
> the extensions section?
Extensions were already introduced in the prior section, I don't think
we need to do anything special here and the ref to CBOR is sufficient.
>> [...]
>>
>>
>> § 4.2.3. <<<< Generating a signature >>>>
> What is the relationship between
> this and authenticatorMake
you mean authenticatorMakeCredential I presume.
there is no relationship between this "generating a sig" section and the
overall makeCredential() flow. this signature is for "assertions" and
the getAssertion() flow.
Yes, this could be made more clear and is something we ought to do.
https://github.com/w3c/webauthn/issues/118
>> Before making a request to an authenticator, the client platform
>> layer SHALL perform the following steps.
>>
>> 1. Represent the parameters passed in by the RP in the form of a
>> ClientDatastructure.
>> 2. Let clientDataJSON be the UTF-8 encoded JSON serialization
[RFC7159]
>> of this ClientData dictionary.
>> 3. Let clientDataHash be the hash (computed using hashAlg) of
>> clientDataJSON, as an array.
>>
>> The clientDataHash value is delivered to the authenticator.
>>
>> The hash algorithm hashAlg used to compute clientDataHash is
>> included in the ClientData object. This way it is available to the
>> WebAuthn Relying Party and it is also hashed over when computing
>> clientDataHash and hence anchored in the signature itself.
>>
>> A raw cryptographic signature must assert the integrity of both
>> the client data and the authenticator data. Thus, an authenticator
>> SHALL compute a signature over the concatenation of the
>> authenticatorData and the clientDataHash.
>
> There's no mention of incrementing
> the counter?
that could perhaps be mentioned in the more general
authenticatorMakeCredential operation section.
> Also, should
> authenticatorMakeCredential mention
> storing / retrieving it?
counters are already mentioned in the various attestation sections -- is
this not sufficient?
>> [...]
>>
>> The authenticator MUST return both the authenticatorData and the raw
>> signature back to the client. The client, in turn, MUST return
>> clientDataJSON, authenticatorData and the signature to the RP. The
>> clientDataJSON is returned in the clientDatamember of the
>> WebAuthnAssertion and <<<< AttestationStatement >>>> structures.
>
> WebAuthnAttestation?
Good catch, yes, thx.
https://github.com/w3c/webauthn/issues/119
>> § 4.3. Credential Attestation Statements
>
> Thinking ahead to future
> attestation formats, is there
> a requirement that they MUST
> sign over clientDataHash?
nominally, yes -- clientData comprises the contextual bindings gathered
as the challenge+params wends its way from the RP-server-side (RPSS)
down to the authenticator. marshaling it into clientDataJSON, hashing
it, and signing over it, and then returning the plaintext collected
clientDataJSON as well as the signature gives the RPSS assurance that it
was indeed its challenge+params that the authnr received and that they
weren't fiddled with during their travels. this is explained in
https://w3c.github.io/webauthn/#sec-client-data but perhaps could be
expanded upon (contributions welcome :)
if you examine all three presently-defined attestation types (packed,
TPM, android), you'll see we've carefully spec'd how to incorporate
clientData into the inputs to the data the authenticator signs over.
to answer your question, yes, perhaps stipulating the importance of any
new attestation types including some form of contextaul binding a la
clientdata should be added. (contributions welcome :)
>
>> An attestation statement is a specific type of signature, which
>> contains statements about a credential itself and the
>> authenticator that holds it. Therefore, the procedures for
>> generating attestation statements closely parallel those for
>> generating WebAuthn assertions as described in §4.2 Signature
>> Format, though the semantics of the contextual bindings are quite
>> different.
>>
>> This specification defines a number of attestation types, i.e.,
>> ways to serialize the data being attested to by the Authenticator.
>> The reason is to be able to support existing devices like TPMs and
>> other platform-specific formats. Each attestation type provides the
>> ability to cryptographically attest to a public key, the
>> authenticator model, and contextual data to a remote party. They
>> differ in the details of how the attestation statement is laid out,
>> and how its components are computed. The different attestation
>> types are defined in §4.3.2 Defined Attestation Types.
>>
>> This specification also defines a number of attestation models.
>> These define how a WebAuthn Relying Party establishes trust in a
>> particular attestation statement, after verifying that it is
>> cryptographically valid.
>>
>> Attestation types are orthogonal to attestation models, i.e.
>> attestation types in general are not restricted to a single
>> attestation model. <<<< Broadly speaking, attestation types pertain
>> to the syntax of the attestation statement, while attestation
>> models pertain to the semantics. >>>>
>
> Maybe a concrete example?
see https://github.com/w3c/webauthn/issues/121
>> § 4.3.1. Attestation Models
>>
>> WebAuthn supports multiple attestation models:
>>
>> Full Basic Attestation
>> In the case of full basic attestation [UAFProtocol], the
>> Authenticator's attestation private key is specific to an
>> Authenticator model. That means that an Authenticator of the
>> same model typically shares the same attestation private key.
>> This model is also used for FIDO UAF 1.0 and FIDO U2F 1.0.
>
> Refs or kill?
see https://github.com/w3c/webauthn/issues/120
>> Surrogate Basic Attestation
>>
>> [...]
>>
>> § 4.3.4. Security Considerations
>>
>> § 4.3.4.1. Privacy
>>
>> Attestation keys may be used to track users or link various online
>> identities of the same user together. This may be mitigated in several
>> ways, including:
>>
>> [...]
>>
>> 4.3.4.2. Attestation Certificate and Attestation Certificate CA
>> Compromise
>>
>> [...]
>>
>> If attestation certificate validation fails due to a revoked
>> intermediate attestation CA certificate, and the WebAuthn Relying
>> Party's policy requires rejecting the registration/authentication
>> request in these situations, then it is recommended that the
>> WebAuthn Relying Party also un-registers (or marks as "surrogate
>> attestation"
>> (see §4.3.1 Attestation Models), <<<< policy permitting >>>>) scoped
> ???
>
>> credentials that were registered post the CA compromise date using
>> an attestation certificate chaining up to the same intermediate CA.
We may need to get Rolf to explain this since he wrote it. in any case,
the "policy permitting" qualifying phrase you highlight should perhaps
be "webauthn relying party local policy permitting", meaning that in
this situation, if the RP wishes to establish local policy allowing it
to not necessarily unregister scoped creds that had been reg'd
post-CA-cert-revocation, an option for them is to note that those scoped
creds (ie: {public key, cred.id, cred.type, account, attestation type,
....}) as being of attstn type "surrogate basic" rather than "full basic".
The connotation of "surrogate basic" being that there is
proof-of-possession of the credential private key at registration time,
but there is no proof-of-provenance of the authenticator as a whole as
there is with legit full basic attstn (or DAA, or Privacy CA).
>> It is
>> thus recommended that WebAuthn Relying Parties remember
>> intermediate attestation CA certificates during Authenticator
>> registration in order to un- register related Scoped Credentials if
>> the registration was performed after revocation of such
>> certificates.
>>
>>
>> [...]
>>
>>
>>
>> § 5. WebAuthn Extensions
>>
>>
>> The mechanism for generating scoped credentials, as well as
>> requesting and generating WebAuthn assertions, as defined in §3 Web
>> Authentication API, can be extended to suit particular use cases.
>> Each case is addressed by defining a registration extension and/or
>> a signature extension. Extensions can define additions to the
>> following steps and data:
>>
>> * makeCredential() request parameters for registration extension.
>>
>> * getAssertion() request parameters for signature extensions.
>>
>> * Client processing, and the ClientDatastructure, for
>> registration extensions and signature extensions.
>>
>> * Authenticator processing, and the authenticatorData structure,
>> for signature extensions.
>
>
> Or the authn may spontaneously create extensions
ah, ok, there's not a mention here of "authnr-produced extensions" --
but that's nominally ok here because the above is a list of the points
in the overall dataflow where an extension may define additional
processing (which may create extension-specific data to add to the
flow), and the 4th bullet is the place where that occurs with
"authnr-produced extensions".
see also: https://github.com/w3c/webauthn/issues/122
>> When requesting an assertion for a scoped credential, a WebAuthn
>> Relying Party can list a set of extensions to be used, if they are
>> supported by the client and/or the authenticator. It sends the
>> request parameters for each extension in the getAssertion()call
>> (for signature extensions) or makeCredential()call (for
>> registration extensions) to the client platform. The client
>> platform performs additional processing for each extension that it
>> supports, and augments ClientDataas required by the extension. For
>> extensions that the client platform does not support, it passes the
>> request parameters on to the authenticator when possible (criteria
>> defined below). This allows one to define extensions that affect
>> the authenticator only.
>>
>> [...]
>>
>>
>>
>> § 5.1. Extension identifiers
>>
>> [...]
>>
>> § 5.3. Extending request parameters
>>
>>
>> [...]
>>
>> For extensions that specify additional authenticator processing
>> only, it is desirable that the platform need not know the
>> extension. To support this, platforms SHOULD pass the client
>> argument of unknown extension as the authenticator argument
>> unchanged, under the same extension identifier.
>
> caps?
>> The authenticator argument <<< should >>> be the CBOR encoding of
>> the client argument, as specified in Section 4.2 of [RFC7049].
>> Clients SHOULD silently drop unknown extensions whose client
>> argument cannot be encoded as a CBOR structure.
yes.
>>
>>
>> § 5.4. Extending client processing
>>
>>
>> §
>> 5.6. Example extension
>>
>>
>> [...]
>>
>> §8. Sample scenarios
>>
>
> Why aren't these in the use cases section?
because these are examples of RP client-side code rather than overall
context-setting use cases.
>>
>> [...]
end
Received on Thursday, 2 June 2016 19:15:34 UTC