See also: IRC log
<selfissued> OK - false alarm. The call's at 10 Pacific Time.
<wseltzer> Tony: talk of extensions on-list, and a submission of a new proposed extension
<wseltzer> scribenick: hubert-PayPal
<wseltzer> Jeff's email
<JeffH> mail msg wrt client filtering of extensions: https://lists.w3.org/Archives/Public/public-webauthn/2016May/0306.html
JeffH: In the thread on
extensions, Wendy made a great observation that some client may
or may not accept some of those extensions
... there can be legal recourse when an authenticator is found misrepresenting an RP etc.
... If a client is filtering all extensions, it is going to add friction to adoption
... I just wanted to present that overall line of thinking and up level the conversation
Vijay: what I took away from that
explanation, is that it seems there are a couple things to be
... there are clients (embedded) that have no use for extensions and will ignore those
<JeffH> i.e. for example
Vijay: then there might be
clients (perhaps client that are wide open and pluggable) that
will want to allow free use of extensions
... then maybe there is going to be a wide spectrum of clients and we should not mandate anything
... we should just be accepting this variety of clients
jeffH: we're in agreement
Vijay: Nitin, we all agree that
the point of registering extensions is to have well-known
... the questions is what happen when a client receives an extension it does not understand?
... the point that Wendy and Jeff made is that there are cases where client will not do anything with it, other clients will do something smarter
... one of the things you can choose to do is pass the extension on and not do anything
Nitin: Does the FIDO spec know
what the extension means/do?
... you need to register extensions to avoid conflict
Jeff: there may be extensions that are private that nobody else needs to know about
Nitin: that's fair
Jeff: it's implicit that one can go and cook up a private extension that both Client and RP understand it amongst themselves
Hubert: Didn't Sam raise privacy concerns about it?
Jeff: I did think about this and
the basic scenario Sam uses, is that a generic ID is return to
all RPs such that it creates a correlation handler - we should
say in the spec that this is bad behaviour
... something to put in the privacy consideration section
<JeffH> giti: note that EME has addressed similar issues wrt privacy
Gmandyam: very clear privacy issue in DRM - the way they solved that is using secure context - this has been dealt with before
<gmandyam> the W3C’s specification for Encrypted Media Extensions (i.e. DRM enabler for the browser), a MediaKeySession can result in opaque messaging being sent between the decryption module (external to browser) and license server. There was a clear recognition that such messaging can be privacy violating (https://www.w3.org/Bugs/Public/show_bug.cgi?id=26332). The solution was to require a secure context for webpages that access EME.
<wseltzer> Secure Contexts spec
Viajy: can you explain further - we already require secure context - how would that also provide privacy ?
gmandyam: if you feel that something more that secure context is require for privacy, then please explain.
Rolf: Jeff you mentioned some recourse: putting an extension in a black list?
<gmandyam> Accommodating finer-grained permissions on an extension level is certainly possible through ongoing work like the Permissions API - https://www.w3.org/TR/permissions/. Currently WebAuthn is not in the spec but it could be.
Wendy: filing legal complaints, putting out warnings that could be used to create a black list
Rolf: this is part of the certification program (privacy)
<vgb> Giri, this is the entire text of the Privacy Considerations section in Secure Contexts:
<vgb> The secure context definition in this document does not in itself have any privacy impact. It does, however, enable other features which do have interesting privacy implications to lock themselves into contexts which ensures that specific guarantees can be made regarding integrity, authenticity, and confidentiality. From a privacy perspective, specification authors are encouraged to consider requiring secure contexts for the features they define.
<vgb> so maybe this is a red herring - we should be looking elsewhere for privacy specifically?
Nity: this is the privacy of biometric ?
Jeff: in general, not being able to track users across RPs
Tony: where does that put us? not hearing everyone on the same page so far
<gmandyam> To vgb: Cited secure contexts as the solution to the privacy issue in EME - see https://www.w3.org/Bugs/Public/show_bug.cgi?id=26332.
Jeff: I'm hearing that the status quo is OK
Dirk: is it ok then to pass on extension it does not understand?
Jeff: the way I see it is, it is
honoring extensions it does not understand
... a client could ignore what extension payload is transmitted, others be smarter
<wseltzer> Giri's "Opaque data" extension
Jeff: Giri wrote an extension
proposal - if a different extension passes an unspecified
payload - some client may chose to ignore it or not
... in other words it is OK to ignore extensions it does not understand - there is a related issue: there is language in the spec that says that if a client does not know about necessary client processing for that extension it should map the data into the authenticator extension and pass it to the authenticator
... there are some issues with client processing for this
... the RP can send arbitrary data to the the authenticator and back - the authenticator should not create tracking
... this has been used for innovation too - the user identification index is an example that was created by a vendor (FIDO)
Rolf: question: we don't see a need to change the spec - if an authenticator adds an extension, then the client has too parse it through to the RP?
Vijay: there is no stripping out - because of signature
Dirk: according to current spec, authenticators can add such extension?
Jeff: yes, there are 3 of them today
Vijay: this is where there was a proposal that authenticators not be allowed to return an extension that it had not been requested with
Jeff: the argument is that adding that would create friction - making it harder to roll things out on the authenticators - we also have the legal recourse backstop if needed
Dirk: which extensions do this?
Jeff: AAGUID - UVI - supported extensions extension (7.3-7.5)
Tony: Jeff, when you talk about clients, are you also including authenticators?
Jeff: just the layer above the authenticator
Tony: whatever is burned into the client becomes the gatekeeper (embedded clients)
Tony: they may never get
... I'm not hearing real objection - but no vote of confidence either.
... if not hearing objections - could people tolerate leaving the doc as-is (with privacy concerns)
<JeffH> gmandyam: are you referring to https://w3c.github.io/permissions/ when you say "permissions" ?
Giri: my feeling is that the use
of certain extension does not require permission. I sense some
people in the group feel there needs to be a finer grained
... we've had discussion in W3C on the appropriate dialog boxes for granting permission etc.
<wseltzer> PROPOSED: continue with what's in the document, potentially adding some privacy considerations
<JeffH> works for me
Tony: not hearing any objection,
I'd like to go ahead and proceed on this premise
... extension draft submitted
Giri: this was a container which
the authenticator can communicate directly to the RP
... I did think of making it more structured data - something like CBOR so the client could peek into it even if not understanding it...
... I used the UIV extension as a model - UVI has left the format open so we already have a model of how this can work
... I can create a pull request when ready
Tony: any objection to add this?
Rolf: this extension will not be sent from RP to authenticator, correct?
<JeffH> i suggest the term "authnr-produced extension" for this class of extensions...
Rolf: give previous conversation,
why would we need such opaque extension?
... why the authenticator would not use UVI?
Giri: overloading the UVI?
Rolf: trying to understand why the authenticator would want to do this rather than add an extension to the signature
Giri: this is the problem with
the spec - not really sure which this should fit
... happy to bring more Qualcom folks to discuss offline for a more precise use case
Rolf: why dedicated opaque extension to do so since we could use UVI ?
Giri: what is the question?
Mike: my reaction on reading
this, is that it's not clear what it is for
... it is certainly a legal extension but it seems too general - needs more knowledge
... we should be adding example extension that would be of general applicability - this is confusing without knowing what the payload is
Giri: UVI already uses this approach
Mike: maybe I will also call out that UVI should also be better defined
Tony: we may not need to define too much detail for extensions
Mike: agreed - but this extension raises more questions than it answers
Giri: what we had a CBOR object in this extension?
Mike: it would be more acceptable as the CBOR syntax could be used to describe what the data actually is
Giri: as mentioned, I had considered more structured data - I can revise the proposal. Not sure it is necessary to be more precise though
Mike: agreed - unspecified binary data left to agreement between RP and authenticator is the concern
Wendy: we can ask for an update on creating a registry for extensions - having additional extensions seems fine
Mike: I don't see the string UVI anywhere?
Giri: section 6.5
Vijay: to channel some of the
uneasiness: as Jeff & Wendy said, there is the technical
recourse and the non-technical recourse. The latter one only
works if people know what is actually going on.
... the moment the authenticator passes opaque data, I suspect the second recourse would be to block it completely - hence the questioning of the wisdom of doing that - state the intent of the extension would help
Giri: UVI does not specify that - if opaque data is a problem, then what about UVI?
Rolf: UVI is often cited as using opaque data but it has a concrete semantic - what about this one? is it only a container for anything? If yes, we already have one (UVI). If it has a concrete semantic, then we should describe it.
Giri: not sure UVI has really a concrete semantic
Wendy: we've lost Giri...
Giri: because it is only listed
as an example
... If I add the CBOR, my proposed extension won't be opaque but adding to many fields would diminish the flexibility
Tony: Giri will revised his
proposed and we can take a look again.
... any objections?
... none - thanks
... where do we stand on the intro and the summary areas?
Jeff: Vijay merged everything this morning - that's done
Tony: any other business?
Wendy: we published the first
draft yesterday - congrats to all
... on to a wide review
... IPR clock started yesterday
End of call
<wseltzer> s/OK - false alarm. The call's at 10 Pacific Time.//
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: i/In/JeffH: In Succeeded: s/burning/burned into/ Succeeded: s/Giry/Giri/G Succeeded: s/JeffH: In// Succeeded: s/In the thread/JeffH: In the thread/ Succeeded: s/WebEx says the call isn't started// Succeeded: s/Are any of you somehow on the call?// FAILED: s/OK - false alarm. The call's at 10 Pacific Time.// Found ScribeNick: hubert-PayPal Inferring Scribes: hubert-PayPal Default Present: weiler, wseltzer, Nitin, Rolf, Tony, gmandyam, vgb, dirkbalfanz, JeffH, apowers, Hubert, RobTrace, ChristiaanBrand, hubert-PayPal Present: weiler wseltzer Nitin Rolf Tony gmandyam vgb dirkbalfanz JeffH apowers Hubert RobTrace ChristiaanBrand Regrets: rbarnes Agenda: https://lists.w3.org/Archives/Public/public-webauthn/2016Jun/0000.html Got date from IRC log name: 01 Jun 2016 Guessing minutes URL: http://www.w3.org/2016/06/01-webauthn-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]