<nadalin> OK

<RobTrace> I may be caller #1 (Rob Trace)

+scribe: jcj_moz

<weiler> scribenick: jcj_moz

nadalin: We have 4 PRs open, like to have a discussion about those to get them accepted. We postponed two from last week, so we can look at those.

vgb: 151 is on me. Rolf and I had some offline email discussion where we came up with a direction to take this, and as Rolf puts it, we're talking about having this kind of standard lvl 2 structure which standardizes the way the clientData is embedded and how authenticatorData are formatted, and that would go into the level 1 format which is specific to the attestation format.
... We reached agreement yesterday, and I need to write it up

nadalin: So there will be a generalized structure in the document to hold the specific structures?

vgb: Right. In that sense, it'll be like the current PR where there's a standardization of the manner in which the individual assertions can be conveyed. There'll be more text around how the trust level of these gets determined, and I'll have to do a rewrite of the verification section.

JeffH: I have to point out a couple of process things. You guys basically have done a 2-person design time, but since the design rationale on the list, it'd be good to put all your messages on the list, or write up a design rationale and post it to the list.
... Not just have a PR that modifies the spec w/o rationale.

Rolf: Happy to share the email conversation.

vgb: I was also going to write up the design rationale in the issue. That seems more comprehensible than the long, raw email thread.

JeffH: My process point is that the design rationale should be captured somehow. The email exchange is less effort. But it should be captured publicly somewhere.

vgb: I'll condense it into a summary in the issue.
... I was going to do that while I update the PR. I'll put a cleaned up version of it in the issue.

nadalin: That should get us... after you update it, people can review it and we can get this one by next week.

JeffH: This has implications for PR #192.

nadalin: We can come back to #192 now and come back to the eTLD.

JeffH: #192 is ready to go to merge in, but there are known issues. #161 will have some effect on it, but not a lot.
... But we could merge in #192 now and that shouldn't make anything harder for #161. It may be easier to finish up 161 with #192 already merged.
... The one open issue is the syntax for the identifiers -- there's two open proposals.
... We don't know who prefixed 'webauthn' on the identifiers, but we don't really need that because the registry will permit unambiguous lookups and deduplication
... The recommendation to prefix with a company still causes collisions, so the Java-like reverse domain name is a way.
... But it's a SHOULD because there's no mechanism to enforce
... But it's probably a more workable suggestion than prefixing with just a company name.
... This is not a big huge issue, but something to polish out.

gmandyam: I have a PR outstanding for the registry itself, and I expect it to merge, but about prefixes - they're also used to clearly designate formats that are proposed but haven't fulfilled criteria for inclusion

JeffH: I disagree with that.
... If someone registers something, it will by the act of registering it, conform to the registry
... If someone has an unregistered identifier that works in their implementation, they don't have to prefix it. It doesn't matter. We're just making a suggestion to avoid collisions at runtime.

gmandyam: OK, but the thing is if the prefix has already been taken, anyone who's implementing should look at the registry to avoid a clash

JeffH: But all you can do is suggest, there's no police.

gmandyam: Why are we suggesting in the text?

JeffH: Because we want to nail down the identifier syntax in a place that's hard to change

gmandyam: I believe it should be nailed down in the registry

JeffH: It is, and that's all that's necessary in the registry context
... Your outstanding proposal doesn't read on this discussion at all
... I have some questions about it but I'll do that on email
... I think the chairs need to figure [process for editorship of the registry document] out

nadalin: When people have authored documents that the WG has accepted, those people usually become the editors. We can change that process if there's interest.

gmandyam: I authored a w3 style registry, after discussion with JeffH we went with an IANA-style registry

JeffH: I'm not out of hand opposed to co-editing, but I haven't had time to fully look into it and have an outstanding comment

nadalin: OK, with that, are we done right now with this particular topic

JeffH: I don't think the chairs are done, but we don't need to discuss it this instance

* instant

nadalin: We still have #162, which comes back to vgb with a little discussion on the list. JeffH weighed in about eTLD+1 options here.
... do we think that we have a WG consensus yet?

vgb: I think Dirk has a good suggestion here, which I need to writeup. I was trying to research Yaron's comment here where he's talking about RFC7719 that eTLD+1 is not well-defined, which as JeffH has pointed out will again lead us again into the swamp of the IETF RFC with the WHATWG definitions of Origin aren't entirely identical, so we're going to have to resolve how this gets bound up with the Origin issue.

