See also: IRC log
<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[End of scribe.perl diagnostic output]