<jcj_moz> re 626... https://github.com/w3c/webauthn/compare/master...jcjones:626-cbor_for_extensions?expand=1

<weiler> jfontana: some groups want to talk with us more. W3C Privacy (tomorrow 9am PST), IETF token Binding, ...

<weiler> JohnBradley: I chair that. No surprises here.

<weiler> agl: google people doing that work are the some ones doing this.

<elundberg> scribenick: emlun

<elundberg> scribenick: elundberg

jcj_moz: we want to make extension data opaque blobs in the perspective of the client
... basically we want to remove the concept of client extension processing
... the gist is this is going to be a big red change
... will make extension processing a lot simpler
... instead of defining methods to convert JS objects to/from CBOR, that we just pass the CBOR through between RP and authenticator

selfissued: a lot of the extensions don't need CBOR at all
... e.g. the geolocation ext just uses a JSON object

jcj_moz: basically this would just change how the RP encodes the request

selfissued: we shouldn't do that in CBOR, it's a web interface

jcj_moz: then we need to define client extension processing for all extensions

selfissued: yes, but we'll need to do that anyway

jcj_moz: my understanding is [the extension data maps?] are not well defined in webIDL

agl: webIDL doesn't define the "any-maps" we need for extensions

selfissued: some of these extensions never hit the authenticator
... it's always been the principle that the RP passes JSON to the client

<jfontana> MIke your connection is cutting out

agl: I think from an implementation POV we'll face the same problems jcj_moz does

jcj_moz: I worry that if we don't do something we'll have to ship FF without extension support until we figure out what the webIDL for this is
... RPs already have to deal with CBOR because of the COSE encoded keys

John_Bradley: I think selfissued's point is that this would be more work for the RP
... but forcing de/recoding it in the client will likely cause more interop issues

jcj_moz: agreed
... the other option is that we change this from the "any-map", and then we need to be a lot more rigid with what exts are allowed
... basically we would have to define that ext data can't be deeper than one level e.g.
... maybe we should take the conversation about this to the list
... with all respect to selfissued, nevertheless I think we need to do this

https://github.com/w3c/webauthn/issues/725

previous issue was https://github.com/w3c/webauthn/issues/626

selfissued: (back on #626) it seems like this is a webIDL typing issue
... changing the RP API from JSON to CBOR to solve that seems like overkill
... there are clear rules for translating from JSON to CBOR
... we should not change the RP <-> Client API just to solve the webIDL typing issue. This is a web spec, not a binary spec.
... is there not a standard way to pass arbitrary JSON?

jcj_moz: as raw string, yes, as arbitrary map, no (in webIDL)
... I agree fixing webIDL would be the clean thing to do
... but as John_Bradley points out, any translation layer invites interop issues

agl: I don't consider using CBOR here to be overkill
... CBOR is a lot more expressive than JSON
... for instance, knowing whether to encode base64 strings as bytes or strings
... is not so well defined
... right now in Chrome, a JSON object with arbitrary content would likely be rejected as invalid

selfissued: look at the geolocation ext: it uses a well defined W3C JSON format for locations

agl: if we want this any-to-any map, webIDL doesn't currently support that

selfissued: I need to talk to the browser people and figure out the webIDL

jfontana: let's move this discussion to the mailing list

selfissued: a JSON struct can already contain any type of value

agl: I don't think there has been any previous web standard that used an any-to-any map type
... in practice, no web standard has used this before, therefore webIDL does not support it

selfissued: ok, let's figure out how to get that into webIDL so we can do the clean thing

jfontana: let's move on

https://github.com/w3c/webauthn/issues/725

https://github.com/w3c/webauthn/issues/734

https://github.com/w3c/webauthn/pull/732

selfissued: #734 seems fine

merged #734

https://github.com/w3c/webauthn/pull/732

agl: I agree examples of COSE_key would be very helpful
... some minor issues, but in general this looks good

selfissued: the RSA issue should be fixed before we merge

agl: I will note this [in the issue?], presumably Jeff will clean it up

https://github.com/w3c/webauthn/pull/731

akshayku: this looks good to me

jcj_moz: me too, and it's not a very big change
... merged #731

https://github.com/w3c/webauthn/pull/730

selfissued: this is not even grammatically correct

elundberg: It is now a conditional value, it's consistent with the other conditional value

selfissued: ok, this looks fine to me

jfontana: ok, please merge

merged #730

https://github.com/w3c/webauthn/pull/723

elundberg: agl commented that passing the AppId in place of the RP ID is a bit of a type error, because of different formats, but I don't think that's going to matter in practice
... it'll work for U2F, and won't affect non-U2F
... the only place I think it'll matter is if the client tries to store the value internally in some structural format that assumes an RP ID

jcj_moz: this looks good, but I want to take another look at it

selfissued: I would like to get akshayku or Angelo to look at it

akshayku: I'll review

https://github.com/w3c/webauthn/pull/705

selfissued: there's a lot of text; I should read this

agl: I'll go through Jeff's replies; I don't think this is quite ready as is

https://github.com/w3c/webauthn/pull/687

elundberg: this is waiting for #705

https://github.com/w3c/webauthn/pull/666

akshayku: I'd like to align whether fields are required/optional with CTAP, but if it's breaking I'm fine with leaving it required
... in that case I think this is ready to merge
...akshayku: we found some follow-up issues, but this is ready

jfontana: ok, please merge

https://github.com/w3c/webauthn/pull/623

jfontana: time's up

<weiler> trackbot, end meeting

This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Present: weiler elundberg jcj_moz wseltzer kpaulh agl Akshay jfontana John_Bradley selfissued apowers
Regrets: nadalin
Found ScribeNick: emlun
WARNING: No scribe lines found matching ScribeNick pattern: <emlun> ...
Found ScribeNick: elundberg
Inferring Scribes: emlun, elundberg
Scribes: emlun, elundberg
ScribeNicks: emlun, elundberg

WARNING: No "Topic:" lines found.

Agenda: https://lists.w3.org/Archives/Public/public-webauthn/2018Jan/0012.html

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 03 Jan 2018
People with action items: 

WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)