JeffH: I have thoughts on that. 7719 is a recent informational that's trying to make sense on DNS terminology.
... I have feedback to give on their section on eTLD and such...
... I was going to reply after the call to Yaron's comment. The term eTLD is generic, but a Public Suffix refers to a particular source of that information.
... There are actually mulitple sources of that on the Internet, for example all the CAs maintain their own lists.
... We're also not mandating in the spec that people use the PSL, which is just one source you can attain the information
... which is exactly the kind of language we used in the Cookie spec 6265
... The nominal reply here is that we're OK here, we're using the correct term in the correct way. But the whole thing is a swamp right now.
... I think currently right now we're skirting that swamp effectively, but it is a swamp.

rbarnes: If a browser doesn't know what an eTLD+1 is, it can't survive in the world, so it's practical to assume this thing exists.

vgb: So, since we're on this topic, what is our definitive direction forward on Origin in general? Are we going with WHATWG HTML5 spec, or the official HTML5 spec? Right now we have RFC something-or-other, but someone objected/

JeffH: I've done some looking into this and talked to Mike West about it; what he's doing in the Cookie specs in IETF and W3 is that he's citing the specs that the browsers are implementing
... If the W3C needs to reference W3 specs, then W3 should figure out the impedance mismatch.

vgb: Do other browser implementers agree?

rbarnes: I don't have a strong opinion about this. I think whatever else the rest of the W3C is following, we should follow that.

JeffH: Problem is that it's not clear.

Dirk: We're not longer talking about 162 and the ETLD issue, it's a different problem?

JeffH: It's related, since we need to reference into the HTML URL in fetched specs, probably

Dirk: I don't understand the problem trying to solve.
... I understand the problem with eTLD+1 and the browser already has to deal with these. Browsers make local decisions about that. I think we should in the spec say 'hey browser, use your normal approach'
... but then you were saying that Origins were ill-defined, and that is confusing

vgb: We have several issues on this, they're all casting doubt on the notion that it's clearly understood what an Origin and an eTLD+1 is, and how to test an Origin for equality.
... People's concern is that there may be more than 1 definition

Dirk: Where are we testing origins for equality?

vgb: We need to test that RPIDs match.

<gmandyam> https://tools.ietf.org/html/rfc6454

JeffH: Obsoleted 6454 in the WHATWG. Also claiming to have obsoleted the URI spec

gmandyam: He's obsoleted it, but has Gecko agreed?

JeffH: My understanding is the guts of the major browsers follow the WHATWG specs

rbarnes: I'm not aware of any policy change from Firefox; as far as I know we're still RFC-bound

<rbarnes> https://fetch.spec.whatwg.org/#origin-header

rbarnes: Looking at the fetch RFC, maybe not a substantive change?

<JeffH> [apps-discuss] RFC6454 "the web origin concept" obsoleted? https://www.ietf.org/mail-archive/web/apps-discuss/current/msg14985.html

JeffH: 4-tuple not a 3-tuple. Added Domain.

rbarnes: The ABNF only has scheme-host-port from my link

JeffH: There's an underlying object that's now a 4-tuple
... I just pasted in my note to the Apps discuss list from July trying to raise consciousness as to what's going on with the impedance mismatch between all the specs.
... I agree with Mike West that we don't need to solve this, we just need to reference something that works in our spec. If there's a problem when we try to go to Recommendation, it's the W3C's problem to fix that because we're doing the best we can do at this point.

gmandyam: When you say a 4-tuple vs. 3-tuple...

JeffH: Ane added Domain, which I'm not deep enough to understand yet

<gmandyam> 3-tuple = scheme/host/port, 4-tuple adds domain

(* Ona?)

vgb: Going to leave this open, but this whole discussion around Origin, but I want to be cognizant that if unresolved this will come back to bite us

<rbarnes> here's the 4-tuple thing: https://html.spec.whatwg.org/#origin

vgb: any progress we can make on this, like a WG consensus on normative references or definitions, would be good.

nadalin: If people stopping in during TPAC when we discuss this may have some interesting views on this

[nadalin will buy beers]

<gmandyam> Reference: https://www.cs.columbia.edu/~angelos/Papers/2014/redbutton-usenix-sec14.pdf

