See also: IRC log
<felipe_bbg> just dropped
<hhalpin> scribe: apowers
<Hubert-PayPal> +Hubert (PayPal)
tony: reviews agenda
scribe: document merge, naming issues, open issues list
<hhalpin> yep, apowers - looks good
... other topics? not heard
... status of merge?
... merged to master
vijay: duplications in master branch, need to blow away old ones
jc: I did a review and didn't see any merge issues
tony: we can remove the subdirectories after we hear back from Mike
jeff: I did a cursory review of
the merge and it looked fine
... and having Mike follow up sounds fine
... mike = mike j (not mike west)
tony: we will do a review this
week and be done with it next week
... any more discussion on merge document?
jeff: is talking about nomenclature a subtopic
jeff: JC did a good start
... made some suggestions on some minor polish for nomenclature
... be aware that if you are using gmail, emails from PayPal (Jeff and Hubert) may end up in your spam folder
<jcj_moz> JeffH's comments: https://github.com/w3c/webauthn/pull/48
vijay: thanks for doing this, I'm reviewing the pull request, let me know if that's the right way to do it
jeff: up to the group
jc: prefer GitHub
<hhalpin> I think Github is generally preferable for things that require actual references to the spec
vijay: prefer GitHub
<hhalpin> If it's some overarching issue, then you do the lsit
jeff: GitHub doesn't notify the list
hhalpin: that's being changed right now
richard: the PR relates to many points
jeff: from my experience, you explicitly have to watch the repo
jeff: let's talk offline
... it would be good to let the list know when someone submits a bunch of comments
(who is speaking?)
alexei: if we have the same name
everywhere and we do this global renaming, can we just create
variables that get renamed?
... does such a mechanism exist in bikeshed?
hhalpin: I will look into it, it might be possible
jeff: mkwst has experience with bikeshed and may know
<hhalpin> Here's all the bikshed docs
tony: if we are done with nomenclature the next item is ...
jc: not sure what to do about IANA numbers
jeff: what was registered?
apowers: crypto formats?
jeff: not registered yet
jc: OID number
... open a ticket to choose a different number or keep them
jeff: maybe talk about it on the
... up to that organization to choose and manage the subtree
rbarnes: what are the OIDs?
jc: some of the extensions have
OIDs, standard form based on org tree
... some are registered to FIDO Alliance
jeff: open an issue
jc: I did change the strings, I think it would make sense to change the strings or OIDs or neither, but not the intermediate state
rbarnes: if they are extensions
and they are optional, then it may not make a difference
... probably want to pull all the OIDs into a non FIDO-org
jc: I'm not familiar with how
common these extensions are
... maybe we discuss on the list whether we want to keep them or rename them
<acz-goog> ... phone rings
jc: reference to ECDAA
... maybe another topic for the list
jeff: leave it alone for
... spec is forthcoming
... will be buttoned up by other SDO, perfectly fine to reference
jc: metadata service we have
another thread going on on the list
... not sure if we want to discuss that today, assume not
... state of naming
... seems like from the PR we can genericize things
... open to suggestions
jeff: looks good, thank you
tony: jeff, do you want to review the relying party issue?
jeff: what I was trying to bring
up was changing "FIDO Relying Party" to just "Relying Party"
may cause issues
... it is context dependent
... has to do with the hand off to the identity provider
... we should use the term WebAuthn Relying Party consistently
... when the context is not clear it leads to impedance mismatches
vijay: should we drop the term
Relying Party altogether?
... it's ambigious
jeff: we went through that
exercise in UAF and it went nowhere
... couldn't come up with a decent term
... could imagine adding some text to the spec
... terminology section
... relying party is not a federated relying party
rbarnes: having terminology would be a good place to do that
jeff: it would be good to be able
to point to a more qualified term
... floated this idea last year, people seemed fine with it
rbarnes: would anyone like to create a terminology section?
jc: I don't mind taking it
... if anyone has feelings on the subject, please let me know or let the list know
... what would work for the term Relying Party
rbarnes: since FIDO has already had that conversation, maybe those "confusables" [terms] could be mentioned
jeff: maybe we should be
assigning issues in GitHub to track the work
... if you start working on something assign it to yourself
... and if the issue doesn't exist, create one and assign it to yourself
<Hubert-PayPal> Agreed - it'll make participation easier
rbarnes: I remember that alexei was going to work through the open issues
alexei: yep, that's on me
<sbarnesj_moz> Terminology Section is Issue #50: https://github.com/w3c/webauthn/issues/50
jeff: can you assign issues to yourself
alexei: yes, fine with me
jeff: separate branches and pull requests (PRs)?
alexei: maybe some trivial things direct to master (adding a comma)
<hhalpin> For trivial editorial work I suggest editor's discretion
alexei: more complex create a PR
sbarnes: I prefer everything go through PRs
<rbarnesj_moz> ^^ that's actually rbarnes
sorry, can I change that?
jeff: either fork to own repo or create a branch
rbarnes: everything through PR
jeff: works for me
<felipe_bbg> I was wondering about the term Relaying Party, in the context web and leaving federated identity out of scope, wouldn't it be essentially "web application"?
vijay: use commit nomenclature for marking issues as fixed
<hhalpin> rbarnes, can you handle looking at IRC queue as soon as this conversation raws to a close
vijay: if we just use that then
there won't be confusion about what the status of the issues
is, especially if the changes aren't on master
... and it closes the issue when merged to master
hhalpin: W3C does use GItHub for
permissions, and then we have a different permissions layer
above that for IPR checks
... if you don't have permissions and you want them, contact Wendy or myslef
<JeffH> how does one tell if they don't have "permissions" ?
jcj: I'm disappointed that you didn't mention that was called ash nazg (sp?)
apparently all of Mozilla sounds the same to me ;)
rbarnes: how are we feeling about Tony's proposal to remove the metadata service from the spec
Vijay: optional add-on that's best left out
jeff: sure, although we could reference as an informative reference
<hhalpin> "One interface to find all group contributors and in IPR bind them https://labs.w3.org/hatchery/ash-nazg/ — "
hubert: sure, informative for more information about the attestations and how to validate them
alexei: I think we had decided during the last meeting to make attestation more of a blob rather than spec'ing it out
jeff: sure, that's another way to do it
rbarnes: alexei: make the changes?
alexei: sure after my other issues I'm working on
jeff: see #47
filipe: I posed a question, leaving federated identity outside the scope, would relying party be the web application?
vijay: no, the web application
... goes back to whomever is going to grant security
filipe: there are references to the "script" and it wasn't clear what that is
jeff: client-side portion of web application
rbarnes: relying party will get information from the script
filipe: what confuses me is that
this is all pinned to an origin
... I have to think a bit more about this
vijay: this is why we also pulled
the web origin into the signature
... telling the authenticator who the relying party (RP) si
hubert: useful addition to the
... do we have a security considerations section anywhere?
jeff: we could open an issue for that
rbarnes: we need that to describe
the overall security model
... hubert: could you do that?
rbarnes: it sounds like we are in pretty good agreement on the attestation / metadata service question
tony: 10 minutes left
... look at open issues, or wait until merge is closed?
alexei: I can get more work done when I'm not on a call
rbarnes: good progress for the day
... or 10 minutes back
... meet again next Wednesday
ironically, my account doesn't have sufficient permissions to view the draft minutes :)
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/jc/rbarnes/ Succeeded: s/jc/sbarnes/ Succeeded: s/jc/sbarnes/ Succeeded: s/rbarnes/jcj/ Succeeded: s/oshgnas/ash nazg/ Found Scribe: apowers Inferring ScribeNick: apowers Present: hhalpin vgb apowers antoine christian RobTrace PaulGrassi Janet from Fed Reserve in Minneapolis Hubert (PayPal) Regrets: wseltzer 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: 23 Mar 2016 Guessing minutes URL: http://www.w3.org/2016/03/23-webauthn-minutes.html People with action items:[End of scribe.perl diagnostic output]