Re: extensions, continued.. (was: 05/24/2016 WebAuthn Summary

On Tue, Jun 7, 2016, 4:20 AM Johan Verrept <Johan.Verrept@vasco.com> wrote:

> Hi,
>
>
>
> Let me provide some examples.
>
>
>
> Assume a particular (group of) RP wishes to use FIDO 2.0 for signing.
>
> Due to legal requirements, the user needs to add the phrase “read and
> approved” to his signature. They are prepared to pay for the development
> and for the custom authenticators their business needs.
>

Why does this need to be a FIDO (or webauthn) thing? Especially if there
are custom authenticators involved, why isn't this just a custom solution
for this group of RPs?

Every plenary, we start off by making sure we're all on the same page about
the use cases we're trying to address. Document signing has not been
mentioned so far. If we want to be serious about document signing, we can
form a working group and start to figure out how to do that (not that I
would be in favor of that - I think we have our hands full with the basic
use cases).

When you propose a general mechanism (unprompted extensions) for solving a
particular problem (document signing), you need to weigh the cons and the
pros. I see quite a few cons (around privacy - see my previous message),
and not many pros (I don't actually see how such an extension would be
sufficient to give you what you want - don't you also need trusted
displays, seperate keys for different purposes (login vs. document
signing), non-repudiation, etc.?), so I don't quite see how this makes the
case for such a mechanism.

Dirk.


>
> How would we, as an FIDO 2.0 server/authenticator vendor, go about
> providing our customer with this functionality?
>
>
>
> Frankly, with the current specifications and especially if you prevent the
> authenticator from adding unprompted authenticator data, we cannot. No
> customer is going to wait 2 years until we get this particular extension
> through the approval process and implemented by the clients/platforms.
>
>
>
> However, an uncertified company can hack up a solution that (ab)uses the
> FIDO functionality in the browses/platforms and provides the customer with
> his needs.
>
> Even if the authenticator wouldn’t be allowed to add arbitrary data, all
> they need is 1 supported extension that allows the authenticator to add a
> string or binary blob.
>
> Oh, and why not add the users’ GPS coordinates for risk management while
> we are at it?
>
>
>
> Is this what we want?
>
>
>
> Certification of FIDO 2.0 functionality should be an advantage, not a
> disadvantage.
>
>
>
> More examples?
>
> -          document signing where the hash of the document should be
> included in the signature.
>
> -          the RP needs the user to make a choice and wants/needs that
> choice signed.
>
>
>
> Of course, we can define an extension for all this now… but what about all
> these things we haven’t thought of? What about the requirements of all the
> businesses we have no experience with? Do we really want 1-2 years delay
> for every new technology or business requirement we want to support?
>
> How many extensions are the clients/platforms prepared to implement,
> support and maintain?
>
>
>
> All in all, although I have no objection to all extension being optional,
> I cannot agree with the interpretation that this means the client gets to
> drop anything it doesn’t know or approve of.  (more:
> https://lists.w3.org/Archives/Public/public-webauthn/2016Jun/0059.html )
>
>
>
> Again, with respect, these measures are trying to protect the user but
> they are failing in that task while they are hurting the certified FIDO 2.0
> ecosystem.
>
>
>
> Best regards,
>
>
>
>                 Johan
>
>
>
> *From:* Dirk Balfanz [mailto:balfanz@google.com]
> *Sent:* Tuesday, June 07, 2016 6:46 AM
> *To:* Mandyam, Giridhar <mandyam@qti.qualcomm.com>; public-webauthn@w3.org
>
>
> *Subject:* Re: extensions, continued.. (was: 05/24/2016 WebAuthn Summary
>
>
>
>
>
> On Sat, Jun 4, 2016 at 6:09 PM Mandyam, Giridhar <mandyam@qti.qualcomm.com>
> wrote:
>
> >Does anyone else remember us discussing (perhaps in the FIDO 2.0 WG)
> these extensions?
>
>
>
> Yes, I do.  But I cannot reproduce the communications that occurred within
> one SDO (in this case the FIDO Alliance) on the mailing list of another
> SDO.  I’m not sure this is relevant to your argument anyways.
>
>
>
> I agree it's not relevant other than these three extensions haven't gotten
> as much scrutiny (at least from this spec editor; perhaps from others, too)
> as the other extensions have.
>
>
>
> >How can the client do its job of protecting user privacy if the
> authenticator is allowed to add data to the assertion that the client
> doesn't understand?
>
> I’ll answer with an example.  Chrome browser supports EME.
> MediaKeySessions involve the exchange of messages between the DRM engine
> (CDM) and license server that the client may not understand, and will
> likely involve unique and privacy-impacting identifiers.
>
>
>
> DRM protocols that expose unique identifiers are not exactly an example of
> clients protecting user privacy. FIDO historically draws the line quite
> differently from where DRM systems draw the line. In fact, FIDO
> historically draws the line even more conservatively than the rest of the
> web does (not even considering DRM). Let me give you an example of that:
> when we first introduced app IDs and facets, it was technically possible
> for two origins, let's say google.com and youtube.com, to collaborate and
> access the same key on an authenticator (something that could come in quite
> handy for those two origins, as you can imagine). Note that absent app IDs
> and FIDO, any two origins on the web, if they choose to collaborate, can
> already track a user and agree on a common identifier (by iframing each
> other, run federation protocols, etc). FIDO at that point decided that we
> didn't want to introduce an *additional* channel for different origins to
> track users; so we changed the app id spec to no longer make it possible
> for exampleA.com and exampleB.com to have access to the same keys from an
> authenticator.
>
>
>
> So, historically speaking, *that's* the bar that FIDO has set (and that,
> presumably, we want to inherit here in the webauthn WG), not the bar set by
> DRM systems. DRM systems, to be sure, set the bar differently for good
> reasons - but we're not here to build DRM, we're here to build
> authentication systems that protect the user's security and privacy.
>
>
>
> Answers to your questions below.
>
>
>
>   You can see https://www.w3.org/Bugs/Public/show_bug.cgi?id=26332 for
> more on this topic.  The solution to this was requiring secure context for
> access to EME (
> https://www.chromium.org/Home/chromium-security/deprecating-powerful-features-on-insecure-origins),
> which is what the WebAuth spec already recommends.
>
>
>
> To me, a greater threat to user privacy than unprompted extensions is that
> secure contexts is only a SHOULD requirement in the spec instead of a MUST
> – see https://w3c.github.io/webauthn/#secure-contexts.  But I imagine
> this has already been discussed to death.
>
>
>
> > I therefore propose that these three extensions be changed to included
> a client argument that signals to the authenticator that the information
> described in the extension should be provided by the authenticator.
>
> Qualcomm cannot support the proposal as written.  I would like to pose
> some clarifying questions however:
>
>
>
> a)      Can the client argument be null?
>
> yes.
>
>
>
> b)      What occurs if the client drops an extension that is associated
> with valid client data?  Will the RP know?  e.g. is an exception thrown?
>
> No exceptions is thrown. What happens, and whether the RP will know,
> depends on the extension. Sometimes, the RP won't know whether or not the
> client supported the extension. For example, in the authenticator selection
> extension, the client MUST choose a (random) authenticator if none of the
> specified authenticators are present. So when the RP asks for authenticator
> A, and gets authenticator B, this might be because no authenticator A was
> present or because the client didn't understand the extension - the RP will
> never know. For most extensions, however, I would assume it will be pretty
> obvious from the authenticator response whether the client supported it or
> not.
>
>
>
> c)      What does this mean for unprompted extensions in the packed
> attestation (https://w3c.github.io/webauthn/#sec-raw-data-packed) without
> a corresponding client argument?  It seems that the client cannot just drop
> an unprompted extension and still expect the signature to pass.
>
> Right. "Dropping an unprompted extension" presumably means that the client
> somehow chops off parts of the authenticator response, which will obviously
> break the signature. That's one of the reasons unprompted extensions are a
> bad idea: we can't ask clients to "drop an unprompted extension". We can
> only ask clients to drop extensions that are requested by the RP. Because
> clients must be able to drop extensions they don't understand, all
> extensions must be requested by the RP.
>
>
>
> d)      Similar question for the assertion.
>
>
>
> Same response as above.
>
>
>
> Dirk.
>
>
>
>
>
> -Giri Mandyam
>
>
>
>
>
> *From:* Dirk Balfanz [mailto:balfanz@google.com]
> *Sent:* Saturday, June 04, 2016 11:14 AM
> *To:* Hodges, Jeff <jeff.hodges@paypal.com>; Vijay Bharadwaj <
> vijaybh@microsoft.com>
>
>
> *Cc:* public-webauthn@w3.org
> *Subject:* Re: extensions, continued.. (was: 05/24/2016 WebAuthn Summary
>
>
>
> Hi there,
>
> Until Adam pointed this out to me in Berlin, I had no idea that these
> other three extensions exited. Now, it's certainly my fault - and no one
> else's - for not reading the attestation document more carefully (which is
> where these three extensions were originally defined), but I honestly don't
> remember these three extensions being discussed the way we discussed the
> authenticator-selection and transaction-authorization extensions. Does
> anyone else remember us discussing (perhaps in the FIDO 2.0 WG) these
> extensions?
>
> In particular, I don't understand why they are defined as "unprompted"
> extensions. This is a privacy problem. How can the client do its job of
> protecting user privacy if the authenticator is allowed to add data to the
> assertion that the client doesn't understand? I get Jeff's point about
> innovation if the RP and authenticator can agree on something even if the
> client doesn't know what that something is, but I believe we should err on
> the side of privacy here.
>
> I would also point out that technically speaking, unprompted extensions
> are not allowed according to the current text, which states that "*an
> extension must specify, at minimum, an extension identifier and an
> extension client argument sent via the {{getAssertion()}} or
> {{makeCredential()}} call*".
>
> I therefore propose that these three extensions be changed to included a
> client argument that signals to the authenticator that the information
> described in the extension should be provided by the authenticator.
>
> Thoughts? Opposing or supporting views?
>
> Dirk.
>
>
>
>
> On Fri, May 27, 2016 at 1:07 PM Hodges, Jeff <jeff.hodges@paypal.com>
> wrote:
>
> On 5/27/16, 12:50 PM, "Vijay Bharadwaj" <vijaybh@microsoft.com> wrote:
>
>
>
> You mean you object to allowing the client a say in which extensions are
> emitted? We’re not talking about removing any existing extensions, just
> about clearly defining the circumstances under which an authenticator might
> emit them.
>
>
>
> Yes, we would object to altering the present design that allows for
> authenticators to implement and emit extensions of their own volition, as
> pesently specified (c.f., AAGUID extension, SupportedExtensions extension,
> User Verification Index (UVI) extension).  We feel it is a
> subtle-but-important aspect of fostering the overall ecosystem.
>
>
>
> This entire thread has become quite frayed... having a concrete extension
> proposal on the table may help it coalesce -- I suggest that Giri write up
> the postulated "opaque data" extension using the framework that's presently
> defined in the spec and then hopefully we can more objectively assess it.
>
>
>
> HTH,
>
>
>
> =JeffH
>
>
>
>
>
>
>
>
>
> *From:* Hodges, Jeff [mailto:jeff.hodges@paypal.com
> <jeff.hodges@paypal.com>]
> *Sent:* Friday, May 27, 2016 12:48 PM
> *To:* Vijay Bharadwaj <vijaybh@microsoft.com>
> *Cc:* public-webauthn@w3.org
> *Subject:* Re: extensions, continued.. (was: 05/24/2016 WebAuthn Summary
>
>
>
> On 5/27/16, 12:37 PM, "Vijay Bharadwaj" <vijaybh@microsoft.com> wrote:
>
> One issue with that is that some of the extensions that are currently
> defined (in fact, 3 out of 5) are emitted unprompted by the authenticator.
> Though if we wanted to make this rule, I would be fine with it and we could
> add it in the spec if others agree.
>
>
>
> Essentially the authenticator would still be allowed to ignore requested
> extensions, just not add new ones on its own.
>
>
>
> We paypal object to obviating existing extensions.
>
>
>
>
>
>  *From:* J.C. Jones [mailto:jjones@mozilla.com <jjones@mozilla.com>]
>
> *Sent:* Friday, May 27, 2016 12:33 PM
>
> That's how you'd enforce it: if the authenticator doesn't obey the
> contract, the signature won't be valid when the RP checks it.
>
> Roughly the contract would be: Authenticators will only emit extensions
> they were prompted to emit.
>
>
>
>
>
>
>
>
>
>