rbarnes: Returning to #162...

nadalin: OK, nice try Richard

<gmandyam> Basically, receivers may"spoof" an origin when retrieving webpages delivered via broadcast access. In this case, I can see why a 4-tuple for origin is important to the browser.

rbarnes: Only open question is Dirk's proposal vs. this proposal
... Dirk's got an alternative syntax for doing this. Dirk, do you want to persist with this general proposal or letting this land as-is?

JeffH: vgb is writing up Dirk's proposal as a PR

rbarnes: OK, lost track of that
... OK we'll look for his writeup
... I think we're done with this one then

nadalin: That gets us through the open PRs.
... We still have a bunch of CR-issues to look at

[groaning]

JeffH: Maybe we should concentrate on WD-02 for now, so we can have it done by Lisbon

nadalin: Sounds fine to me.
... On to https://github.com/w3c/webauthn/issues?q=is%3Aopen+is%3Aissue+milestone%3AWD-02

vgb: we also have to do a self-asessment for Accessibility, too.
... #6, what are we doing here?

alexei-goog: If I look at this correctly, how does the authenticator tell the RP what transports it supports. One answer was the MDS.
... the other question is how does the RP tell the client about this information? There the MDS doesn't help much

Dirk: Need to know if this authenticator is something we need to talk to over Bluetooth or NFC or USB... no point telling user to turn on Bluetooth if the device is NFC.

gmandyam: In U2F, wasn't some of this encoded in the x509 cert cert?

