<apowers> morning everyone

<jcj_moz>  present+

<jcj_moz> Zakim save this conference description

<scribe> scribenick: vgb

State of open issues

hhalpin: let's go through open issue

<jcj_moz> open next agendum

tonynad: went through and marked issues last week
... FPWD = First Public Working Draft, SPWD is Second

dates are 5/13 and 9/13 respectively

scribe: aligned with FIDO Plenary dates

<hhalpin> we have reserved space

scribe: set a date for TPAC so we can present SPWD there

hhalpin: TPAC is the all-hands meeting for W3C

<hhalpin> TPAC is 19-23 September 2016

<hhalpin> Lisbon

<hhalpin> https://www.w3.org/blog/2015/09/tpac-2016-dates-and-location-announced/

tonynad: look at issues, and if you disagree with milestones, change them - we now have 5 issues for FPWD

vgb: this week, JC worked on Bikeshed and Travis, I merged in the renaming change, will be starting on remaining issues in the next day or two.

alexei-goog: maybe also do attestation etc. in FPWD?

vgb: was thinking something similar, will take a look this week

rolf: what was the basic idea here? we already have a JSON structure with a raw blob inside it

all: <tense silence while we wait for Alexei to refresh his memory>

alexei-goog: let's put this on hold, will come back to it later int he call

tonynad: terminology section - JC is working on?

jcj_moz: have set aside tomorrow

tonynad: vgb working on TAG comments
... and aligning with Credential Management
... and eTLD+1

alexei-goog: we currently have a section 6 talking about attestation formats
... talks about various things like attestation types, contexts, and DAA
... shows examples in CBOR and so on
... most of this does not need to be here
... if we just had type+blob, that should suffice
... in other words we would have the indirection layer here and FIDO etc. could define the actual blobs

Rolf: clarifying if this means we are removing the attestation spec from the contributed set

alexei-goog: something like that

tonynad: how do people feel? any concerns?

Rolf: not really. the W3C and attestation specs are at different levels and it's not clear for example that W3C testing would focus too much on testing attestation
... should we also think similarly about signature format?

<hhalpin> XML-DSIG

hhalpin: true, W3C focuses on JS APIs, but we have done XML DSIG and other things where we do go to a deeper level
... so if this is truly opaque to web developers, okay, but if not we should really keep things in the same place even if different docs
... obviously things like FIDO device-to-device protocols are out of scope here, but this one is borderline

Rolf: frmo experience, the people involved in JS/HTML are different from the browser side folks, and the JS/HTML folks do not care much about these blobs or the details of processing them on the backend

dirkbalfanz: what did WebCrypto do?

hhalpin: Leaned on JOSE and JWK a fair bit
... that being said other specs do go to low level detail
... all about how do you get to successful interoperable implementations
... goal of this effort was to enable someone to build an implementation that correctly exposes FIDO hardware if they have that

Hubert-paypal: what is the real concern?

vgb: taking Harry's position as guide, want to not specify things that won't be tested here and are not relevant to browser vendor wrapping FIDO-compliant authenticator hardware

Rolf: concern about having too many proprietary implementations due to lack of discoverable spec

hhalpin: does the script author care about these details?

Rolf: no, but the server might not like it

hhalpin: what about node.js or something? anything web app developer can do?
... maybe feedback that something is valid vs. not?

Rolf: this is really server logic. for example during web registration the server has to make a trust decision.

<hhalpin> Yes, just wondering how much server logic will be in JS or not. Anyways, its borderline so I can see it going either way personally.

Hubert-PayPal: in the end, you still have to validate attestation somewhere. so i understand that we might want to separate the specs, but don't want it to get too spread out.

Rolf: server team does not care about web API, while client devs don't need to understand details of format. so there is a natural separation of concerns.

tonynad: so are we okay with that now?

Rolf, Hubert-PayPal: yes, but would be nice to have a link to the attestation spec

hhalpin: yes we can link
... usually eyebrows are raised when e.g. specs are pay-for-download
... can start discussion internally

Mirko: are we taking away means for the browser to help the user?
... e.g. by checking that it's the same authenticator as last time?

Rolf: there is key ID / credential ID but everything else is server-side

Hubert-PayPal: so now the question is whether the separation of concerns is too sharp, i.e. should the browser do something with these "opaque" blobs?

Rolf: don't see what the browser might do.

hhalpin: jsut sent email asking about normative reference policy. let's then talk about level of abstraction.

alexei-goog: but the blob is not produced by the browser, which is just a conduit. so how can W3C enforce anything about it?

hhalpin: we've done various things in the past, but there is a good point about abstraction here.

alexei-goog: why should a hardware vendor read a W3C spec?

hhalpin: there is a bureaucratic concern about how we pull outside specs into W3C, and we really should have a normative reference for interop, so should at least get our ducks in a row.

tonynad: +1 on the interop point.

alexei-goog: take no drastic action now, wait for advice from Wendy and others

hhalpin: Wendy should be back next week

Rolf: can we put a link to these minutes in the GH issue?

hhalpin: here is a link

Rolf: i will add the link

<hhalpin> https://www.w3.org/2016/04/06-webauthn-minutes.html

Rolf: to the issue

tonynad: looks like Alexei already did it
... do we believe this needs to be solved for FPWD?

hhalpin: FPWD can be pretty flexible on this sort of thing

JC: agree

tonynad: will leave as SPWD
... Next topic - it came up at IETF in Token Binding discussions about how it would apply to OAuth
... we have an issue with a client that would need to have access to a JS API for signing at that layer

<Axel> IETF Token Binding https://tools.ietf.org/html/draft-balfanz-https-token-binding-00

tonynad: using the EKM from the TLS session

hhalpin: Can't we do this with WebCrypto?

<hhalpin> So we can sign and verify with WebCrypto, including JWTs

dirkbalfanz: what are we trying to do? which EKM? we might have many sessions open.

tonynad: about OAuth because of the way that federation works
... browser needs to put this in the application header. can do a quick writeup.
... that's all i had
... few more changes coming to Token Binding as a result of yesterday's meeting
... until next week

hhalpin: we'll... be... baaack

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)

Found ScribeNick: vgb
Inferring Scribes: vgb

WARNING: No "Present: ... " found!
Possibly Present: Axel Hubert-PayPal JC RobTrace Rolf adamkcooper alexei-goog all apowers dirkbalfanz hhalpin https jcj_moz joined mirko scribenick tonynad vgb webauthn
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy


WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting

Got date from IRC log name: 06 Apr 2016
Guessing minutes URL: http://www.w3.org/2016/04/06-webauthn-minutes.html
People with action items: