See also: IRC log
<vgb> scribenick: angelo
<vgb> Hi Wendy!
I will scribe
<jcj_moz> scribenick: angelo
We will start by looking at 321
Vijay is leading the discussion for PR 321
Vgb: we will look at the diff first instead of going through all of the changes
Dirk: the public key is no longer returned by makeCredential
Now the returned object from makeCredential is only clientDataJSON and attestationObject
The logic behind the change is that the client shouldn't have to worry about the key parsing. It'd be best if only a blob is returned.
Another change is regarding U2F attestation format
Alexei: credential ID is missing
Vgb: he will ensure the Cred ID is available there and will fix this problem later
Richard Barnes: I think the logic is backward
Richard's main concern is that there are certain common attributes cross all authenticators.
JeffH: there have been discussions where we decide to push the complexity back to the server side
Richard: I agree that for the browser, it should just give back the attestation blob
Vgb: what we learned is that most servers are already equipped to handle the complexity
Richard: the assumption of Vgb"s argument is all the relying parties care about attestation
Vgb: however, we have to think about what the solution to this problem is. Which step will take care of the complexity, the RP, browser, authenticator?
Dirk: the browser should take care of the complexity. Another point is that we shouldn't have to worry about making a distinction between server and the frontend JS.
Because whether server and JS script takes care of the compleixty is going to shift over time
Vgb: we are looking at figure 3
All parts of the attestation data is standard component
Alexei: why the attestation format, data, and statement is in binary format instead of JS object
... U2F attestaiton has additional complexity because it doesn't have AAGUID, counter, etc.
<jeffh> The Concise Binary Object Representation (CBOR) data format (RFC7049) implemented in pure JavaScript: https://github.com/paroga/cbor-js
Vgb: the complexity is either going to be on the authenticator or the RP either way.
wendy, do you mean who is at the F2F
Vgb: one point made in the past: should we make the API a bit opninate to force people to parse attestation to have additional secuirty protection
For RPs who don't care about attestation, they don't have to parse it.
Richard: let's land 321 first. I and Dirk will look at it and see if we can make it better
<jcj_moz> scribenick: jcj_moz
nadalin: We're going to merge 321, and then people can comment on it, and we'll resolve the comments in WD-05. We can merge this and put out WD-04.
angelo: [brings up #334]
... There are some concerns about use cases after browser implementations have started
... We want to ship an API that's compatible between all browsers so RPs can start to implement
... This is a set of use cases I've identified [in 334]
... First is bootstrapping two-factor [see issue[
... Also used the terminiology of "cross-platform" rather than portable/not portable
... There are also devices that identify via biometrics, vs. devices that you just happen to have
... That's the very first scenario. The device needs to be portable, but doesn't need to identify the users.
... One example is Github.com; if you sign up for U2F, the site gives you a password prompt first and then prompts for the second factor
... [2nd case] The device can be built in or portable, but doesn't have to be positively identifiable
... [Passwordless re-auth]: While a user has a password - it's a fall back. The device has to identify the user, but can be portable or not
... [ correction, says it has to be portable]
... You have to be able to carry it around to bootstrap other machines
... Fourth case: User signs in without even a user name. The device can always be used to log in
... This is relevant use case for retail employees - the employee uses a card to punch in, you never see your username
... That case the authenticator is portable and has to be able to produce an assertion without a username, using only an RPID
... so those are the use cases we should consider for the doc
Yaron: From an editorial POV it's confusing, because it has a normative and informative section that move back and forth w/o transition
angelo: This will be rewritten to be added to the doc
... [Discussion re: should the RP always show the same credential UI? Potentials of using local storage to keep track of how the user authenticates]
nadalin: Where do you put the 2FA case?
angelo: That's the first case
Yaron: Do you see this as a purely editorial change, even if some of the use cases aren't covered by the current protocol?
angelo: All 5 of these use cases should be part of the spec
Rolf: I'd argue that all 5 of these use cases are already supported
vgb: One of the things I learned from this was that if I knew I was going to call getAssertion w/o a credential ID...
Rolf: This is somehow pre-selecting which authenticators can satisfy...
vgb: Some of these use cases require that selection
... if you want these use cases to work smoothly, you want filter criteria
... I counted 3 criteria: 1) positive ID, 2) portable vs builtin, 3) being callable w/o a credntial ID
jeffh: We should use consistent terminology
vgb: This is angelo saying that 'I as a browser vendor want to support RPs these use cases'
[discussion over those 3 criteria above, re: whether they are dependent on each other]
alexei-goog: [draws a description of how the 3 criteria can be used as a filter]
<weiler> scribenick: weiler
Yaron: we're setting up a choice between two difference bad user experiences.
jeffH: hopefully only a minor fraction of RPs care about the authenticator
... vast majority of web won't care
jakob: can we simplify?
...
angelo: do we need a new method to let an RP know if a certain (type of?) credential is available on a device?
<scribe> scribenick: jcj_moz
vgb: [discussion about interruption during login upon calling a getAssertion]
[[ Breaking for lunch ]]
<jeffh> jcj_moz: :)
<jeffh> dirk: preso cred mgmt vs. webauthn
<angelo> I will scribe
<angelo> We are looking at the relationship between CredMan and WebAuthn
<weiler> scribenick: angelo
<jeffh> angelo: thx
Dirk is introducing us to the CredMan API
The concern: as a developer, I am looking at the APIs and the names are confusing
Even if a dev doesn't care about the names, the two APIs are also very similiar in terms of intent and type
Dirk has a deck. We will refer to the deck for this part of discussion
<weiler> scribenick: jeffh
angelo: sees some RPs using both CredMgmt (CM) and WebAuthn (WA) together to address varioius use cases
e.g. a webapp may use CM to store the moral equivalent of a cookie upon user authn using WA
vgb: CM api is intended for webapps that are not super picky wrt the sec level of the user login/consent, and their 1st priority is low-friction UX.
... posits not prompting user much or at all
... Webauthn posits that it will prompt the user (eg swipe your finger)
dirk: CM is structured where the methods are static....
... but not seeing appetite in room for doing approach B (making webauthn types part of CM class hierarchy)
angelo: there are analogues in various places between CM and WebAuthn
dirk: yes
rolf: CM dictates the protocol for conveying the cred to the RP, where in webauthn we leave it up to the RP to figure out how to do
vgb: when u create a pswd cred the RP doesn't know about it (or have to), but in webauthn we have to register the cred with the RP
... in webatuhn case calling makeCred() is just the beginning of a fairly complex dance
jcj_moz: store() is not correct msthod for creating a 'cryptoCredential'
<angelo> thank you jeff
jcj_moz: thihnks semantics of webauthn is enough different from CM that it is difficult to figure out how to really merge them...
dirk: one of the constraints is (obviously) not to re-start from square-one...
rolf: make CM clear that it is about bearer tokens
dirk: if we just do approach A which is 'rename' scopedCredential -- what do we call it/them? AuthenticationKeyPair ? something else?
axel_nennker_dt: perhaps using terms like "import" (ie improt challenge) and u get something back...
dirk: that's a proposal for redoing the methods so they work for both bearer tokens and for our scoped creds....
... < wondering about what we can simply change in webauthn that clarifies the diffs betwn CM and webauthn>
angelo: what about device bound?
dirk: likes idea of creds being assoc w/authnr, and the bearer ones can just float around...
... (assessing): not seeing appetite for merging into CM, but we need to think about what/how to rename in order to clarify....
all: going around brainstorming terminology...
alexei: CM has store() and get() -- how about it changes to "token storage" API and it keeps the store() / get()
rbarnes: its really about "pswd store" and its special
vgb: and it's write-only
jeffh: they shud rename CM to be "Legacy Cred Mgmt" :)
rbarnes: what's the minimum to actually merge the APIs? (it is approach B in slides)
rbarns: we could just stick the webauthn methods over the on nav.credentials
dirk: no appetite for de-merge -- seems we have appetite for simple re-name, need to do soon if so....
rbarnes: clearly we have storeCred() and exerciseCred() which are similar to store() get() -- if we were to shim into that hierarchy, do we want to steer dvlprs away from using
...: our creds with get() and store() ....?
jcj_moz: we did discuss that we have to return errors if one passes the wrong cred type into any of those four methods....
all: brainstorming....
dirk: as we went from option A to C, appetite decreased....
tonynad: thinks this is coming too late in the game....
mbjones: unless there's a proposal that is *clearly* better than the status quo, do nothing...
vgb: notes that if i'm web dvlpr and there's these two apis -- credentials and authentiction -- which do i use?
angelo: so maybe we rename all four methods and hang them all off of navigator.credentials.
all: more brainstorming
?: nav.credentials.store.better() ???
rolf: what do we do about siteboundCred vs ScopedCred ?
dirk: both are bound to origins, but are different...
axel_nenneker_dt: thinks we need to rename the CM methods...
axel_nennker_dt: does not think they webappsec have appetite to put "bearer" in their names
alexei: what do we want to propose to mkwst?
rolf: differentiate "credential" as being "bearertokens"
all: brainstorming....
dirk: ok, we can propose that to them, in the meantime what do we rename our methods to be ?
all: brainstorming, no clear winner. yaronf_ does not like CryptoCredential because 'crypto' is generic
<weiler> scribenick: weiler
Adam: not planning to test crypto bits
Mike Jones & Tony: advocating for testing crypto bits
Jakob: we have some HW bits we could use for this.
[Mike Jones volunteers to review]
[-04 will get pushed tomorrow or next day]
rbarnes: should we do the 321 changes before the freeze?
... I'd rather have those simplifications (not having to parse authenticator data) before we commit to a version to test.
[two big changes on the horizon: that + the afternoon topic re: credapi naming changes]
[browser vendors agreeing, in principle, to locking down on wd-04 for testing.]
<rbarnes> maybe wd-04++ -- with the developer-friendliness changes we discussed this morning
<rbarnes> (or wd-04 itself, if it gets those changes
<rbarnes> )
angelo: we're about ready to run tests.
adam: any reason to not write tests at the same time as the plan?
A: no.
adam: i'll start writing once wd-04 is out; will take me 2-3 weeks for first cut.
tony: future of wg? other topics? (e.g. touchless auth)
... extensions?
selfissued: I want iana registry created before we finish, so spec can point to it.
jcj: issue 290 - i don't like extensions.
angelo: +1
alexei: the only one we want is appID.
tony: emvco?
alexei: use case for appid: existing u2f deployments using chrome u2f api. eventually want to move them to webauthn.
... can't move users w/o asking them to reenroll unless you have appID.
jcj: for me to do this, I have to do the hard parts of the u2f implementation.
rbarnes: cost of not doing appid is a rocky transition path for users.
selfissued: we've heard good biz cases for other extensions. we can't cut extensions completely.
yaron: can we make extensions transparent to browseer?
jc: could, but extensions could be bad for user; browser needs to be able to filter
alexei: google doesn't need private channel between device and RP; we use attestations (for corp side), and that's sufficient.
yaron: sees strange to publish such a complex spec w/ no extensibility.
[discussion of normalcy of having extensions from the start.]
selfissued: different biz/use cases justify it.
[example of kid's fingerprint for unlocking phone for candy crush, then draining retirement accts. neither ios nor android allow diff privileges based on the finger.]
angelo: let's get core api out (and working) and move ext to another doc.
tony: i'm not sure we want to stick around to maintain ext's. wanted to push out ext's as we know them now and wash our hands of it.
rbarnes: what I'm hearing from browsers is that nothing but appid will be supported for now.
jakob: enterprise/proprietary....
[reference back to transparency...]
rolf: we sgreed before that we'd pass things though by default
everyone: NO.
jeffh: we haven't heard re: "bad" u2f extensions yet...
jakob: what do you do w/ extensions you don't understand?
... what's default behavior?
rolf: I'm fine w/ passing through by default and blacklisting as needed.
[passing through unknown ext's]
[discussion of UVM and what happens if it's not supported]
dirk: a well-behavng UA should not pass through extensions it doesn't understand.
rbarnes: I like angelo's idea of stripping the ext's from the main doc.
conclusion: no change; keep the ext's in the docs. need somone to review doc (selfissued. and jeffh.)
[some discussion of having fido maintain a list of well-liked extensions]
tony: CR not in 1Q. maybe in 2Q.
<jeffh> all: long discussion (yet again) wrt extensions and whether they are honored/supported/passed-thru by browsers. result for now is keep extns in spec as-is, ensure the "they are optional" language is there, and also language that the browser can drop unprompted extension emitted by authnr. note: there is non-trivial pushback in room wrt this -- some (RPs, authnr vendors) want browsers to (best case) agree to a list of extensions that are supported.
<jeffh> all: mike jones to review present spec text in this light with JeffH
no mtg this week; next call 22 Feb