Web Authentication WG -- 01 Jun 2016

<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

"It's all about extensions" discussion, please read Jeff's proposal that was sent to list

<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 inferred
... 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 extensions identifiers
... 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?

Jeff: yes

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)

Jeff: yes

Tony: they may never get updated
... 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 permission mech
... 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

<vgb> +1

Tony: not hearing any objection, I'd like to go ahead and proceed on this premise
... extension draft submitted

Giri's draft extension proposal

<wseltzer> https://lists.w3.org/Archives/Public/public-webauthn/2016Jun/0001.html

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?

Giri: yes

<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

Giri: ok

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> [adjourned]

<wseltzer> s/OK - false alarm. The call's at 10 Pacific Time.//

- DRAFT -

Web Authentication WG

01 Jun 2016

Attendees

Contents

"It's all about extensions" discussion, please read Jeff's proposal that was sent to list

Giri's draft extension proposal

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output