<felipe_bbg> just dropped

<hhalpin> scribe: apowers

<Hubert-PayPal> +Hubert (PayPal)

status of merge document

tony: reviews agenda

(like that?)

scribe: document merge, naming issues, open issues list

<hhalpin> yep, apowers - looks good

scribe: AOB
... other topics? not heard
... status of merge?

jeff: complete
... merged to master

vijay: duplications in master branch, need to blow away old ones

jeff: correct

jc: I did a review and didn't see any merge issues

tony: we can remove the subdirectories after we hear back from Mike

Document merge, status/update

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

tony: sure

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

hhalpin: yes

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?

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

<hhalpin> https://github.com/tabatkins/bikeshed

tony: if we are done with nomenclature the next item is ...

Naming issues, update from JC

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 mailing list
... 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 specification
... maybe another topic for the list

jeff: leave it alone for now
... 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 on
... 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

<hhalpin> +1

<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?

thx

blah

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 ;)

apologies

<hhalpin> https://github.com/w3c/?utf8=%E2%9C%93&query=ash-na

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

<hhalpin> https://github.com/w3c/ash-nazg

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 would be the javascript, relying party is the backend
... 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 spec
... 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?

hubert: sure

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?

*tumbleweed*

alexei: I can get more work done when I'm not on a call

rbarnes: good progress for the day

tony: AOB?
... or 10 minutes back
... meet again next Wednesday
... adjourn

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: