[pasting a few lines from before rrsagent joined; I'll fix minutes]

tony: meting canclled next week due to IETF

We will cancel the meeting next week due to IETF

We will start talking about the proposal about credential management

We are looking at 344

Kim is stuck on traffic and won't be able to join. But she has addressed the concerns by Jeff

Does Jeff have time to look at the issue?

There are two nits that Jeff have problems with. But Kim has addressed the change.

Vijay will merge it soon

Giri: can we make the point that silent authentication is not going to be part of the spec?

Jeff: we have punted silent auth to version 2 of the spec.

Angelo: we have a couple of issues related to silent auth. Can we close them

Angelo: I am planning on addressing 350 after I address the three other PRs I have.

375 is an editorial change and we can wait

Vijay and Jeff will try to look at 378 within the next two weeks

We were looking at 379 and 378. Jeff: I think we need a more comprehensive solution than a point solution.

We agree we can put this on the backburner.

<Rolf> sorry, I have to drop-off now.

We are looking at 384

Mike West has made changes to the PR. The PR 384 roughly captures everything there is about the idea of what the merge of the two APIs would look like

Names such as ScopedCredential haven't been changed.

<gmandyam> Re: credman, please see question at https://lists.w3.org/Archives/Public/public-webauthn/2017Mar/0157.html. Where in the PR is this addressed?

Jeff: As a RP, I don't want to have to worry about what kind of credential I want to get.

This PR will help broad adoption.

Angelo: from the Edge point of view, I am attracted to the idea of getAll and getting all kind of credential there is. However, I am also concerned that the change will trickle down and delay the release of the spec.

Giri: from a device vendor perspective, I am concerned about authenticator scoping.

Mike West: I acknowledge the authentication api spec has more of a requirement of user interference from a hardware perspective.

Mike: the current PR delegates the responsibility of showing user info to the authenticator. But this can be changed.

Giri: the authenticator shouldn't have to worry abotu example.com vs www.example.com

Mike: I doubt it. Authenticators do have to care about that.

Giri: cred man is clear that UA is in charge of handing over cred info and differentiating that info.

Mike: the UA has more control over cred info. For the authenticator aspect, we can teach UA to recognize user mediation.

Giri: I don't believe the current authenticator scoping is different from the way how cred man is doing.

Vijay: Mike has split the cred man into two versions: base and xx. We should be looking at base.

<battre> https://w3c.github.io/webappsec-credential-management/base.html

Giri: I havent' taken a look at the base one. I can take a look at the one.

<battre> https://w3c.github.io/webappsec-credential-management/sitebound.html is the other document that is specific to passwords

Mike: the current spec is that the authenticator would never hand over credential without further user mediation.

Jeff: I think the overall direction of the cred man spec is good. We just need to polish it more.

We should look at the extension-related PR 386

Tony: Jeff and Mike Jones should take it over.

Mike Jones: I looked every line about extension and registry

The one thing I noticed that IANA spec and the main spec are wildly out of sync.

mJones: I put things more related to the main spec back into the main spec and keep the IANA spec small to prevent out of sync in the future.

The main goal of PR is to get the IANA spec get sponsorship from IETF

<jeffh_> please note when MikeJ @selfissued says "IANA spec" he is referring to https://github.com/w3c/webauthn/blob/master/draft-hodges-webauthn-registries.xml

Another part of the spec is that it is now clear that all the extensions in the spec are no different than other extensions, except that they are registered at the IANA spec.

We should merge this very soon so that we can get this going at the beginning of IETF next week

Jeff: I have a review in progress so that we can fix detail level stuff.
... I will finish the review later this afternoon.
... I am fine with the registry portion.

Vijay: can we break the index.bs and the registry into two things because the index.bs change is substantial.

The change would make extension processing critical.

MikeJ: that's not the intention of the PR.

Vijay: our decision earlier was that a cal would never fail because of an extension. That may or may not be the right decision. But that is not related to submission to IETF.

MikeJ: I can split the PR into two but I would prefer getting them in at once so that it is a better sell to Kathleen.
... once I split up the PR and vijay and jeff reviewed it, is vijay authorized to merge it?

Last item: Tony is still working through the richard co-chair stuff.

This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Present: Ketan Rolf alexei-goog angelo gmandyam jeffh jfontana jyasskin mkwst nadalin selfissued vgb wseltzer
No ScribeNick specified.  Guessing ScribeNick: angelo
Inferring Scribes: angelo

WARNING: No "Topic:" lines found.

Got date from IRC log name: 22 Mar 2017
Guessing minutes URL: http://www.w3.org/2017/03/22-webauthn-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


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