alexei-goog: Right, so there are 2 parts: how does the authenticator tell the server, and 2( how does the server tell the client? #1 was in the cert
... but now we're talking about the part that in U2F was in the API call so the client call
... so that the client could know

gmandyam: Could overload the Crypto Key interface

Dirk: How are we doing this in U2F today?

alexei-goog: In U2F, during registration the Authenticator sends an X509 that has Key Handles in the response
... U2F devices, in their x509 cert, during registrations, send their list of supported transports. The server stores this alongside the Key Handle in the DB, and during API calls from the RP to the client, the RP tells the client what transports to use
... In w3c language, the server tells the client here's a whitelist, and here's a list of transports for a given credential ID

dirkbalfanz: Does that work if we do the same thing here?

alexei-goog: It should ,yes
... so that would be going into the Whitelist

vgb: I think you're suggesting adding an optional element to Credential Description
... We need to decide what to do when the RP gives nonsensical values. The browser may even know it's wrong.

alexei-goog: Right now, for example, in U2F we have these authenticators that work over BLE, or USB, or over just one of those. In an API call, the server may ask a mobile browser to use a credential that's only available over USB which isn't doable, so the browser rejects it right away.
... But some credentials may be available over multiple transports and so the browser sends the request over the transports that do exist

vgb: OK. Do you want to write it up, alexei-goog?

alexei-goog: Sure. I'll add a comment to that issue and then write it up.

JeffH: One thought that occurred to me that you might want to include: Might not some of this transport stuff be buried in the platforms' abstraction, so the client doesn't need to know it? Maybe it will matter where WebAuthn gets embedded in the stack?

alexei-goog: I don't think I follow?

JeffH: u2f knows about transport hints because the platform doesn't know about it.

alexei-goog: The way I understand this would work, platforms would propose an API to clients, and clients have to figure out how to talk about this

JeffH: This raises the question of, is CTAP the transport interface, and how does this get addressed in CTAP?

[egg-throwing]

alexei-goog: I think the answer is that CTAP would operate at a lower-level, so after you've already made a decision as to which transport to use, CTAP would be the protocol on that transport. And that decision has to be made beforehand.

JeffH: and what we mean by CTAP is the USB, BLE and NFC specs rolled together

nadalin: Issue #8, which JeffH opened.

JeffH: In terms of all our discussion of Origin we are chipping away at

vgb: Is there anything to do specific with this issue, or can we close this one and handle the others?
... This one is about native apps vs. web platform, and maybe this should just be closed?

JeffH: I'll think about it, maybe this can be

nadalin: #53

vgb: That one just needs to be done, not controversial.

JeffH: Let's mark it OK to do and assign it to vgb

nadalin: We have the TAG review feedback, #60
... Do we finally have a consensus on what to do here?

JeffH: vgb, mike west agreed that these are separate specs and not necessarily intersecting, and we need to consider changing names to not collide?

vgb: Yes, Mike was sad but agreed. And we have 3 things to do, and 1 and 3 are already sorted.
... the middle one that remains is that we define an interface Credential and Mike West defines Credential and they're not the same thing. That's what really needs to be fixed.

JeffH: Sounds simple.

vgb: Yes, to the extent that naming things is simple.

nadalin: #86

vgb: This will be fixed with the attestation change.
... this will get fixed as part of that PR that will be updated with Rolf's feedback

nadalin: Issue #99

vgb: It sounds like JeffH thinks this can be closed.

JeffH: Yes. I think it can.

[Rolf will look and let us know.]

nadalin: We've discussed 161, 162, we have... issue #178.
... and no one has really commented on this one.

vgb: This is one of those that it depends on which reference you use for Origin and such.

JeffH: I'll assign it to myself.
... Issue #179.

gmandyam: I'm confused- do we have a rule of thumb on this? Do we use USVString when it originates outside the browser and intended to go to another entity, but DOMString ... ?

vgb: My understanding is that USVString is... let me paste into IRC a reference

<vgb> one reference: http://heycam.github.io/webidl/#idl-USVString

JeffH: From the IDL spec it's hard to discern what they actually mean

alexei-goog: I need to drop off

SamSrinivas: me too

<Rolf> I am ok with closing issue 99.

gmandyam: It's still not very clear as to when you use it and when you don't.

vgb: My understanding is that DOMString is a logical thing, it's abstract. USVString is a particular serialized implementation of that thing, particularly Unicode.

gmandyam: I understand that, but I don't see where you pick to use it
... If it's internal to the browser and not shared externally, it seems DOMString is OK, but the comment suggests we shouldn't use it at all

vgb: In some places we say that you should take the UTF-8, or the lowercase utf, and that is sloppy terminology he's objecting to

JeffH: We use "UTF8 String" or "UTF-encoded string" in a few places...

vgb: This to me is editorial
... The rest of it is mostly to do with Registry.

[topic change to the Registry comments]

[gmandyam is concerned that the spec data is spread across multiple sources, W3C, IANA]

[JeffH clarifies that mnot is intending that the process for submission of extensions would go into the registry, where it's easier to maintain than in the difficult-to-update spec]

nadalin: gmandyam, do you still want to work on this?

gmandyam: Yes, I do, but I'm waiting on vgb to finish his attestation proposal, I may have to post questions on the list

<JeffH> where "this" is #155 and PR #192

<JeffH> & pr #193

nadalin: As I understand it then, we're OK with going ahead with JeffH's proposal, and JeffH and gmandyam will take over editorship of the registry document.
... So that gets us through the WD-02 stuff
... for now!

vgb: Circling around to what we started at the beginning, does that mean we can merge in 192 and 193?

[agreement]

vgb: OK, I'll do that now.

nadalin: Thanks Mike Jones for writing the blog post
... Looks like we're on schedule to make the TPAC date.
... There was some discussion by Sam from W3C on trying to resolve conflicts between the Privacy and WebAuthn WGs
... Is there anyone on this call who has the in-person TPAC calendar conflict with the PING group and WebAuthn?
... I've gotten that one conflict notification, but if no one has that conflict I'm willing to let this go.

[ no real concern over that ]

nadalin: Does anyone have an objection to keeping the schedule as it is now?

[ no comments ]

nadalin: OK, leaving it as-is for an all-day Tuesday meeting at TPAC
... that's all I have for the agenda today
... Thanks everyone for being so interactive today!
... Talk to you next week!

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: s/x509/x509 cert/
Found ScribeNick: jcj_moz
Inferring Scribes: jcj_moz

WARNING: No "Topic:" lines found.

Default Present: nadalin, rbarnes, jcj_moz, apowers, vgb, JeffH, samsrinivas, Rolf, gmandyam
Present: nadalin rbarnes jcj_moz apowers vgb JeffH samsrinivas Rolf gmandyam
Agenda: https://lists.w3.org/Archives/Public/public-webauthn/2016Sep/0130.html

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

Found Date: 07 Sep 2016
Guessing minutes URL: http://www.w3.org/2016/09/07-webauthn-minutes.html
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